Model Context Protocol (MCP)

Model Context Protocol, or MCP, gives compatible AI applications a shared way to connect to outside data and tools. If several AI products need your CRM, files, or calendar, that can save you from building the same connection for each one.

But you still have to decide which records the AI may read, which actions need approval, how you’ll check the result, and who fixes a failed run. MCP gives the applications a way to connect, it doesn’t make those decisions for your firm.

Anthropic introduced MCP on November 25, 2024. The specification referenced here is dated November 25, 2025, and the project’s March 9, 2026 roadmap said no newer specification release had shipped at that point.

The connection has a host application, a client inside that host, and a server that makes data and actions available. The server can offer resources to read, tools to take actions, and prompts with instructions you can reuse.

How does MCP work?

The host is the AI application you use, and it creates a client connection to each MCP server. Through that connection, the server describes the data and actions it makes available.

The November 2025 MCP specification uses a message format called JSON-RPC 2.0 for that conversation. What matters for your work is that a compatible AI application can ask the server what it offers, read the descriptions and input rules, and use an allowed function without a new custom connection for each task.

Imagine a project assistant with one MCP server that offers an approved client record and another that can create a task in the project system. The assistant can read the record, draft a follow-up, and ask to create the task.

MCP defines how those functions are described and called, but your firm decides which accounts the user can reach, whether creating the task needs approval, and what proves the right task was created. You also need to decide who handles a failed call, because making an action easy to request doesn’t tell you whether it belongs in the process.

What can an MCP server expose?

An MCP server can expose tools, resources, and prompts. The project’s July 28, 2026 server guide separates them by who controls their use.

A resource gives the application read-only information, such as an approved project brief or a description of how a database is organized. The application controls how that information is used.

A tool lets the model request a defined action, such as searching the CRM or creating a follow-up task, within the host application’s controls. A prompt is an instruction template the user chooses, for example to prepare a client handoff from approved records.

So calling all three “access” leaves out an important difference, who chooses what happens and whether it can change another system.

Reading an approved project brief is different from sending a client email. Creating an internal draft is different from changing a price. A firm should grant and review those capabilities separately even when one server exposes them.

The host decides what reaches the model, what the model may call, and when a person must approve the call.

What problem does MCP solve for a business?

MCP reduces repeated connection work. A team might build one custom connection from its CRM to one AI product, then build a second version for another. A compatible MCP server can present the same approved capabilities through one maintained interface.

That reuse matters when you have several AI applications or expect to change them. Your CRM search, project lookup, or document resource can stay behind the same server while you switch the application people use.

Developers still have to maintain the server and its connections to your systems, but they can spend less time rebuilding the same connection for another product.

Anthropic’s November 25, 2024 launch described information trapped behind separate systems and named Google Drive, Slack, GitHub, Postgres, and other early server examples. The standard gives those systems a common way to describe what an AI application can use.

A reusable connection does not fix the process behind it. A CRM full of stale stages remains stale. A project process that lives in a manager’s head remains undocumented. A server makes the available system easier for AI to reach. It carries the quality and limits of the system behind it.

Is MCP the same as an API, RAG, computer use, or an AI agent?

MCP sits beside these concepts. Each names a different part of the system.

An API is usually underneath an MCP server. The API defines how software talks to a service. The MCP server can wrap that API and describe selected operations in a form compatible AI hosts can discover. MCP adds a common way for AI applications to use those operations. The API and its authentication rules remain in place.

Retrieval-augmented generation finds evidence and gives it to a model before an answer. MCP can expose the resources or search tools a RAG system uses. It can also expose actions that have nothing to do with retrieval.

Computer-use AI operates a screen with clicks and typing. MCP calls a capability with defined inputs. That path is usually easier to limit and test when the system offers one. Computer use remains useful for old portals and desktop software with no usable API or MCP server.

An AI agent pursues a goal across several steps and may use MCP tools along the way. MCP gives the agent a way to discover and call capabilities. It does not provide the goal, finish test, authority limit, or recovery owner.

Is MCP secure?

An MCP connection is safe only when the host, server, permissions, and operating controls around it are safe. The protocol includes security requirements and guidance. Each firm still enforces those controls around its connected systems.

The specification warns that MCP can open paths to arbitrary data access and code execution. It says users must understand and consent to data access and operations. It also says tool descriptions should be treated as untrusted unless they come from a trusted server. A familiar connector screen does not prove that the server or every action behind it deserves trust.

The project’s July 28, 2026 security guide is direct about local servers. They may run with the same privileges as the client. The guide recommends explicit consent before commands run, minimal default privileges, restricted file and network access, sandboxing, and logs.

For client work, give the connection its own identity and limit it to the clients and records the job needs. Keep permission to read separate from permission to change something.

Put a person at the approval step before a message reaches a client, money moves, scope changes, permissions change, or a record disappears. And keep the call and its result somewhere your firm can inspect them later.

You also need to account for prompt injection, where a document, tool result, or server description contains instructions meant to change what the model does. Treat that content as data, and enforce what the AI is allowed to do through code and permissions rather than trusting a sentence in the prompt.

What should a business check before connecting an MCP server?

Start with one bounded read-only job. A project-status lookup over internal records is a better first test than a server that can email clients and edit the CRM.

Check seven things before production:

1. Publisher: who built the server, who maintains it, and whether the code path is one the firm trusts.
2. Data scope: which systems, clients, folders, and fields the server can reach.
3. Identity: which person or software identity each call uses.
4. Actions: which capabilities read, which write, and which writes require approval.
5. Evidence: what record proves the correct source was read and the correct action happened.
6. Failure path: what happens after a timeout, partial write, wrong result, or denied permission.
7. Owner: who reviews logs, removes stale capabilities, and receives a failed run.

Before expanding access, test the kinds of cases the connection will face, a missing record, two clients with similar names, a permission the user lacks, a document with hostile instructions, a timeout after a write, and a request the server should refuse. Check the final business record rather than accepting the assistant’s word that the job finished.

When should a firm build its own MCP server?

Build one when a repeated internal capability needs to work across several compatible AI applications or workflows, and no trusted server exposes it with the permissions and records the firm needs.

A business may have a project-health calculation that already lives in an internal API. Wrapping that capability once can make sense when several assistants and workflows need it. The server becomes the maintained connection around that business function.

Use an existing server when you trust its publisher and its permissions, actions, and logs meet your needs. Building your own means maintaining code, protecting credentials, following security updates, and handling failures, so count that work before choosing it.

The shared protocol can save you from building a connection twice, but someone still has to keep that connection running.

Skip MCP for a one-off task that works with a manual file and needs no repeated connection. A twelve-person firm with one assistant and one simple lookup may gain little from adding another service to operate. Build after the repeated connection becomes the constraint.

Where does MCP sit on the Delivery Model Ladder?

MCP usually enters at Stage 1 or Stage 2 of the Delivery Model Ladder.

At Stage 1, Enhanced, a person deliberately starts an MCP-connected assistant, watches the result, and carries it into the next system. The connection makes the person faster. The person still holds the workflow together.

At Stage 2, Augmented, MCP capabilities sit inside a delivery workflow. The system starts from a defined trigger, uses approved context and actions, checks the result, records what happened, and routes a failure to a named person. The connection then becomes part of an AI employee, rather than another tool an individual opens.

MCP doesn’t move your firm up the Ladder on its own. Start with one read-only function, check its permissions and the evidence it leaves, then add one change you can undo, with your firm still responsible for the rules around it.