# How to connect Claude to your company's tools with MCP

> A step-by-step guide to connecting Claude to your company's tools with MCP: the Connectors Directory, custom remote servers, desktop extensions and building your own - which plans allow what, who has to approve it, what tool definitions cost you in tokens, and the security posture Anthropic actually publishes.

Canonical page: https://www.heybeagle.com/guides/how-to-connect-claude-to-your-tools-with-mcp

Last reviewed: 2026-07-30

Give Claude your tools. Four ways in, one honest map.

MCP is the standard everyone agreed on, which is exactly why the hard parts are no longer technical. They are which plan you are on, who is allowed to say yes, and what you are paying in tokens before Claude does any work.

## The short answer

There are four real ways to connect Claude to a company's tools, and only one of them needs an engineer. The Connectors Directory is the default: over 950 MCP servers as of July 2026, split between connectors Anthropic has reviewed and community ones that pass only automated checks. A custom remote connector points Claude at any MCP server by URL and works on Free, Pro, Max, Team and Enterprise, though Free is capped at one and on Team or Enterprise an Owner has to add it to the organisation before anyone can connect. A desktop extension is a .mcpb bundle that runs an MCP server on your own machine, and it is the only path to a system behind your firewall, because remote connectors are called from Anthropic's cloud rather than from your laptop. Failing all of those, you write your own server against the spec. What decides between them is rarely capability. It is where the data sits, who is allowed to approve the connection, and how many tool definitions you are willing to pay for on every single message.

## At a glance

- **Is there an official way?**: Yes. Claude's Connectors Directory listed over 950 MCP servers as of 28 July 2026. Anthropic splits them into verified connectors it has reviewed for security, reliability and compatibility, and community connectors that pass automated checks but are not reviewed in depth.
- **Plans it needs**: Custom connectors using remote MCP work on Free, Pro, Max, Team and Enterprise, with Free limited to one. On Pro and Max you add one yourself; on Team and Enterprise an Owner adds it to the organisation first, then each member authenticates their own account.
- **Where it runs**: Claude connects to a remote MCP server from Anthropic's cloud, not from your device. Anything on a private network, behind a VPN or behind a firewall will not connect unless you allowlist Anthropic's IP ranges or run the server locally instead.
- **Who has to approve it**: An Owner on Team and Enterprise. On Enterprise, custom roles can set each connector - and each individual tool inside it - to always allow, needs approval, or blocked.
- **Time to set up**: Minutes for a directory connector once the approval lands. An afternoon for a server you write yourself, and the authorisation is the long pole, not the tools.
- **What it costs**: Tool definitions are billed as input tokens before Claude does anything. Anthropic's own worked example puts a five-server setup at roughly 55,000 tokens of definitions, which its tool search cuts by more than 85%.
- **Biggest limitation**: Anthropic reviews connectors against its listing criteria but states plainly that it does not security-audit or manage any MCP server, and that a remote server can change its behaviour after you have approved it.

## Side by side

Six paths, eight questions that actually decide between them. A tick means the path does this today without you building it; a dash means it does it with a condition attached, and the condition is written under the dash.

| Capability | Directory connector | Custom remote MCP | Desktop extension | Zapier MCP | A server you write | Beagle |
| --- | --- | --- | --- | --- | --- | --- |
| No code to write | Yes | Partly (If the vendor hosts one) | Yes (Install is a double-click) | Yes | No | Yes |
| Works on Free, Pro and Max | Yes | Partly (Free: one only) | Yes (Desktop app only) | Yes (Zapier plan applies) | Yes (Any plan) | Yes (No Claude plan needed) |
| Reaches a system behind your firewall | No (Called from the cloud) | Partly (Allowlist Anthropic's IPs) | Yes (Runs on the machine) | No | Partly (Local server only) | No (Cloud OAuth only) |
| An admin can restrict it per tool | Yes (Enterprise custom roles) | Yes (Enterprise custom roles) | Partly (Allowlist, not per tool) | No (Zapier side only) | Partly (You write the checks) | Yes (Per-tool toggles) |
| Acts under each person's own permissions | Yes (Per-user OAuth) | Yes (Per-user OAuth) | Partly (Whatever the machine reaches) | No (Zapier's own connection) | Partly (You design it) | Yes (Your existing grants) |
| Runs when nobody is in the chat | No | No | No | Partly (Zaps, not Claude) | Partly (You build it) | Yes (Scheduled and ambient) |
| Security-reviewed by Anthropic | Partly (Verified ones only) | No | No | No | No | No (Not an Anthropic product) |
| Nothing to pay beyond your Claude plan | Yes (Tokens still count) | Yes (Tokens still count) | Yes | No (2 tasks per call) | No (Hosting and tokens) | No (Free tier, then credits) |

