# What is MCP? The Model Context Protocol for platform teams

URL: https://infro.io/blog/what-is-mcp
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-20
Last modified: 2026-10-20
Last reviewed: 2026-10-20 (next review due 2026-11-19)
Topic: Agents and multimodal systems
Format: Guide

> The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. A host application (such as Claude, ChatGPT, Cursor or VS Code) runs MCP clients that connect to MCP servers; servers expose tools (functions the model can call), resources (data) and prompts (templates), over JSON-RPC 2.0. The current specification, 2026-07-28, makes the protocol stateless, with every request carrying its own protocol version and capabilities, and defines OAuth-based authorization for HTTP transports. Because tools amount to code execution on someone's behalf, MCP needs consent, scoped credentials, an allowlist of servers and tools, and an audit trail.

Key takeaways:
- MCP is an open standard connecting AI applications (hosts) to external systems through servers that expose tools, resources and prompts.
- Messages are JSON-RPC 2.0; the 2026-07-28 specification makes MCP stateless, with protocol version and capabilities on every request.
- HTTP-based servers should use the specification's OAuth-based authorization; stdio servers take credentials from the environment.
- The specification's own security principles: explicit user consent, data privacy, and treating tools as arbitrary code execution.
- Govern MCP like any integration: approved servers, scoped credentials, tool allowlists, and a record of every call.

**What is MCP?** The Model Context Protocol is an open-source standard for connecting AI applications to external systems[1]. An AI application — the **host**, such as Claude, ChatGPT, Cursor or VS Code — runs **clients** that connect to MCP **servers**, and each server exposes **tools** the model can call, **resources** it can read and **prompts** users can pick, over JSON-RPC 2.0 messages[2]. The project's own analogy is a USB-C port for AI applications: one standard connection instead of a custom integration per app and per system[1].

For platform and security teams, MCP is both a simplification and a new surface. Every MCP server is a path by which a model can read data or take actions. This guide explains the protocol in plain terms and the controls it needs.

## The pieces

| Part | What it is | Example |
| --- | --- | --- |
| Host | The AI application that initiates connections | Claude, ChatGPT, Cursor, an internal agent |
| Client | A connector inside the host, one per server | The host's connection to your ticketing server |
| Server | A service that provides context and capabilities | A server wrapping your issue tracker's API |
| Tools | Functions the model can execute | `create_ticket`, `search_orders` |
| Resources | Context and data for the user or the model | A document, a table, a file |
| Prompts | Templated messages and workflows for users | "Summarise this incident" |

Table: From the MCP specification overview, version 2026-07-28.

Clients can offer features back to servers too: elicitation (a server asking the user for more information), sampling and root directory lists[2][3]. Optional extensions add more, such as Tasks for long-running operations and MCP Apps for interactive UI rendered inside a conversation; extensions are opt-in and negotiated by both sides[2].

The specification names the Language Server Protocol as its inspiration: LSP standardised how editors support programming languages, and MCP standardises how AI applications gain tools and context[2].

## How a request works

All messages follow JSON-RPC 2.0: requests with an id and a method, responses with a result or an error, and one-way notifications[3]. A tool call looks like this:

```json
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_orders",
    "arguments": { "customer_id": "cust_42", "status": "open" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}
```

### Stateless since 2026-07-28

The current specification defines MCP as a stateless protocol: "all the information needed to process a request is contained in the request itself." Servers must not rely on earlier requests on the same connection for capabilities, protocol version or client identity; each request carries its protocol version and client capabilities in `_meta`, and state that spans requests must be referenced by an explicit identifier[3]. For operators this is good news: MCP servers behave like ordinary stateless services, which makes them easier to scale, load-balance and put behind a gateway.

The specification also introduces a `resultType` on results (`complete`, or `input_required` when a server needs more from the client), multi round-trip requests for sampling, elicitation and roots, and a reserved range of MCP error codes[3].

### Authorization

For HTTP-based transports, implementations should follow the specification's authorization framework, built on OAuth; stdio servers, which run locally, should take credentials from the environment instead[3]. In practice: remote servers sign users in through an OAuth flow, and local servers read keys from environment variables the user provides.

## The security model, in the specification's own words

The specification lists three principles[2]:

1. **User consent and control.** Users must explicitly consent to and understand all data access and operations.
2. **Data privacy.** Hosts must obtain explicit consent before exposing user data to servers, and must not transmit resource data elsewhere without it.
3. **Tool safety.** "Tools represent arbitrary code execution and must be treated with appropriate caution," descriptions of tool behaviour should be considered untrusted unless obtained from a trusted server, and hosts must obtain consent before invoking any tool.

It is also explicit that the protocol "cannot enforce these security principles at the protocol level"; implementors should build consent and authorization flows, access controls and data protections[2]. Those responsibilities fall on whoever deploys MCP in a company.

## Governing MCP in an organization

Treat each MCP server as an integration with the access of whatever credential it holds:

