MCP, Tool Registries & Frameworks

As agents multiply, the way abilities are offered and connected becomes an architecture question of its own. This lesson covers MCP as a layer that lets systems work together. It shows how to manage large numbers of tools with registries and discovery. And it shows how to decide whether a framework is worth adopting.

Model Context Protocol (MCP)

MCP is a protocol for connecting AI applications to outside context and abilities through standard interfaces. In concept, it separates the host and model from the way tools and context are offered. That matters because agent ecosystems otherwise turn into piles of custom adapters. A standard protocol makes abilities easier to find and reuse across compatible clients and servers.

• Know the pieces: host, client, server, tools, resources, and the protocol boundary between them.
• Know the difference between discovery and execution. Finding an ability is not permission to run it.
• MCP does not remove the need for security. A tool offered through a protocol is still something that can run. The server must authenticate and authorize requests, check inputs, limit scope and protect secrets.
• Think of MCP as a layer for working together. It is not the brain of an agent. Your application still owns policy, identity, orchestration and business logic.

Tool registries and finding abilities

As the number of tools grows, putting every definition into every model context gets expensive and confusing. Discovery of abilities lets an agent find the relevant tools before it calls them. A registry can store the tool's details, owner, version, permissions, health and the customers it supports. Discovery can work by meaning, by category or by policy.

{
  "tool": "orders.refund.issue",
  "version": "2.1.0",
  "owner": "payments-team",
  "description": "Issue a refund for a delivered order. Max $50 without approval. Idempotent by (order_id, request_id).",
  "input_schema_ref": "schemas/refund_issue.v2.json",
  "risk_tier": 2,
  "requires_approval_above_usd": 20,
  "tenants": ["acme", "globex"],
  "health": { "status": "ok", "p95_ms": 420 },
  "deprecated_after": null
}
// The registry may say a user COULD use this tool. The execution layer still enforces final authorization on every call.

• Keep discovery information apart from permission to run. A registry must never become a way around authorization.
• Version tools like APIs. Breaking changes need a plan for compatibility, schema versions and monitoring.
• Measure tool selection errors, meaning the wrong tool chosen, and not just failures when a tool runs.

Frameworks: when to use them

Agent frameworks give you ready-made parts for state, tools, graphs, memory, tracing and model connections. They speed up development, but they can hide important behavior. A senior engineer learns the underlying ideas first, and can build a minimal agent loop without a framework. Then they adopt a framework when it reduces repeated code without stopping them from debugging or controlling things. Your architecture is the system of boundaries, state, tools, policies, data and operating controls. The framework is a detail of how you build it, unless its protocol becomes a deliberate platform dependency.

• Understand the raw model and tool APIs before you adopt an orchestration framework.
• Judge lock-in, visibility, extensibility and how easy it is to debug.
• Keep business logic outside framework-specific glue wherever you can.