Every AI assistant that does useful work needs access to business systems: a ticketing tool, a CRM, a document store, an internal API. Before the Model Context Protocol (MCP), each assistant and each AI product had its own way of defining those integrations, so connecting five systems to three assistants meant fifteen integrations. MCP is an open protocol that standardises the connection: you expose a system once as an MCP server, and any MCP-compatible client (desktop assistants, IDEs, agent frameworks, your own applications) can use it.
This post explains the architecture, what a tool definition looks like, what changed in recent spec revisions, and the security and governance questions an enterprise should settle before connecting assistants to production systems.
Architecture: hosts, clients and servers
- Host: the AI application the user interacts with, such as a desktop assistant, an IDE, or your own agent service.
- Client: the component inside the host that maintains a connection to one MCP server.
- Server: a program that exposes capabilities from some system (a database, a SaaS API, a file store) using the protocol.
Messages are JSON-RPC 2.0. The specification is versioned by date, and both sides state which protocol version they speak, so clients and servers built against different revisions can detect mismatches.
Server primitives
| Primitive | Controlled by | Purpose | Example |
|---|---|---|---|
| Tools | The model (with host approval policies) | Functions the model can call to take actions or fetch data | create_ticket, get_invoice |
| Resources | The application or user | Read-only context identified by URI that the host can attach | A file, a schema, a record |
| Prompts | The user | Reusable prompt templates the user can select | "Summarise this incident" |
In practice, tools carry most of the value for enterprise integrations, and they are also where most of the risk lies.
Transports
- stdio: the host launches the server as a local subprocess and talks over standard input and output. Typical for developer tools and desktop assistants accessing local resources. Credentials come from the local environment.
- Streamable HTTP: the server runs as a remote service; clients send JSON-RPC messages via HTTP POST, and servers can stream responses. This is the transport for shared, centrally operated enterprise servers. The older HTTP+SSE transport is deprecated.
For remote servers, the specification defines an authorization model based on OAuth 2.1: the MCP server acts as an OAuth resource server, and clients obtain tokens from your authorization server. This means MCP access can sit behind the same identity provider, SSO and scopes as your other internal services.
Defining a tool
A server advertises tools in response to tools/list. Each tool has a name, a description written for the model, a JSON Schema for its input and, optionally, an output schema and behavioural annotations.
{
"name": "search_open_tickets",
"title": "Search open support tickets",
"description": "Search open support tickets for a customer account. Use when the user asks about a customer's current issues. Returns at most 20 tickets, newest first. Returns an empty list if none are open.",
"inputSchema": {
"type": "object",
"properties": {
"account_id": {
"type": "string",
"description": "Customer account ID, e.g. ACC-10442"
},
"priority": {
"type": "string",
"enum": [
"low",
"normal",
"high",
"urgent"
]
},
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 20,
"default": 10
}
},
"required": [
"account_id"
]
},
"annotations": {
"readOnlyHint": true,
"openWorldHint": false
}
}When the model decides to use it, the client sends a tools/call request and the server returns content for the model, optionally with structured data matching an output schema:
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"resultType": "complete",
"content": [
{
"type": "text",
"text": "2 open tickets for ACC-10442: TKT-9921 (high) Billing address mismatch; TKT-9874 (normal) Invoice PDF missing"
}
],
"structuredContent": {
"tickets": [
{
"id": "TKT-9921",
"priority": "high",
"subject": "Billing address mismatch"
},
{
"id": "TKT-9874",
"priority": "normal",
"subject": "Invoice PDF missing"
}
]
},
"isError": false
}
}The design advice from AI agents in the enterprise applies directly: task-shaped tools, precise descriptions, tight schemas, small outputs, and separate tools for reading and writing.
What changed in recent spec revisions
MCP has evolved quickly, and teams building servers should target a specific revision deliberately. The 2026-07-28 revision is the most significant change so far for people running servers at scale:
- Stateless protocol. The
initializehandshake and theMcp-Session-Idheader are gone. Each request carries its protocol version and client capabilities in_meta, and servers implementserver/discoverto advertise supported versions and capabilities. Remote servers can now sit behind ordinary load balancers without sticky sessions. - Deprecations: the Roots, Sampling and Logging features are deprecated, with a published minimum twelve-month deprecation window. OAuth Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.
- Results carry a `resultType`, and a multi round-trip pattern replaces server-initiated requests when a server needs more input from the client.
- An extensions framework for optional capabilities outside the core protocol, with long-running tasks moved into an official extension.
Official SDKs handle most of this, so the practical step is to pin SDK versions, read the changelog for each revision you adopt, and test against the clients your users actually run, since client support for new revisions arrives at different times.
Security and governance
MCP makes connecting an assistant to a system easy, which is precisely why it needs governance. The main risks:
- Untrusted servers. A third-party server's tool descriptions and outputs go straight into the model's context, and can contain instructions that steer the model (sometimes called tool poisoning). Maintain an allow-list of approved servers and review them like any other software dependency.
- Over-broad credentials. A server holding an admin API key gives every connected assistant admin access. Use the authorization flow so each call runs with the user's own scopes.
- Cross-server data movement. An assistant connected to both your CRM and an external messaging server can be manipulated into moving data between them. See the prompt-injection section of AI data privacy and governance.
- Local servers on laptops. stdio servers run with the user's local privileges. Decide which are permitted on managed devices.
A common enterprise pattern is a central MCP gateway or registry: approved servers are registered once, authentication goes through the corporate identity provider, every tool call is logged with the user's identity, and write tools can require confirmation. That gives security teams one place to apply policy instead of auditing each assistant's configuration.
When to build an MCP server, and when not to
- Build one when several assistants or AI products need the same system, or when you want users' existing assistants to work with your internal tools.
- Skip it for a single application with a fixed integration, where a direct function-calling implementation is simpler and has fewer moving parts.
- Wrap retrieval as a tool to expose a governed document search to any assistant; see RAG for enterprise documents.
- Evaluate it like any other component: tool-selection accuracy and output quality belong in your eval suite.
Watch context cost too. Every connected server's tool definitions occupy the model's context on each request, so connecting dozens of servers with hundreds of tools degrades tool selection and raises spend. See LLM cost control.
Key takeaways
- MCP standardises how assistants reach tools, resources and prompts: integrate once, use from many clients.
- Use Streamable HTTP with OAuth-based authorization for shared enterprise servers, and target a specific spec revision.
- The 2026-07-28 revision makes the protocol stateless and deprecates several features; check SDK and client support.
- Govern servers centrally: allow-list, user-scoped credentials, logging and confirmation for writes.
HashTech builds MCP servers and integrations for internal systems as part of its AI enablement work.
