MCP is a shared language that lets AI applications talk to outside tools and data in a consistent way.

The plain-words definition

A protocol is an agreed set of rules for how two programs talk. You already use protocols every day. When your browser loads a web page, it follows rules called HTTP. When your phone sends an email, it follows rules for mail. MCP is a protocol for one particular conversation: the one between an AI application and the outside tools or information it wants to use.

What it offers

MCP lets a program, called a server, say: “here is what I can do, here is what I can show you, and here is how to ask.” An AI application, such as Claude, reads that description and can then use those abilities when they help with your request. The AI does not need custom code written specially for each tool. It follows the common rules.

A short story of why it appeared

As AI assistants became capable, people wanted them to work with real information: their documents, their code, their messages, their company data. Developers solved this one connection at a time, writing special code to join an assistant to a service. Every connection was slightly different, and each needed upkeep. MCP was created to replace that patchwork with a shared standard, so that effort spent on one connection benefits everyone. It is a bit like the early days of the web, when agreeing on common rules turned isolated pages into a connected world.

What MCP is not

It is not a model, and it does not make Claude smarter. It is not a single product that you buy. It is not a security guarantee either; it is a way of connecting things, and the safety of each connection still depends on the server, the permissions, and your care. Keeping these limits in mind helps you judge claims about MCP calmly.

Without a standard, every AI application would need its own special connection to every tool.

The many-to-many tangle

Imagine five AI applications and ten tools: a calendar, a document store, a code host, a database, and so on. If each application needs a custom connection to each tool, that is fifty separate pieces of work. Every time a tool changes, many connections break. Every new application starts from zero. This is sometimes called the N times M problem, because the work grows with the product of the two numbers.

flowchart LR
  subgraph Before["Without a standard"]
    A1["App 1"] --- T1["Tool A"]
    A1 --- T2["Tool B"]
    A2["App 2"] --- T1
    A2 --- T2
  end
  subgraph After["With MCP"]
    B1["App 1"] --> M["MCP"]
    B2["App 2"] --> M
    M --> S1["Tool A server"]
    M --> S2["Tool B server"]
  end
    

On the left of the diagram, two apps and two tools need four separate connections. Add a third app and a third tool, and you need nine. On the right, each app speaks MCP, and each tool is wrapped in an MCP server. Now each side is built once, and any app can reach any server. The work grows by addition instead of multiplication.

Why it matters for AI in particular

AI assistants are only as helpful as the information and abilities they can reach. A model that cannot read your documents cannot summarize them. A model that cannot create a ticket cannot help you manage your tasks. As people ask AI to do real work, the number of tools it must reach grows quickly. A standard makes that growth manageable and keeps the ecosystem open to new tools and new assistants.

Who benefits

Everyone in the chain gains something. Tool providers write one server and reach many assistants. Assistant makers support one standard and gain access to many tools. Companies can connect their internal systems once and let different teams use them with the assistant of their choice. And ordinary users get an assistant that knows more about their world and can help with real work. A shared standard also reduces lock-in, since a tool built for MCP is not trapped inside one product.

MCP describes who does what with three simple roles.

One host, many servers

A single host can connect to several servers at once. Each connection has its own client inside the host. So in one conversation, Claude might use a calendar server to check your schedule, a document server to find a file, and a database server to look up numbers. The servers do not talk to each other. The host sits in the middle and decides how to combine what they return.

Why this separation is useful

The separation keeps responsibilities clean. The host controls the user experience and permissions. The client handles the technical conversation. The server focuses on its own specialty, such as a particular service, and need not know anything about the AI model itself. This makes servers simpler to write and safer to reason about.

flowchart TD
  U["You"] --> H["Host: the Claude application"]
  H --> C1["Client 1"]
  H --> C2["Client 2"]
  H --> C3["Client 3"]
  C1 --> S1["Server: files"]
  C2 --> S2["Server: calendar"]
  C3 --> S3["Server: database"]
    

MCP has layers: a message format, a way to carry messages, and the features built on top.

The layers

It helps to picture MCP in three layers. At the bottom is the transport, which is the road the messages travel on. Above it is the message format, which defines how requests and answers look. At the top are the features, which describe what servers and clients can offer each other. Each layer can be understood on its own.

The message format

MCP messages follow a widely used, lightweight format for remote calls, in which one side sends a request with a method name and details, and the other side sends back a result or an error. There are also one-way notices, for events that need no reply. Because the format is simple and common, it is easy to build and to inspect when something goes wrong.

The main components

A server can offer three kinds of things, each with a different purpose and a different level of control.

