What Is the Model Context Protocol (MCP)?

Why a protocol won the tool layer

Before MCP, every agent product had its own plugin format, and every tool builder chose which vendors to support. The protocol inverted that: build one server, and Claude Code, Cursor, Copilot, and every other compatible host can use it. Tool investment stopped being vendor-locked, which is why the tool layer became an ecosystem.

How it works, briefly

An MCP server exposes capabilities in three shapes: tools (functions the agent can call, with typed schemas), resources (data the agent can read), and prompts (reusable templates). The host connects, reads the schemas, and the agent selects tools by matching their descriptions against the task.

That last sentence carries a design consequence: tool descriptions are prompts. Agents choose and use tools by reading them, so a vague description produces misuse the same way a vague skill trigger produces non-use. The reference servers are worth reading purely as examples of description craft.

The security frame

An MCP server is code your agent executes, with whatever permissions the server holds. Adopting one is a dependency decision and a security decision at once:

• Prefer first-party. github/github-mcp-server inherits GitHub's auth and scoping; a community equivalent inherits its author's weekend.
• Scope the credentials. A server holding a broad token makes the agent exactly that powerful, including when injected.
• Treat aggregator lists as discovery, not vetting. The largest MCP list has thousands of entries and no security review; that combination is fine only if you supply the review.

Tools versus skills

The recurring confusion, settled by the stack: tools act on the world, skills teach procedures. An MCP server gives your agent the ability to control a browser; a QA skill teaches it what to check and when to be suspicious. Capability without procedure produces enthusiastic misuse; procedure without capability produces essays. Mature setups pair them: the skill's instructions name the tools they expect.

Adopting well

1. Start from the need: which verification loop or workflow is blocked on a missing capability?
2. Prefer first-party or reference servers; read the code of anything community-built.
3. Check the permission footprint against the task's actual needs, per your governance checklist.
4. Wire it, then teach it: add or update the skill that tells the agent when and how to use the new capability.

The scored tool collections in the index are the shortlist worth starting from.