- **An approved list of servers.** Which servers employees and agents may connect to, and who owns each.
- **Scoped credentials.** A server should hold a credential with the least privilege its tools need; a read-only search tool should not run on an admin token.
- **Tool allowlists.** Many servers expose more tools than a team needs. Allow only those, especially for write actions.
- **Untrusted descriptions.** Tool descriptions and results are input to the model and can carry injected instructions. [Prompt injection defense in depth](https://infro.io/blog/prompt-injection-defense-in-depth) applies to every tool result.
- **A record of every call.** Which user or agent called which tool on which server, with what outcome — the audit trail a security review will ask for.
- **Token cost.** Every tool definition a host loads is input on every turn; large tool lists are a measurable cost. [MCP vs CLI token overhead](https://infro.io/blog/mcp-vs-cli-token-overhead) quantifies it.

A central MCP gateway puts those controls in one place: one entry point that holds server credentials, enforces allowlists and records calls, instead of a configuration on every laptop. [MCP gateway: one governed entry point](https://infro.io/blog/mcp-gateway-govern-agent-tools) covers the pattern, and [MCP and tool calling in production](https://infro.io/blog/mcp-tool-calling-production) the failure modes.

## Building or adopting an MCP server: a checklist

Whether you write a server or connect a vendor's, check the same things before it reaches production:

- [ ] **Transport.** A remote server over HTTP should use the specification's authorization; a local stdio server should read credentials from the environment, never from a file in the repository.
- [ ] **Credential scope.** The token the server uses against the underlying system has only the permissions its tools need, and belongs to a service account you can rotate.
- [ ] **Tool design.** Read tools and write tools are separate, write tools have names and descriptions that make their effect obvious, and destructive actions ask for confirmation.
- [ ] **Output size.** Tools return the fields the model needs, not whole records; a tool that returns 50 KB per call costs tokens on every turn that follows.
- [ ] **Version.** The server declares the protocol version it implements; clients on older versions are handled, since the 2026-07-28 revision changed how requests carry their metadata.
- [ ] **Logging.** Every call is logged with the caller, tool, arguments' shape and outcome, with sensitive values redacted.
- [ ] **Owner.** Someone is named as owner, and there is a way to disable the server quickly.

> **Example: A read-only server done right**
> An internal "orders" server exposes two tools, `search_orders` and `get_order`, both read-only, backed by a database role that can only select from two views. Results return order id, status and dates — no payment details. Calls are logged with the requesting user. A separate `refund_order` tool lives on a different server, approved only for the support team's agent, with a confirmation step.

## INFRO and MCP, in two directions

INFRO uses MCP both ways. **The INFRO MCP server** lets an assistant such as Claude or Cursor read and manage your INFRO organization — usage, findings, budgets, routes — with OAuth sign-in and permissions chosen per area, or with a management token. **The INFRO MCP gateway**, on the Business plan, is a governed entry point to your own MCP servers: owners and admins review each tool's full definition before approving it, a definition that changes after review is refused until it is approved again, a server or all tool traffic can be switched off in one action, and approvals, blocks and changes are written to the audit log. Both follow the same rule as the rest of INFRO: your credentials, scoped access, and a record of who changed what.

## Summary

MCP is the standard way for AI applications to reach tools and data: hosts run clients, clients connect to servers, servers expose tools, resources and prompts, now over a stateless protocol with OAuth-based authorization for remote servers. The specification states the security principles but cannot enforce them, so organizations need approved servers, scoped credentials, tool allowlists and an audit trail.

## Questions

### What is MCP in AI?

The Model Context Protocol is an open-source standard for connecting AI applications to external systems. An AI application such as Claude, ChatGPT or Cursor connects to MCP servers, which expose tools the model can call, resources it can read and prompt templates, so one integration works across every application that supports MCP.

### What is the difference between an MCP server and an API?

An MCP server usually wraps an API. The API is designed for programs written by people; the MCP server describes that capability as tools, resources and prompts in a standard form a model can discover and call, with schemas, descriptions and the protocol's authorization and consent model around it.

### Is MCP secure?

The protocol cannot enforce security by itself. Its specification says tools represent arbitrary code execution, that hosts must obtain explicit user consent before invoking a tool and before exposing user data, and that tool descriptions should be treated as untrusted unless the server is trusted. Security comes from how hosts, servers and your organization implement those principles.

### What changed in the 2026-07-28 MCP specification?

It defines MCP as a stateless protocol: each request carries the information needed to process it, including protocol version and client capabilities in its _meta field, and servers must not rely on prior requests on the same connection. It also adds structured result types, multi round-trip requests and error codes reserved for the specification.

## Sources

1. What is the Model Context Protocol (MCP)? — Model Context Protocol. https://modelcontextprotocol.io/docs/getting-started/intro (accessed 2026-10-20)
2. Specification — Model Context Protocol. https://modelcontextprotocol.io/specification/latest (accessed 2026-10-20)
3. Base protocol overview (2026-07-28) — Model Context Protocol. https://modelcontextprotocol.io/specification/2026-07-28/basic (accessed 2026-10-20)