How to
How to add a custom connector to Claude, step by step
Adding a custom connector to Claude takes minutes once a server exists. Here are the steps at the level that stays true across UI updates, and the part of the job the steps hide.
To add a custom connector to Claude, you need the URL of its remote MCP server. In Claude, open settings, find the connectors section, add a custom connector with that URL, then sign in to the underlying tool through its own authentication. From there, use it in conversation and approve actions when Claude asks.
Key takeaways
- Everything hinges on one input: the URL of a running remote MCP server. Adding it to Claude is the easy part.
- You authenticate through the tool's own sign-in, so the connector acts as your account with your existing permissions.
- Claude's UI evolves, so check the Claude Help Center for current button labels and menu locations rather than screenshots in blog posts.
- The setup is minutes; building, hosting, and maintaining the server behind the URL is the real work.
What do you need before you start?
You need a custom connector's remote MCP server URL and a Claude plan that supports custom connectors. The server is the actual integration: a hosted service that speaks the Model Context Protocol and wraps your tool's API. You either build that server, or have one built and hosted for you.
If you already have the URL, from your engineering team or a provider, you are five minutes from done and can skip to the steps.
If you do not have a URL, that is the actual project. A remote server has to exist and stay running somewhere the internet can reach, which is why team connectors are hosted services rather than files. The distinction is covered in remote vs local MCP servers.
How do you add the custom connector to Claude?
In Claude, open settings and find the connectors section, add a custom connector, and paste the remote MCP server URL. Claude will walk you through authenticating with the tool's own sign-in, and after that the connector is available in your conversations. The whole flow is a few minutes of clicking.
- 1Get the connector's remote MCP server URL. This comes from whoever built or hosts the server, whether your team or a provider.
- 2In Claude, open settings and find the connectors section.
- 3Add the custom connector and provide its URL.
- 4Authenticate through the tool's own sign-in when prompted, so the connector acts as your account.
- 5Start a conversation, ask Claude to use the tool, and approve actions as Claude prompts you.
We are deliberately not naming exact buttons or showing screenshots, because Claude's interface changes and stale screenshots are how tutorials rot. The Claude Help Center documents the current UI, and the shape above stays true across updates.
How does authentication work when you add it?
The connector sends you through the underlying tool's own sign-in, usually an OAuth flow, and you approve access there. That means the connector acts as your account and inherits your permissions, nothing broader. On a team plan, each member goes through the same sign-in individually, so everyone keeps their own access.
This is worth pausing on because it is the security model in one sentence: Claude can only do what your account can already do in the tool. You never paste a password into Claude, and revoking access works the same way it does for any connected app in the tool's own settings.
What happens the first time you use it?
The connector's tools become available in conversation, and Claude uses them when your request calls for it. Read actions flow naturally. For consequential actions, Claude asks before proceeding, and a well-built connector gates destructive operations like `delete` and `send` behind explicit confirmation, so nothing irreversible happens without you saying so.
A good first session is a few real questions against real data: pull a record, summarize recent activity, search for something you know exists. That confirms the connection and teaches you the connector's vocabulary faster than reading a tool list.
Test the gates
Early on, ask for one gated write on a low-stakes record and watch the confirmation flow. Knowing exactly what the connector asks before it acts builds the trust that makes the rest of the rollout easy.
If adding it is this easy, where is the real work?
In the server behind the URL. Someone has to design the tools, separate reads from writes, gate destructive actions, run per-user authentication, host the service, and keep it working as the tool's API changes. Adding a connector is minutes; building and maintaining one is an engineering project with a permanent owner.
This is the honest asymmetry of the tutorial. Every step above assumes a running, well-built server, and that assumption is where teams get stuck: the tool they need has no connector, and nobody has time to build and own one.
That is the case we exist for, so read this paragraph knowing we sell the solution: we scope, build, host, and maintain custom connectors as a service, and what lands in your inbox is the URL from step one. How that process works end to end is on how it works, and if you would rather start from your tool, tell us what to build.