## What each one actually is

All four Anthropic paths speak the same protocol, so the differences are not about what Claude can do. They are about where the server runs, who is allowed to turn it on, and who is accountable when it misbehaves.

| Approach | What you get | Where it stops |
| --- | --- | --- |
| A connector from the directory (Minutes. Owner approval on Team and Enterprise) | The default path, and the right one for anything mainstream. Over 950 MCP servers were listed as of July 2026, most of them hosted by the tool's own vendor. You enable it, then authenticate your own account through OAuth, so Claude inherits your permissions rather than a shared service account's. | Verified and community sit on the same shelf and look identical once connected, but only verified connectors have been reviewed by Anthropic in any depth. Community ones pass automated checks only. |
| A custom remote connector (Minutes. A URL and an OAuth round trip) | Point Claude at any MCP server by URL. This is how you connect a vendor whose server is not in the directory, or your own hosted server. Available on every plan, and the connection is per person even when the server is enabled organisation-wide. | Free is capped at one. Claude calls the server from Anthropic's cloud, so a server that only answers inside your network will simply fail to connect. On Team and Enterprise, members cannot add one until an Owner has. |
| A desktop extension (Minutes to install. Longer to package) | A .mcpb bundle - a zip holding a local MCP server and a manifest - that installs into Claude Desktop by double-clicking. It runs on your own machine over stdio, bundles its dependencies, needs no OAuth and works offline, which makes it the realistic path to an internal or firewalled system. | Desktop only, and it inherits whatever that machine can reach rather than what the person is entitled to. Admins get an allowlist rather than per-tool control, and switching the allowlist on force-deletes every extension already installed. |
| An automation platform's MCP server (Minutes. A separate subscription) | Zapier, Make and n8n all expose their own catalogues to Claude over MCP, which is a fast way to reach a long tail of apps that will never ship a first-party server. Useful when the action you want is a single well-defined step. | Claude acts as the platform's connection, not as the person asking, so the per-user permission story disappears. Zapier bills each tool call as two tasks from the same quota your Zaps draw on, so a chatty agent is expensive. |
| A server you write (An afternoon to a fortnight) | The spec is open, stewarded by the Agentic AI Foundation under the Linux Foundation since December 2025, and the SDKs are good. You get exactly the tools you want, exactly the scopes you want, and you can run it locally over stdio or hosted over Streamable HTTP. | You own the authorisation, and OAuth 2.1 with protected resource metadata and resource indicators is most of the work. You also own keeping up: the July 2026 revision made the protocol stateless, and roots, sampling, logging and dynamic client registration are all inside a deprecation window. |
| An AI teammate that arrives connected (Minutes. Any Slack or Teams workspace) | A different shape of answer: instead of connecting a chat window to your tools, you hire something that already lives in your channels with the connections made. Beagle is one of these - it works under your existing OAuth grants and holds every outbound action for a human's nod. | You are adopting someone else's product decisions rather than assembling your own. It is a cloud product, so it reaches what OAuth reaches and not what is sitting on a laptop behind a VPN. |

## Step by step

The path most teams should take is a directory connector, so that is the walkthrough. The order matters more than it looks: two of these steps are the ones people skip and then spend a fortnight undoing.

