Agents & tools

MCP (Model Context Protocol)

Also called: Model Context Protocol

MCP is an open standard for connecting agents to tools and data. Instead of hard-coding an integration into every agent, you run an MCP server once and any MCP-aware agent can use it.

James Phoenix
Understanding Data Updated July 2, 2026

Every agent needs tools, and for a while everyone built those tools in a different, incompatible way. The Model Context Protocol fixes that. It is a shared wire format for how an agent discovers and calls tools, reads resources, and uses prompts. Write an MCP server once and it works in any client that speaks MCP, the same way any browser can talk to any website over HTTP.

Think of it as a USB-C port for agents. The port is standard, so what you plug in, a database, a ticketing system, your internal docs, does not need a bespoke adapter for each agent.

A minimal server

An MCP server exposes capabilities. The most common is a tool: a named action with a typed input schema and a handler. Here is a complete server that offers one tool over stdio, using the TypeScript SDK.

TypeScript
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'

const server = new McpServer({ name: 'changelog', version: '1.0.0' })

server.registerTool(
  'get_release_notes',
  {
    title: 'Get release notes',
    description: 'Return the changelog entry for a given version tag',
    inputSchema: { version: z.string().describe('e.g. v2.4.0') },
  },
  async ({ version }) => ({
    content: [{ type: 'text', text: `Release notes for ${version}...` }],
  }),
)

// stdio is the transport a local agent launches and talks to over a pipe.
await server.connect(new StdioServerTransport())

When an agent connects, it asks the server what it offers, sees get_release_notes and its input schema, and can then call it exactly like a built-in tool. The agent never needs to know how the changelog is stored.

Why it matters

  • Write once, use everywhere. One server serves every MCP-aware agent, so integrations stop being N-times work.
  • The agent stays lean. Capabilities live behind the protocol rather than baking into the harness, which keeps the context window and the toolset manageable.
  • Clear boundaries. A server declares exactly what it exposes, which makes permissions and auditing far easier than ad-hoc integrations.
Note
MCP defines three main capability types: tools (actions the agent can invoke), resources (read-only data the agent can pull in), and prompts (reusable templates). Tools get the most attention, but resources are what let a server feed real context to the model.

Related terms

Building with AI agents?

This dictionary is part of how I think about agentic engineering. If you want the same thinking applied to your codebase, that is what I do.

See how I can help