Anthropic introduced the Model Context Protocol, or MCP, on November 25, 2024.1 The open protocol gives AI applications and the systems they connect to a common interface.
That’s a worthwhile idea. Instead of inventing a different connection pattern for every assistant and data source, developers can build MCP clients and servers that speak the same language.
It is rather like agreeing on how the microphones connect in a recording studio. Very helpful. It does not mean the drummer has learned the song, the cables belong in every room or someone should immediately broadcast the rehearsal.
For a business considering an AI assistant, the opportunity is more reusable connections. The work around trustworthy information, permissions and useful behavior remains.
Try one bounded information task
Let’s use a fictional support team that wants help answering questions from approved product documentation. The first experiment could let an assistant find the relevant policy and explain it to a staff member.
It would not need access to payments, customer exports or order changes. Starting with those because the connector happens to support them would be an ambitious interpretation of “find the manual.”
Separate the interface from the underlying service
An MCP server exposes capabilities to a compatible client. Behind that interface, the server may still need to call an existing API, query a repository or retrieve a document.
Those systems retain their own formats and business rules. If one product catalog uses discontinued codes or two policy folders disagree, the common protocol does not resolve the conflict.
The team still has to decide which information is authoritative and how it is kept current. “It came through MCP” is a statement about the connection, not a certificate of truth.
At launch, Anthropic highlighted local server support in Claude Desktop and shared example connectors. That is a starting point for experiments, rather than proof that every organization already has a complete production deployment model.
We build AI agents with clear jobs and sensible limits. See how.
Test a question with an inconvenient answer
Begin with a real support question and identify the document that should answer it. Then try a question where the right response is uncertainty or a handoff.
Suppose the customer asks whether an old accessory works with a newly listed product. If the approved documentation does not establish compatibility, the assistant should say that. A confident guess is still a guess, even after being transported through a beautifully standardized connection.
Retrieval quality matters here. Search methods, including embeddings that represent semantic similarity, can help locate related material. Related material isn’t necessarily the correct version or an adequate answer. Keep the source and its date visible to the person reviewing the response.
Decide what the assistant is allowed to do
The initial support task helps clarify the next decision. Should the assistant only retrieve information, draft an answer or carry out a business action?
These are different levels of authority. Reading a returns policy and approving a refund should not become equivalent because both appear as available tools.
Keep permissions outside the model’s judgment
The connected services should enforce access rules for the actual user and operation. The assistant must not be able to widen its permissions by asking nicely or by repeating something it found in a document.
That document may contain irrelevant or malicious instructions. Prompt injection describes this broader problem of untrusted content trying to influence an AI system’s behavior. A common connection protocol does not make the retrieved text trustworthy.
For our support example, restrict the source set and keep actions out of scope until the reading task works reliably. Where an action is later added, define the permitted inputs, approval conditions and audit record in the application.
Worth reading next: Before giving AI access to the CRM, draw the permission boxes.
Observe a complete interaction before expanding
Save enough of the task history to understand which sources were used, which operations were requested and what the assistant returned, with appropriate handling of sensitive information.
Then review failures as carefully as successful demonstrations. Did the assistant select an obsolete policy? Did the server return an error that the assistant quietly converted into an answer? Could a staff member distinguish a retrieved fact from an inference?
These observations tell the business where more work is needed. Another connector mostly tells it that another connection has been made.
I like MCP’s direction because common interfaces can reduce repetitive integration work. The sensible first win is a narrow task that behaves predictably with real information and honest limits.
Get that working, let the team try it, and expand where the benefit is clear. A tidier plug arrangement is useful. We still need to know what we’re plugging in.