1. **Decide whether the tool has to be reached from the cloud** - This single question picks your path. Claude calls remote MCP servers from Anthropic's infrastructure, so a system that only answers inside your network cannot be a remote connector unless you allowlist Anthropic's IP ranges. If that is not going to happen, you want a desktop extension running locally instead, and you want to know that now rather than after the security review. Check first: Is the server reachable from the public internet?
2. **Look for it in the directory before you build anything** - Most mainstream tools now publish their own MCP server, and a vendor-hosted server is one you do not have to maintain. Check whether the listing is verified or community: both work identically once connected, but only verified connectors have been reviewed by Anthropic for security, reliability and compatibility. Where: claude.com/connectors
3. **Have an Owner enable it for the organisation** - On Team and Enterprise, a member cannot add a connector until an Owner has added it at the organisation level. Enabling it does not give anyone access to anything - it only makes the connector available. Each person still authenticates their own account afterwards, which is what keeps Claude inside their existing permissions. Where: Organization settings, then Connectors
4. **Set the ceiling before you invite anyone in** - Owners can limit what a connected service is allowed to do across the whole organisation, for example allowing reads while preventing every write. On Enterprise, custom roles go further: each connector, and each tool inside it, can be set to always allow, needs approval, or blocked. Blocked tools are filtered out before Claude ever sees them. Note: The org-wide policy is a ceiling. A role cannot widen it.
5. **Connect your own account** - Each person authenticates through OAuth, so no password is shared and Claude inherits that individual's permissions in the connected system rather than a shared service account's. Read the consent screen properly - the connector provider's own terms and privacy policy are usually presented on it, not Anthropic's. Where: Customize, then Connectors, then Add
6. **Turn off the connectors you are not using** - Every connected tool's definition is sent to the model as input tokens before Claude does any work. Anthropic's own figure for a five-server setup is roughly 55,000 tokens of definitions, and it tells claude.ai users directly that connectors are token-intensive and worth switching off when idle. If you are running ten or more, move tool access to on-demand rather than always-available. Where: Tool access modes in settings. Auto is the default.
7. **Decide your prompt-injection posture before you widen access** - Anthropic's guidance is that a hosted server can change behaviour at any point after you approved it, so your install-time trust decision may not still apply, and that anything outside its directory should be treated as untrusted. Start with read-only connectors on low-sensitivity systems, keep write actions on needs-approval, and widen once you have watched it behave.

## What trips people up

The things that turn an afternoon into a quarter, roughly in the order teams hit them.

- **The cloud calls it, not your laptop** - This is the most common dead end, and it is invisible until it fails. A remote MCP server is called from Anthropic's infrastructure, so an internal tool that resolves only on your corporate network will never connect no matter how correct the URL is. Either allowlist Anthropic's IP ranges or use a local desktop extension. There is no third answer.
- **You pay for tool definitions on every message** - Definitions are billed as input tokens before Claude has done anything with them. Anthropic's published example puts GitHub at roughly 26,000 tokens and Slack at roughly 21,000, with an internal setup that reached 134,000 tokens of definitions before optimisation. Tool search cuts that by more than 85% by loading only the handful of tools Claude actually needs, and Anthropic's own cost guidance notes that a plain CLI can beat an MCP server on context because it adds no per-tool listing at all.
- **Verified and community look identical once connected** - The distinction is made at the point of listing and then disappears from the interface. Community connectors pass automated checks but are not reviewed in depth by Anthropic, and Anthropic says explicitly that it does not security-audit or manage any MCP server. Decide which shelf you are willing to install from, write it down, and tell people.
- **Approval happens once, behaviour can change later** - Anthropic states this plainly: a hosted server can change behaviour at any point after you approved it. The research community has been demonstrating the shape of it since 2025 - Trail of Bits showed that a server can inject instructions through its tool listing and so influence the model before any tool is invoked, which is upstream of the approval prompt entirely. In 2025 a real MCP server exposed data across roughly a thousand customer organisations for a month before it was caught.
- **A local extension inherits the machine, not the person** - The neat per-user permission story only holds for OAuth connectors. A desktop extension runs as a process on someone's laptop and can reach whatever that laptop can reach. Admins get an allowlist rather than per-tool control, and be warned: switching the allowlist on force-deletes every extension already installed on every client.
- **Do not assume your SIEM sees the tool calls** - Enterprise has a Compliance API that pulls activity feed events, chat data, file content and audit log events. Before you design a control around it, confirm what it actually returns for connector activity rather than assuming tool arguments and results are in there. Anthropic's own CISO guidance leans on connector allowlists and per-tool approval as the boundary, which is a hint about where the boundary really is.
- **Some of what you would build on is already deprecated** - If you are writing a server: the July 2026 revision made the protocol stateless, removing the initialise handshake and the session header, and dropped stream resumability so a broken stream means re-issuing the request. Roots, sampling, logging and dynamic client registration are all in a deprecation window that ends in July 2027. Pin your protocol version deliberately and read the changelog before you start, not after.

A connector gets Claude to your data. Somebody still has to open the chat, know what to ask, and remember to ask it on a Friday.

