What Is MCP? Model Context Protocol Explained Simply

Why this matters now: MCP became the default way to give agents tools, and most of the agent work covered on this site sits on top of it. Point Claude Code at infrastructure code or let an agent migrate an EC2 workload to ECS and the protocol underneath is the same. This piece is the plain version: the architecture, a working demo, and where MCP sits next to ordinary APIs.

Three takeaways:

The mental model is small. Hosts are the applications a user talks to (Claude Desktop, IDEs, custom agents) and they own permissions and user interaction. Clients keep a one-to-one connection to each server and speak JSON-RPC 2.0. Servers expose three capability types: tools the model can call, resources it can pull into context, and prompt templates that guide how both get used.
MCP complements APIs by standardizing how a model discovers and calls capabilities. A client can ask a server what it offers at runtime, so agents pick up new tools without being rebuilt against fixed endpoints. That discovery step is what makes agent tooling composable, and it is why vendors from GitHub to AWS to Spacelift now ship their own servers.
Getting started is cheap and security is the catch. The demo is a .vscode/mcp.json file, a Perplexity server and VS Code agent mode, with the API key prompted for at first use. A working server takes an afternoon, so build one before forming an opinion about the protocol. Then treat every server you install like a dependency with production access, because prompt injection and tool abuse are the pressing risks the article calls out.

**What I’d add today: The 2026-07-28 specification brings a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs.

Who should read it: engineers wiring agents to real systems, teams deploying agentic solutions with IaC, and anyone who keeps hearing MCP in meetings and wants the plain version.