Custom Claude connectors: what they are and how businesses use them

Directory connectors and custom connectors

Claude has two kinds of connectors. Directory connectors are prebuilt and reviewed by Anthropic, and cover popular apps such as Google Drive, Slack, Notion, HubSpot, and Stripe. Custom connectors are any remote MCP server you add yourself by URL.

Both use the same technology, the Model Context Protocol. The difference is who built the server and who is responsible for it. If your system has a directory connector that does what you need, use it. A custom connector is for everything else: the in-house database, the ERP with no listing, the internal API, or a popular app where you need tighter permissions or your own business rules.

How a custom connector works

The connector is a web service that speaks MCP at an HTTPS address, commonly ending in /mcp. When Claude starts a conversation with the connector enabled, it asks the server what tools it offers. Each tool has a name, a description, and an input schema. When a question needs one, Claude calls the tool, the server runs it against your system, and the result comes back into the conversation.

Anthropic's documentation is explicit that Claude connects to custom connectors from Anthropic's cloud infrastructure, even when someone is using Claude Desktop. That is why the server cannot sit only on your office network: it needs a reachable endpoint, or an approved network path, and it needs to authenticate every request.

Plans and rollout

Anthropic documents custom connectors on Free, Pro, Max, Team, and Enterprise plans, with the Free plan limited to one custom connector. On Team and Enterprise, only owners, or roles granted the right permission, can add a connector for the organization, under Organization settings and then Connectors.

Adding a connector to the organization does not give anyone access by itself. Each member connects and authenticates individually, and then enables the connector in the conversations where they want it. When the connector uses per-user OAuth, Claude can only reach what that person could already reach in the source system. When it uses one shared credential, everyone reaches whatever that credential can, which is rarely what a business wants.

What makes a connector useful instead of a demo

Most connectors that disappoint are thin wrappers that expose every API endpoint as a tool. Claude then has dozens of similar tools to choose from, picks the wrong one, or pulls far more data than the question needs.

• Start from real questions. Ten or twenty questions your team asks every week decide the tool list.
• Keep tools narrow. One job per tool, a strict schema, and a description that says when to use it and when not to.
• Bound every result. Cap rows, document counts, and response size so answers fit the context window.
• Separate reads from writes. Label write tools so Claude asks before using them, and ship read-only first.
• Write server instructions. A short set of rules sent at connection time, such as how to treat missing data, steers Claude more than any prompt a user writes. Keep it short: Claude Code truncates long instructions at 2,048 characters.
• Test with questions the connector must refuse, not only the ones it should answer.

When to build, and when to buy

If you have developers with time and only one system to connect, building in-house is reasonable; the official SDKs are good. If the connector will be used by a whole team, touches sensitive data, or spans several systems, the ongoing work of hosting, authorization, and keeping up with protocol changes is usually the bigger cost. That is the work a done-for-you connector covers.