Who is in control?

A neat way to remember the three is by asking who triggers each. Tools are model-controlled: the AI decides when a tool would help. Resources are application-controlled: the host decides which information to supply. Prompts are user-controlled: you pick them from a list. This split helps keep people in charge of the important choices.

How a tool describes itself

Every tool comes with a name, a plain-language description, and a description of the inputs it expects. The model reads these descriptions to decide when and how to use the tool. This is why descriptions matter so much. A clear description helps the model use the tool correctly. A vague or misleading one leads to mistakes. Servers can also say whether a tool only reads or can also change things, which helps hosts ask for the right level of approval.

Choosing the right building block

When you design or select a server, it helps to ask what the reader actually needs. If Claude must do something, such as create a ticket, a tool is right. If Claude must see something, such as a policy document, a resource is right, because it is simply information to read. If a person often starts the same kind of task, such as a weekly summary, a prompt template saves them from retyping the same instructions. Many beginners make everything a tool. A more careful design keeps reading and acting separate and offers the simplest block that fits the need.

Messages can travel on your own computer or across the internet, and the transport decides which.

Local servers

A local server runs on your own machine, started by the host. The host and the server exchange messages through standard input and output, which is the simplest possible channel between two programs on the same computer. There is no network involved, which makes local servers fast and easy to build. They are well suited to tasks such as reading files on your computer or using local developer tools.

Remote servers

A remote server runs somewhere else, such as a company’s cloud, and the host reaches it over the internet using standard web requests. A remote server can serve many users, can be updated centrally, and does not require installing anything on your machine. It also needs more care around identity and security, since it is reachable from outside.

Streaming and long tasks

Some work takes time, and servers may want to send progress updates or several pieces of a result as they become ready. The remote transport supports streaming, so a server can send information gradually over one connection. This is useful for long searches, large downloads, or tasks that report their progress step by step.

Every MCP connection starts with a handshake, runs for a while, and ends cleanly.

The handshake

When a client connects to a server, the two begin by introducing themselves. The client says which version of the standard it speaks and which abilities it supports. The server answers with its own version and the abilities it offers. This exchange is called capability negotiation. After it, both sides know exactly what the other can do, and neither will try to use something the other lacks.

sequenceDiagram
  participant H as Host and client
  participant S as Server
  H->>S: Hello: my version and abilities
  S-->>H: Hello: my version and abilities
  H->>S: Ready to work
  H->>S: What tools do you have?
  S-->>H: List of tools with descriptions
  H->>S: Call this tool with these inputs
  S-->>H: Result
  H->>S: Close the connection
    

The sequence shows an orderly conversation. The two sides greet each other and agree on abilities. The client then asks what tools exist, receives the list, and calls a tool when the model needs it. At the end, the connection closes. The same pattern applies to resources and prompts: ask for a list, then ask for the item you want.

Staying up to date

Servers can change over time. A new tool may appear, or a document list may grow. The standard lets servers send a notice that something has changed, so the host can ask for a fresh list. This keeps the model’s picture of what is available accurate, without restarting the connection.

Following one question through the system shows how all the parts work together.

An example request

Suppose you type: “Find the notes from last Tuesday’s meeting and add the action items to my task list.” You have connected a document server and a task server. Here is what happens, in plain terms.

sequenceDiagram
  participant U as You
  participant H as Claude host
  participant M as Model
  participant D as Document server
  participant T as Task server
  U->>H: Your request
  H->>M: Request plus list of available tools
  M-->>H: Please call the document search tool
  H->>U: Ask for permission if needed
  U-->>H: Approve
  H->>D: Search for last Tuesday's notes
  D-->>H: Matching notes
  H->>M: Notes returned as context
  M-->>H: Please call the task creation tool
  H->>T: Create tasks from action items
  T-->>H: Tasks created
  H->>M: Confirmation
  M-->>H: Final answer for you
  H->>U: Summary of what was done
    

Step by step

Two points deserve attention. First, the model never reaches the document or task systems directly. It only asks the host, and the host talks to servers. Second, everything returned by a server becomes part of the text that the model reads. This is why trusting the server matters, a theme we will return to in the security chapters.

What can go wrong along the way

A request passes through many hands, and each hand is a place where something can fail. The model might choose the wrong tool. The inputs might be incomplete. The server might be slow or return an error. The result might be too long to be useful. A good host and a good server expect these troubles. They show clear messages, let the model try again with better inputs, and avoid repeating the same failing call. As a user, you can help by describing your request clearly, naming the service you mean, and saying what a good result looks like.

