Model Context Protocol (MCP)

What it is

MCP defines how an AI application talks to the systems around it. The specification names three roles. The host is the AI application, such as Claude Code. The host creates one client per connection. Each client talks to one server, a program that offers capabilities. A server can offer three kinds of thing: tools (functions the model can call), resources (data the model or the person can read) and prompts (reusable templates).

Messages are JSON-RPC 2.0. Two standard transports carry them: stdio, for a server running as a local process, and Streamable HTTP, for a remote MCP server. The project describes MCP as a USB-C port for AI applications: one plug shape instead of a custom cable for every device.

Why it matters

Before MCP, every agent framework described tools its own way, so every integration was written again for every framework. With MCP, a system that publishes an MCP server works with any MCP client that speaks a compatible revision. The integration work moves from once per framework to once per system.

How it works

1. The client connects and learns the server's capabilities and protocol version.
2. It asks for the list of tools (tools/list). Each MCP tool has a name, a description and a JSON Schema for its input.
3. The model picks a tool, and the client sends tools/call with arguments.
4. The server runs it and returns content, or a result marked isError that the model can read and correct.

The protocol is versioned by date. The current revision is 2026-07-28, which made each request self-describing and removed protocol-level sessions. Servers and clients built on earlier revisions, such as 2025-11-25 and 2025-06-18, remain in use, and the specification describes how the two eras detect each other and fall back.

Example

A support agent connected to a ticket desk's MCP server lists that server's tools, finds one that creates a ticket, reads its schema, and calls it with a title and a priority. Nobody wrote code for that vendor inside the agent.

Common pitfalls

• Assuming MCP adds security. The specification says the protocol cannot enforce its own security principles; consent, access control and logging are left to implementers.
• Trusting tool descriptions. The specification tells clients to treat tool annotations as untrusted unless they come from a trusted server.
• Connecting many servers at once. Every server adds tool definitions to the model's context. See tool overload.

How actionlake handles it

The actionlake endpoint is one remote MCP server at https://connect.actionlake.com/mcp. It speaks Streamable HTTP on every current revision: 2026-07-28, with per-request metadata and server/discover, and the handshake revisions 2025-11-25, 2025-06-18 and 2025-03-26. Behind it sit 1,000+ connectors and 289,000+ actions (counted from our service files, 24 October 2026), reached through eight fixed tools. MCP is the road; actionlake adds what the protocol leaves to implementers: a credential vault, per-key permissions, spending caps, human approvals and a hash-chained ledger. Read how the pieces fit on the platform page, or connect a client with the quickstart.