## Or skip the build

If what you want is not "Claude, plus our tools" so much as "the work done, using our tools", that is a different product shape. Beagle arrives in Slack or Teams already able to connect, and runs whole jobs rather than answering one question at a time.

- **No connector budget to manage** - Beagle does not spend your Claude context on tool definitions, because it is not sitting inside your Claude plan. There is no always-available versus on-demand decision to get wrong, and no five-figure token bill before the first useful answer.
- **It works under the grants you already gave** - Beagle connects through your own OAuth, so it reaches exactly what you reach in the CRM, the inbox and the tracker. Tools can be switched off one at a time per connection when you want a narrower blast radius.
- **It starts work nobody asked for** - The weekly report drafted before the standup, the renewal flagged while there is still time to act, the quiet account surfaced. A connector waits to be queried. Noticing is the point.
- **Every outbound action waits for a nod** - Beagle drafts the reply, the update and the record change, then holds all of it for a human's approval. Nothing reaches a client or a system of record on the AI's own authority.

## In your stack

Teams here usually connect: Slack, Notion, Linear, Drive, HubSpot, Gmail. Beagle connects to ~3,200 tools in total - see https://www.heybeagle.com/integrations.

## FAQ

**Which Claude plans support MCP connectors?**

Custom connectors using remote MCP are available on Free, Pro, Max, Team and Enterprise, with Free limited to a single custom connector. The difference between the tiers is who sets one up: on Pro and Max you add it yourself, while on Team and Enterprise an Owner has to add it to the organisation first, after which each member authenticates their own account. Desktop extensions work through Claude Desktop specifically, not the web app.

**What is the difference between a connector, an MCP server and a desktop extension?**

They are three names for layers of the same thing. MCP is the open protocol, stewarded by the Agentic AI Foundation under the Linux Foundation since December 2025. An MCP server is a program that speaks it and exposes some tools. A connector is how Claude refers to an MCP server you have connected, whether from the directory or by URL. A desktop extension is a .mcpb bundle that packages a local MCP server so it installs into Claude Desktop with a double-click and runs on your own machine.

**Can Claude reach a tool on our internal network?**

Not through a remote connector by default. Claude connects to remote MCP servers from Anthropic's cloud rather than from your device, so a server on a private network, behind a VPN or behind a firewall will not connect unless you allowlist Anthropic's IP ranges. The supported alternative is a desktop extension: it runs an MCP server locally over stdio, on the machine that can already reach the system, and needs no inbound access at all.

**Do MCP connectors respect our existing permissions?**

OAuth-based connectors do. Each person authenticates their own account, so Claude inherits that individual's permissions in the connected system rather than a shared service account's, and Owners can additionally cap what the connector may do across the whole organisation. Two paths break that model and you should know which you are on: a desktop extension runs with whatever access the machine has, and an automation platform's MCP server acts as the platform's own connection rather than as the person asking.

**What is the difference between MCP and Claude Skills?**

Anthropic's own framing is that MCP connects Claude to data while Skills teach Claude what to do with it, and that the two are meant to be used together. A Skill is a folder with a SKILL.md file and optional scripts, loaded progressively so it costs roughly a hundred tokens until it is triggered. Reach for MCP when you need live data or an action in another system, and a Skill when you need a repeatable procedure done consistently. One Skill can drive several MCP servers.

**Is it safe to connect Claude to our production systems?**

Treat it as a decision rather than a default. Anthropic reviews connectors against its listing criteria but says outright that it does not security-audit or manage any MCP server, and warns that a hosted server can change behaviour after you have approved it. The practical posture, and the one Anthropic's own CISO guidance describes, is an allowlist of connectors, read-only where possible, per-tool approval for anything that writes, and a start on low-sensitivity systems. The joint guidance CISA published with international partners in May 2026 says the same thing in fewer words: avoid granting broad or unrestricted access, and begin with low-risk cases.

## Read next

- [Claude in Slack](https://www.heybeagle.com/guides/how-to-use-claude-in-slack): Where connected tools actually earn their keep
- [How Beagle connects](https://www.heybeagle.com/connect): OAuth, scopes, and what it can reach
- [Agent, defined](https://www.heybeagle.com/glossary/ai-agent): The word doing the heavy lifting above

Try Beagle free: https://www.heybeagle.com/signup (1,000 credits, no credit card).