Why the host stays in the middle

It might seem simpler to let the model talk to servers directly, but keeping the host in the middle is a deliberate choice. The host can enforce your permissions, show approvals, hide secrets from the model, record what happened, and cut off a server that behaves badly. This central position is what makes it possible to combine many servers without trusting each of them completely.

MCP appears in several Claude products, each with its own way to add and manage servers.

Claude is available in several places, and MCP shows up in many of them. The common thread is that each product can act as a host. The differences lie in how you add servers, how approvals work, and what the product is designed for.

Connectors in everyday words

If you are not a developer, you can think of a connector as a permission slip. You tell Claude, “you may look in my calendar” or “you may search my team’s documents”, and you sign in to approve it. After that, when your request needs that information, Claude can fetch it. You stay in control of which connectors exist, and you can turn them off.

Organizations and administrators

On work plans, administrators may decide which connectors are allowed, who can add new ones, and what data they may reach. This is a feature, not an obstacle. It keeps company information inside approved systems. If a connector you want is missing, ask your administrator before looking for workarounds.

Example: one task, three products

Imagine you want help preparing for a client meeting. In the Claude app, you might connect your document store and calendar, and ask for a briefing based on the last three proposals and tomorrow’s agenda. In a coding product, a developer might connect the issue tracker and ask Claude to prepare release notes from closed tickets. In a custom assistant built through the developer platform, a company might connect its customer database so support staff can ask plain-language questions. The same idea of a shared standard powers all three, while the setup and controls differ.

The right choice depends on where your data lives, who needs access, and how much risk you accept.

flowchart TD
  A["I want Claude to reach something"] --> B{"Is it a cloud service with a provided connector?"}
  B -- "Yes" --> C["Use the remote connector and sign in"]
  B -- "No" --> D{"Is it on my own computer?"}
  D -- "Yes" --> E["Use a trusted local server"]
  D -- "No" --> F{"Is it an internal system of my company?"}
  F -- "Yes" --> G["Ask the platform team for an approved server"]
  F -- "No" --> H["Consider building a small server of your own"]
    

The path begins with the easiest option. If a trusted provider already offers a connector for the service, use it. If the data sits on your own computer, a local server is natural. If it is an internal company system, the right route is through the people who manage it, who can provide an approved and monitored server. Only when none of these exist is it worth building your own.

Questions that guide the choice

Besides what servers offer, clients can offer abilities back to servers.

So far we have described servers offering tools, resources, and prompts. MCP also lets clients offer a few abilities to servers. These are optional, and both sides must agree to them during the handshake.

Why these features exist

Each addresses a real need. Sampling lets simple servers use intelligence without managing their own model. Roots keep servers from wandering across your whole disk. Elicitation avoids wrong guesses by asking you directly. In all three cases, the host remains in charge: it decides what to allow, shows you what is happening, and can refuse.

When a remote server touches your accounts, it must know who you are and what you allowed.

Two different questions

Security people separate two questions. Authentication asks: who are you? Authorization asks: what are you allowed to do? A remote MCP server needs answers to both. Typically, you sign in with the service, such as your document provider, and approve a list of permissions. The service then gives the connector a token, which is a kind of temporary pass that proves permission without sharing your password.

Why tokens beat passwords

A token can be limited to certain actions, can expire, and can be revoked without changing your password. If something goes wrong, you cancel that one token. A password, by contrast, opens everything and is hard to take back once copied. MCP’s approach to remote servers builds on widely used web standards for this kind of sign-in, so familiar sign-in screens appear when you connect.

Shared accounts versus personal accounts

Think about whose identity a connector uses. If every person signs in with their own account, each action is traced to a real person, and each person sees only what they are allowed to see. If a team shares one account, everyone may see the same data, and nobody can tell who did what. Personal sign-in is almost always the better choice for tools that read private information or change records. Shared service accounts belong only to narrow, well-monitored jobs.

Connecting an AI to real systems makes it far more useful and also creates new ways for things to go wrong.

Security thinking begins with a simple fact: a server’s output goes into the text that the model reads, and the model can then take actions. That chain is powerful and also exposes risks. The following table lists the main ones in plain language.

Prompt injection in more detail

Prompt injection is the best-known risk. When Claude reads an email, a web page, or a document through a connector, that content might contain sentences written to look like instructions. Claude is trained to treat such content as information to read rather than orders to obey, and hosts add further protections. But no defense is perfect, which is why approvals for actions and care with untrusted sources still matter.

The dangerous combination

