Claude MCP: What It Is and How to Point It at Your Business

Ask five people what "Claude MCP" means and you will get five answers. One will say it is the connectors list in Claude's settings. One will say it is a terminal command. One will say it is a file full of JSON. One will call it a protocol. One will shrug.

They are all describing the same thing from different angles, which is exactly why it is confusing.

Claude MCP is Claude's support for the Model Context Protocol, an open standard that defines how an AI app talks to outside software. The protocol is one thing. The places you configure it in Claude are another. The server you point it at is a third, and it is the one that decides whether the whole setup is actually useful to you.

This guide covers all three. You will learn what MCP genuinely is under the marketing, where Claude MCP surfaces across the web app, Desktop, and the command line, what happens during that browser popup on first connection, and how to choose a server that covers your whole business instead of one more tool. If you want the connector-shaped version of this story, the companion guide to Claude connectors and how they differ from MCP takes the settings-panel route. This one starts at the protocol.

Quick Answer: What Claude MCP Actually Is

The Model Context Protocol is an open standard, originally published by Anthropic and now used well beyond Claude, that describes how an AI application asks external software for information or actions.

Before MCP, every AI-to-tool integration was bespoke. If you wanted Claude to read your project tracker, somebody had to build a Claude-specific integration. Then somebody had to build a different one for another AI app. MCP replaced that with one shared vocabulary, so any compliant server works with any compliant client.

Three words do most of the work:

• Server: the software that holds or reaches the data. It advertises a list of tools it can perform.
• Client: the AI app. Claude is the client. So is Cursor, VS Code, or ChatGPT in developer mode.
• Tool: a single named capability the server offers, with a defined input. Something like search_documents or create_ticket.

Claude MCP, then, is not a feature you switch on. It is the fact that Claude speaks this protocol, in every surface Anthropic ships. When you add a "custom connector" in Claude's settings, you are adding an MCP server. When you run a terminal command to register a server with Claude Code, you are doing the same job through a different door.

The interesting question is never "how do I turn on Claude MCP". It is "which server do I point it at, and how much of my business can that server actually see".

How an MCP Server and Claude Talk to Each Other

Understanding the handshake makes every setup screen make sense afterwards.

When Claude connects to a remote MCP server, it opens an HTTP connection and asks the server what it can do. The server replies with a list of tools, each with a name, a description written for a model to read, and a schema for its arguments. Claude keeps that list in the conversation.

From then on, Claude decides when to use them. You do not invoke tools by name. You ask a normal question, and if a tool description matches what you need, Claude calls it, gets the result back, and works the result into its answer. That is why tool descriptions matter so much: they are the model's only guide to when a tool is relevant.

Modern remote servers use Streamable HTTP, where the client posts to a single URL and the server can respond with a straight answer or a stream. Older and local servers use stdio, launching the server as a subprocess on your machine and talking over standard input and output. Remote is what you want for anything hosted, because it works identically on the web, on Desktop, and on your phone with no install step.

There is one behaviour worth knowing in advance. Claude will not call a tool it does not think is relevant. If you connect a server and nothing seems to happen, the usual cause is not a broken connection, it is that nothing you asked looked like a job for that server. Naming the server in your prompt once ("ask Context Link about our supplier terms") is a reliable way to prove the wiring works before you rely on Claude to route automatically.

Where Claude MCP Shows Up: Three Surfaces, One Setup

Claude exposes MCP in three places. They look different but they register the same kind of server.

Claude on the Web and Desktop: Custom Connectors

In the Claude apps, an MCP server is called a custom connector. You add one from Settings, then Connectors, then Add custom connector, and the only thing you have to supply is the server's URL.

Anthropic keeps a directory of pre-built connectors alongside this, and those are MCP servers too, just ones Anthropic has verified and listed for you. The custom connector route is how you add anything that is not in the list, including a server you run yourself.

One setup covers a lot of ground. A connector added on the web shows up in Claude Desktop, in Cowork, and on mobile, because the connection is attached to your Claude account rather than the device.

Claude Code: The claude mcp add Command

On the command line, the same job is a single command. This is the form most people mean when they search for claude mcp add:

claude mcp add --transport http context-link https://www.context-link.ai/mcp

The pieces: --transport http says this is a remote Streamable HTTP server rather than a local subprocess, context-link is the local name you will refer to it by, and the URL is the server itself.

By default that registration applies to the current project only. Add --scope user to make the server available in every project you open:

claude mcp add --transport http --scope user context-link https://www.context-link.ai/mcp

A few companion commands are worth memorising:

Command	What it does
claude mcp list	Shows every server registered, and whether it is connected
claude mcp get <name>	Prints the full config for one server
claude mcp remove <name>	Unregisters a server
/mcp (inside Claude Code)	Opens the interactive panel to authenticate, inspect tools, or reconnect

Anthropic's Claude Code MCP documentation covers the less common flags, including environment variables and headers for servers that use a static API key instead of OAuth.

Other Clients: The Same Server, Different File

The reason MCP is worth learning once is that the server does not care which client is calling. Cursor reads servers from .cursor/mcp.json. VS Code reads them from .vscode/mcp.json. Codex reads them from ~/.codex/config.toml. All three take the same URL you pasted into Claude.

If you ever move off Claude, or run Claude alongside another tool, the server you set up follows you. Our MCP server docs carry the exact config block for each of those clients.

What Happens During That Browser Popup

The first time a Claude MCP server needs to know who you are, a browser tab opens, you approve something, and the tab closes. It looks trivial. It is doing a fair amount of work, and knowing what that work is helps you answer the security question when a colleague asks it.

A well-built remote MCP server authenticates with OAuth 2.1, the same family of flows that powers "sign in with" buttons across the web. Four parts matter:

