What MCP Actually Standardizes

Model Context Protocol (MCP) defines how an AI application can discover and use capabilities exposed by another program. An MCP host is the application the user runs. It creates a client connection for each server. A server can expose tools that perform actions, resources that provide data, and prompts that offer reusable templates. The model itself is not an MCP client: the host decides what to show the model and whether a requested call is allowed. This distinction matters when you design permissions. The MCP architecture specification defines these roles and boundaries.

A Concrete Example

Suppose a legal research assistant needs to answer, “Which version of this regulation applied on the contract date?” A read-only MCP server could offer a search tool that accepts the regulation name and date, then returns matching document IDs. A resource could return the text and publication metadata for a selected version. The host would ask the user to authorize access, call only the permitted server, and pass the returned passages to the model. The final answer should name the source and effective date and say when the available records are insufficient. This is a design example, not a claim that a particular Hatson Tech product already provides these functions.

MCP describes the exchange between components; it does not guarantee that the retrieved regulation is current, that the model will cite it correctly, or that the user has permission to see it. Those checks belong in the application and data service. RAG may select relevant passages; MCP is one possible way to expose a retrieval capability to the host. They solve different parts of the system.

When MCP Is Worth Using

MCP helps when the same data service or tool must be available to several compatible AI applications. A team can maintain one server interface and connect it to multiple hosts, subject to each host's supported features and authorization. If one application calls one internal API, a direct integration may be simpler. The familiar “N × M becomes N + M” description is an architectural goal, not a guaranteed saving: authentication, schemas, error handling, version compatibility, and user experience still need work. Building an MCP server for internal systems is ordinary integration work, of the kind described on our AI agent development page.

Security Checklist Before Production

  • Start with read-only operations. Separate searches from writes such as sending an email or editing a record. Require explicit approval for sensitive actions.
  • Enforce access at the server. Check the user's identity and document permissions on every request. A model prompt or a tool description is not access control.
  • Limit returned data. Return the relevant passage and source metadata, not an entire private database row or unrestricted file content.
  • Treat results as untrusted. A retrieved document may contain instructions aimed at the assistant. The host must keep source text separate from its own rules and permissions.
  • Log and test. Record tool identity, authorized user, result status, and source IDs without leaking sensitive document contents into logs. Test denied access, stale data, malformed responses, and prompt-injection attempts.

Tool annotations may describe a server's intent, but they are not a security guarantee. The MCP maintainers' explanation of tool annotations makes clear that an untrusted server can mislabel a dangerous action.

Sources