Security specialists warn about a combination of three things in one session: access to private data, exposure to untrusted content, and the ability to send information out. When all three meet, an attacker’s hidden instruction in untrusted content could cause private data to be sent away. Reducing any one of the three breaks the chain. You can avoid connecting private data to untrusted content in the same session, or require approval before anything leaves.

flowchart LR
  A["Private data access"] --> D["Risk of leaking data"]
  B["Untrusted content"] --> D
  C["Ability to send things out"] --> D
  D --> E["Break the chain: remove one, or require approval"]
    

Supply chain and update risks

Servers are software, and software has a supply chain: the authors, the packages they rely on, and the places where updates are published. A server that was safe last month can become unsafe if its author is compromised or if it quietly adds new abilities. For this reason, prefer servers with active maintenance and clear change notes, pin versions where you can, and review what a server can do after each update. Treat a surprise change in a tool’s behavior as a reason to pause and check.

Protecting secrets

Servers often need keys or tokens to reach services. Keep these out of chat messages, shared documents, and anywhere the model can print them. Use the secure storage that your host or platform provides, give each key the narrowest rights, and rotate keys on a schedule. If a key may have been exposed, replace it immediately. A leaked key is far easier to replace quickly than to repair the damage it can do.

The best safety feature of MCP is often you, with a clear view of what is about to happen.

Hosts like Claude are designed to keep a person involved where it matters. Before a tool that acts, the host may show you its name and the inputs it will use, and wait for your approval. Some hosts let you approve once, approve for the session, or always allow a trusted tool. Each choice is a trade-off between convenience and control.

A sensible approval policy

Approval fatigue

If you are asked to approve fifty harmless actions, you may start clicking “yes” without reading. Then the one dangerous request slips through. To avoid this, keep the number of connected servers small, allow clearly safe read-only tools to run freely, and save your attention for actions that change things. Good safety design makes the important questions stand out.

If you cannot see what a server is doing, you cannot fix it, secure it, or improve it.

Anyone who runs MCP servers, especially for a team, needs visibility. Without logs and measurements, problems appear as vague complaints such as “Claude seems slow today”. With them, you can say exactly which call failed and why.

What to log

What to measure

Protect the logs themselves

Logs can contain sensitive information, such as file names or message text. Store them securely, limit who can read them, and keep them only as long as needed. Log what you must, and avoid recording secrets such as tokens and passwords.

Reviewing logs with a purpose

Logs are only useful if someone reads them. Set up a small routine: check the error rate once a week, look at unusual spikes in usage, and review any permission changes. When a user reports a problem, start from the log entry for that call. Over time, patterns appear, such as one tool that fails every Monday morning or one team that never uses a connector it asked for. Those patterns guide improvements and show where training or redesign would help.

A well-designed server is easy for the model to understand and hard to misuse.

If you build servers, or choose between them, design quality matters a great deal. A model uses a tool by reading its name and description, so a tool that is clear to a human reader is usually clear to the model as well.

Testing a server before trusting it

Before you rely on a server, test it. Try the tools with harmless data. Ask Claude questions that you know the answer to, and see whether the results match. Try a request that should be refused, such as touching a folder outside the allowed area, and confirm that it is. Look at the approval prompts and see whether they are clear. Testing takes an hour and can reveal confusing descriptions, missing safeguards, or slow responses long before real work depends on them.

Some designs and habits cause trouble again and again.

MCP is powerful, but like every tool it has strengths and costs.

Main trade-offs

When MCP is not the answer

MCP is not needed for every task. If you only want Claude to read a page you can paste, pasting is simpler. If you need a one-time file conversion, upload the file. If a task needs exact, repeatable behavior with no AI judgment, a normal script may be better and cheaper. MCP shines when the assistant must reach changing information or take actions across tools, and when you want that access to be reusable and controlled.

A short list of habits will keep most MCP setups safe and useful.

Common mistakes in one table

Most connection problems fall into a few familiar groups.

A calm method

Work from the outside in. First, confirm that the service itself works when you use it directly. Second, check that the connector is enabled and signed in. Third, check the permissions it was given. Fourth, try a very simple request that must use the tool, such as “list my five most recent documents”. Only then look at more complex causes. This order finds simple faults quickly and avoids chasing complicated explanations for simple problems.

Asking for help well

If you need support, describe the problem in a way that makes it easy to answer. Say which product you use, which connector or server is involved, what you tried to do, what you expected, and what happened instead. Include the exact error message and the time it occurred, and remove any private details before you share a screenshot. A clear report saves days of back-and-forth, and it helps the people who maintain the connector fix the real problem.

Six everyday situations show where MCP earns its place.