What is MCP (Model Context Protocol)?

How MCP works

MCP has three parts: a host (the AI application, like Claude Desktop), one or more clients inside the host (each one a connection to a single MCP server), and the servers themselves (the things exposing tools or data). The host spawns a client per server it wants to talk to; each client speaks the MCP protocol to its server over a single transport.

Each server declares:

• Tools it exposes, with names, descriptions, and JSON-schema argument definitions.
• Resources the model can read (files, database rows, API responses).
• Prompts the host can surface to the user as templated starting points.

At runtime, the client lists available tools to the host, the model decides which to call, the client forwards the call to the server, the server executes, and the result returns to the model’s context window. The protocol is transport-agnostic: stdio, SSE, and streamable HTTP bindings all work.

The design goal was to stop every AI app from reinventing its own plugin system. Build an MCP server once, and it works with every MCP-compatible client.

Why MCP matters

Before MCP, connecting AI tools to external systems meant per-vendor integrations: one plugin format for ChatGPT, another for Claude, custom work for every IDE. Each integration was throwaway work that rarely transferred.

MCP collapses this into one protocol. A database server, a filesystem server, or an internal knowledge-base server can be written once and used across tools. That matters for three reasons:

• Context portability: the same context follows the user across AI tools instead of being trapped in one vendor’s walled garden.
• Ecosystem leverage: a community server for a SaaS product benefits every MCP-compatible client simultaneously.
• Separation of concerns: the AI product focuses on reasoning; the server focuses on domain data and tool surface.

Common misconceptions about MCP

• “MCP fixes context.” It standardizes the transport. What comes through still needs to be designed: how big are responses, are they structured, is scope enforced per user? The most common MCP production failures are context engineering problems.
• “MCP is a security layer.” Authentication scopes who can call a tool. It does not validate what the tool returns. Tool descriptions and external content both enter the context window as trusted input unless you add your own perimeter.
• “Bigger tools are better tools.” An MCP tool that returns a 50KB raw API payload will blow out the context window on a single call. Shaping outputs, paginating, and summarizing at the server is usually the difference between a useful tool and an expensive one.
• “MCP replaces OpenAPI.” It doesn’t. MCP is how AI clients call tools. OpenAPI is how humans document REST APIs. Many MCP servers wrap OpenAPI endpoints, but MCP adds the affordances LLMs need (descriptions optimized for tool selection, typed responses, discovery).

MCP and Wire

Every Wire container ships with an MCP server. You get five built-in tools (wire_explore, wire_search, wire_navigate, wire_write, wire_delete) plus any custom tools generated from your container’s content. Connect any MCP client (Claude Desktop, Cursor, Cline) by pointing it at {org-slug}.mcp.usewire.io/container/{id}/mcp. The server handles auth via OAuth 2.1 with RFC 8707 resource indicators, enforces per-tool visibility, and shapes responses to keep context compact. You author context; Wire exposes it as MCP.