MCP Servers — Connection Layer: Plugging Claude into External Tools and Data

So far, our agent has memory, expertise, control, delegation, and distribution methods. But it still lacks one thing to truly operate in a business: connection to the outside world — GitHub, databases, CRM, Google Drive, Slack, reporting systems. An agent that cannot access real data will always remain theoretical.

That is the role of MCP (Model Context Protocol) — the connection layer in the toolkit. In the diagram, MCP Servers are on one side and connect to all other layers, as it is the bridge of capability.

What is MCP

MCP is an open standard that enables AI agents to connect with external tools and data sources — without having to write custom integrations for each service. Anthropic introduced MCP in November 2024 (Anthropic — Introducing MCP). Its role in the toolkit is very clear: **to add capability** — different from skills (teaching how to do), subagents (maintaining context), or hooks (ensuring determinism).

A concise way to remember: MCP connects and provides data; Skills teach Claude what to do with that data (Anthropic — Skills explained).

An important point: MCP is an open standard, not proprietary to Anthropic — many other applications and models also share it, so an MCP server you write can be reused in many places.

Client–Server Architecture

MCP follows a client–server model. An MCP server exposes three types of things to the agent (modelcontextprotocol.io — Server concepts):

Tools — functions that the model can call (e.g., "create an issue on GitHub", "query a database").
Resources — data that the model can read (e.g., the content of a file, a record).
Prompts — reusable prompt templates.

Communication uses JSON-RPC 2.0, via stdio (local process) or streamable HTTP (remote service).

Declaring an MCP Server

The quickest way is through the CLI (Claude Docs — MCP):

Bash

# Remote via HTTP (recommended for cloud services)
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Local via stdio (running a process on your machine)
claude mcp add --transport stdio airtable -- npx -y airtable-mcp-server

Or declare it in a .mcp.json file to share by project (can be committed to the repo):

JSON

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": { "Authorization": "Bearer ${API_KEY}" }
    }
  }
}

A few points to remember:

Transport: stdio (local), http/streamable-http (remote, supports OAuth), along with sse/ws.
Scope: local (default, your own), project (.mcp.json, shared via git — needs approval before use), user (all projects).
Tools from MCP appear with names in the format mcp__<server>__<tool>.
Env var expansion in .mcp.json: use ${VAR} and ${VAR:-default} — absolutely do not hardcode tokens/keys; reference through environment variables.

How MCP Connects to Other Layers

This is when the entire toolkit aligns with each other:

A Plugin can package an MCP server (place .mcp.json at the root of the plugin) — enabling the plugin runs the server automatically (see Article 5).
A Hook can call an MCP tool (type: "mcp_tool") or match an MCP tool in the matcher (see Article 3).
A Subagent can limit or add its own MCP servers through frontmatter mcpServers (see Article 4).

Summary statement for the entire series: **Skill changes behavior; Subagent protects context; MCP adds external connection capabilities; Hook ensures deterministic actions; Plugin packages & distributes everything.**

Security

Project scope servers must be approved before use (as they come from the repo, they may have been added by others).
Remote services should use OAuth 2.0 instead of hardcoding tokens.
Organizations can use managed config with a list of allowed/blocked servers (allowedMcpServers/deniedMcpServers).
Always keep tokens/headers in environment variables, do not commit them to the repo.

A Common Misunderstanding

Many people worry that "plugging in multiple MCP servers will stuff hundreds of tools into the context and consume tokens." In reality, MCP has a default tool discovery mechanism — it only loads tools when needed — so you can connect multiple services without excessively bloating the context.

Summary & Next Steps

MCP is the connection layer: an open client-server standard exposing tools/resources/prompts, declared via CLI or .mcp.json, with multiple transports and scopes, and integrates with plugins/skills/hooks/subagents to provide capabilities for the agent. This is the piece that helps the agent break out of the "closed room" and work with real data.

Now you have all six layers. Article 7 — the final article — will put everything together: building a complete "AI employee" for a real business process, and outlining the implementation roadmap.

References

Anthropic — Introducing the Model Context Protocol: https://www.anthropic.com/news/model-context-protocol
Claude Docs — Connect Claude Code to tools via MCP: https://docs.claude.com/en/docs/claude-code/mcp
Model Context Protocol — Server concepts: https://modelcontextprotocol.io/docs/learn/server-concepts
Anthropic — Skills explained (MCP vs Skills): https://claude.com/blog/skills-explained

Article 6/7 in the "Agent Development Toolkit with Claude" series. Content reinterpreted from the original documentation by Anthropic. Previous ← Article 5: Plugins · Next → Article 7: Putting Together.

MCP Servers — Connection Layer: Plugging Claude into External Tools & Data