What is MCP? A practical guide to the Model Context Protocol.

MCP — Model Context Protocol — is the closest thing the AI agent world has to USB. It's a small, open spec for how an agent talks to tools that live outside its own process. By 2026, the major agents (Claude Code, Cursor, Cline, AZMX AI, Continue, and the long tail) all speak it. If you build agent tooling and you don't ship an MCP server, you don't exist.

The 30-second version

MCP defines a JSON-RPC dialect for an agent (the host) to ask a server "what tools and resources do you expose?" and then to call those tools by name with structured arguments. The server replies with structured results. That's it.

What MCP gets right is the boundary. Tools used to be in-process plugins — every host had its own plugin format, every plugin had to be ported. MCP says: the tool runs in its own process, the wire format is fixed, anyone's host can talk to anyone's tool.

The two transports — stdio vs HTTP

MCP servers expose themselves over one of two transports. Knowing which to pick is the single most useful thing a beginner can learn.

stdio (the local default)

The host spawns the server as a subprocess and talks to it over stdin/stdout. No port, no auth — the operating system already isolated them. This is the right choice for tools that read your filesystem, your git repo, your local SQLite. Latency is zero. Setup is "install the binary."

HTTP (the remote default)

The server listens on a URL. The host connects with bearer auth or OAuth. Use this for shared services — a company-wide MCP that wraps an internal search index, a hosted tool from a SaaS vendor, anything you don't want a thousand engineers installing locally.

AZMX AI supports both. Most agents do.

What an MCP server actually exposes

• Tools. Functions the agent can call. Each has a name, a JSON schema for arguments, and a description.
• Resources. Read-only blobs the agent can attach to context — files, URLs, query results.
• Prompts. Reusable prompt templates the host can offer as slash commands.

Five minutes: wire an MCP server into AZMX AI

Take the official GitHub MCP server as an example. It exposes tools like create_issue, list_pull_requests, and get_pull_request_diff.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
    }
  }
}

Drop that block in the MCP settings and the agent gains every tool the server exposes. The tools show up in the agent's tool list. The approval gate still applies — you'll see the exact call before it fires.

Why MCP changed the game

Before MCP, every agent vendor had to negotiate one-off integrations with every tool vendor. That doesn't scale. With MCP, the slope is now: build a server once, every host can use it. The ecosystem flipped from "platforms with apps" to "protocols with implementations" — which is the same flip the web won with.

The security implication is large. An MCP server is a piece of software running on your machine, with whatever capabilities you grant it. Treat it like an npm package: read what it does, prefer servers from people you'd trust to send a PR to your repo, and prefer hosts (like AZMX AI) that gate destructive tool calls behind a human approval.

Where MCP is going

Sampling (the server calls the model, not the other way around) is landing across hosts. Elicitation (the server asks the host to ask the user something) is next. By the end of 2026, expect MCP to be the default way any non-trivial AI integration ships — the way REST became "just how you build APIs" in the 2010s.

Get started with AZMX AI's MCP support · How approval gates make MCP safe