Model Context Protocol (MCP)

Model Context Protocol, or MCP, gives compatible AI applications a shared way to connect to outside data and tools. Anthropic introduced it on November 25, 2024. The current published specification is dated November 25, 2025, and the project’s March 9, 2026 roadmap says no newer specification release has shipped. An MCP connection has a host application, a client inside that host, and a server that exposes capabilities. The server can offer resources for context, tools for actions, and prompts for reusable instructions. This common interface can reduce connector work when a CRM, file store, calendar, or internal system must serve several AI products. MCP ends at the connection boundary. The firm still decides which records the AI may read, which actions need approval, how results are checked, and who repairs a failed run.

How does MCP work?

MCP uses a host, a client, and a server. The host is the AI application a person uses. It creates a client connection to each MCP server. The server describes the data and actions it makes available.

The current MCP specification uses JSON-RPC 2.0 messages for that conversation. For an operator, discovery is the useful part. A compatible AI application can ask a server what it offers, read its descriptions and input rules, and call an allowed capability without a new custom wrapper for each task.

Imagine a project assistant. One MCP server exposes an approved client record. Another exposes a task action in the project system. The assistant can read the record, draft a follow-up, and ask to create the task. The protocol defines how those capabilities are described and called. The firm defines which accounts this user can reach, whether task creation needs approval, what proves the correct task was created, and where a failed call goes.

The server can make an operation easy to call. It cannot decide whether that operation belongs in the delivery 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.

MCP feature	What it provides	Who controls it	Service-firm example
Resource	Read-only context	The application	An approved project brief or database schema
Tool	A function that reads or changes another system	The model, within host controls	Search the CRM or create a follow-up task
Prompt	A reusable instruction template	The user	Prepare a client handoff from approved records

A resource supplies context. A tool performs a defined operation. A prompt gives the user a repeatable way to start work. Calling all three “access” hides the different decisions each one brings to delivery.

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 service firm?

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 a firm has several AI applications or expects to change hosts. The CRM search, project lookup, or document resource can stay behind the server while the AI application changes. Developers still maintain the server and its underlying integrations. They 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.

Translate that into client work. Give the connection its own identity. Limit it to the clients and records needed for the job. Separate reads from writes. Put a person before a message reaches a client, money moves, scope changes, permissions change, or a record disappears. Record the call and result where the firm can inspect them later.

Prompt injection remains part of the threat. A document, tool result, or server description may contain instructions intended to change the model’s behavior. Treat retrieved content as data. Put authority in code and permissions rather than in a sentence telling the model what to do.

What should a service firm 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.

Run representative cases before expanding access. Include a missing record, two clients with similar names, a permission the user lacks, a poisoned document, a timeout after a write, and a request the server should refuse. Score the final business record, not the assistant’s claim 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 service firm 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 its publisher, permissions, actions, and logs meet the firm’s requirements. A custom server creates code to maintain, credentials to protect, security updates to follow, and failures to own. The shared protocol reduces duplicated integration work. It does not remove the work of operating the connection.

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 does not move a firm up the Ladder by itself. Start with one read-only capability, prove the permissions and evidence, then add one reversible write. The connector can be shared. The operating contract stays with the firm.