Dynamic Client Registration. Claude has never met your server before, so it registers itself as a client on the fly and gets back an ID. This is why you do not have to paste an API key or pre-create anything on the server side. The URL really is the only input.

PKCE with S256. The authorization code that comes back through the browser is bound to a cryptographic challenge only the original client can answer. If someone intercepts the code mid-flight, it is worthless to them. Context Link's server refuses any request that does not use it.

Opaque tokens. Some servers hand out self-describing tokens that anyone holding one can decode. Context Link does not. The token is a random string, stored hashed, and validated in-process on every call. A leaked token reveals nothing about you by itself, and it can be revoked centrally the moment you disconnect.

Resource indicators. Defined in RFC 8707, these bind a token to the specific server it was issued for, so a token minted for one service cannot be replayed against another.

The practical takeaway for a non-developer: what you approved on that consent screen was a scoped, revocable grant tied to your own account. The server sees exactly what your account can see, and nothing belonging to a teammate's private connections. Revoking it is a single toggle in Claude's connector list.

The Question Nobody Asks: How Much Should One Server Cover?

Here is where most Claude MCP advice stops, and where the actual decision lives.

The default assumption is one server per tool. A server for your document store. A server for your ticketing system. A server for your inbox. Each one is a clean, well-scoped integration, and each one searches exactly one place.

Stack enough of them and something awkward happens. You now have to decide, before you ask, which server holds the answer. Claude will happily route to a server if your question obviously matches its description, but most real questions do not announce their source. "What did we commit to on data residency for the enterprise deal?" could be in an email thread, a proposal document, a project tracker comment, or a page on your own website. Possibly all four, with different wording.

You end up as the router. You hold the map of where everything lives, and the tooling just gives you more places to point at.

There is a second shape available, and it is underused: one MCP server that reads across everything at once. Rather than exposing your tools individually, it indexes their content into a single searchable layer and offers Claude a small number of tools that search all of it. The question stops needing a destination.

That is the trade-off in a sentence. Per-tool servers give you precise, tool-specific actions and make you choose. A whole-business server gives you one place to ask and does not do tool-specific actions. Most operators want both eventually, but if you only set up one, the second kind answers more of your actual questions.

A Worked Example: One Claude MCP Server for the Whole Business

Context Link is built as that second kind. It runs a hosted MCP server at https://www.context-link.ai/mcp, and it exposes four tools rather than one per source:

Tool	What Claude does with it
get_context	Runs a semantic search across everything you have connected and returns the matching snippets with their sources
ask_question	Same retrieval, then composes one grounded paragraph with numbered citations. Pro plan only
save_memory	Writes a named document back to Context Link so future sessions read the current version
get_memory	Retrieves one of those documents by name

Behind those four tools sit your connected sources: Google Docs and Drive, Notion, OneDrive, Basecamp, Monday.com, any website crawled by sitemap or URL list, named stacks of uploaded files, email inboxes and specific folders over IMAP, and Memories. Sources re-sync on a schedule, every 24 hours by default, so what Claude reads reflects the current state rather than the day you connected it.

The result is that "what did we commit to on data residency" becomes a single call. Claude asks get_context, gets snippets from the email thread and the proposal document together, and answers with citations pointing at both.

Setting it up takes one of the two routes above:

1. In the Claude apps. Settings, Connectors, Add custom connector. Name it Context Link, paste https://www.context-link.ai/mcp, set authentication to "Required when the server asks", and save. The full walkthrough with screenshots covers the permission prompts.
2. On the command line. claude mcp add --transport http context-link https://www.context-link.ai/mcp, then /mcp inside Claude Code to authenticate.

Either way, note the www. The apex domain is not the MCP endpoint, and pointing a client at it is the single most common setup failure.

If you want the wider picture of why retrieval beats pasting documents into a Project, our guide to grounding Claude in your own business data covers the alternatives, and the business context MCP page lays out the whole-business version in product terms.

Troubleshooting Claude MCP

Five failure modes cover almost everything.

The connection fails instantly. Check the host, character by character. A missing subdomain or a trailing slash will do it.

Connected, but every tool call returns 401. The client has not authenticated yet. Most clients only trigger the OAuth flow when a tool is first called, not when the server is added. Look for a "sign in" or "authenticate" action in the MCP panel, or just ask a question that forces a tool call.

Claude never calls the tool. Name the server explicitly in your prompt once. If it works when named and not when implied, the issue is routing, not connection.

Tools connect but return nothing. The token is bound to whichever account approved the consent screen. If that account has no sources connected, or the content sits on a colleague's personal connection, there is genuinely nothing to search.

A client demands OIDC or a userinfo URL. Turn that option off. OAuth 2.1 and OpenID Connect are related but different, and an MCP server that issues opaque tokens is not an identity provider. Insisting on OIDC will break a connection that would otherwise work.

Conclusion

Claude MCP is less complicated than the vocabulary makes it look. Here is what to keep:

1. MCP is an open protocol for AI apps to call external software, not a Claude-only feature.
2. Claude exposes it as custom connectors in the apps and as claude mcp add on the command line. Same servers, different doors.
3. That browser popup is an OAuth 2.1 grant scoped to your account, and you can revoke it in one click.
4. The server you choose matters more than the setup. One server per tool leaves you routing your own questions.
5. A server that reads across everything you have connected removes the need to know where an answer lives before you ask.

If you already have a Claude MCP server or two wired up, try this: take the last question you had to ask twice, in two different places, and see whether a single whole-business server would have answered it in one call. That gap is the one worth closing.

Connect a source in Context Link, add the server to Claude, and ask something that spans two of your tools at once.