The simplest way I explain MCP is still the kitchen drawer full of old chargers. Before USB-C, every device needed its own cable. Before MCP, every agent needed its own custom wiring to reach the same tool.
MCP has three pieces.
| Piece | What it does |
|---|---|
| Host | The app the user is in, like Claude Desktop, an IDE, or a custom agent. |
| Client | The connector inside the host. It manages the session. |
| Server | The process that exposes tools, prompts, or resources. |
That sounds abstract until you build one. A GitHub MCP server can expose "list issues" and "open pull request." A database MCP server can expose a safe query tool. A browser MCP server can expose "click this button" and "observe the page." The host does not need custom GitHub code, database code, or browser code. It speaks MCP.
The practical benefit is boring, which is why it matters. You can test the server without a model. You can swap hosts without rewriting your tool. You can put policy around the server instead of hiding rules in a prompt.
MCP is not magic, and it is not always the right interface. If a CLI already solves the job, use the CLI. If the capability is really a workflow, write a skill. But when an agent needs a stateful, typed connection to tools, MCP is the clean place to put that boundary.