Phase 5: Model Context Protocol (MCP) · 75 min · Python · MCP SDK · Anthropic SDK

Dynamic Tool Discovery & MCP Registries

A registry lets an agent discover which tools exist, query by capability, and connect only to what it needs — not all 50 servers at once.

Hiring signal: Every large enterprise building AI infrastructure eventually needs a tool registry. Candidates who can articulate why (context window limits, access control, dynamic discovery) and describe an implementation are thinking at the right level of scale for staff and principal AI engineer roles.

What you will learn

Build an MCP registry that catalogs servers by capability tags and enforces team-level ACLs
Implement capability-based tool selection: extract required capabilities from a task, query the registry, connect only to matching servers
Design a health-check mechanism that marks unavailable servers before agent runs begin

The Problem

Your company has 50 internal MCP servers. A customer support agent needs database and email tools. An engineering agent needs GitHub and Postgres tools. A data analyst agent needs analytics and reporting tools.

Connecting every agent to all 50 servers at startup means loading 250+ tool definitions into every model call. Tool definitions consume tokens. At 250 tools, model performance degrades significantly — too many choices impairs decision-making. The model spends reasoning budget evaluating irrelevant tools instead of solving the task.

The solution is a tool registry: a catalog of available MCP servers tagged with capability labels. Each agent queries the registry for servers relevant to its current task, connects only to those, and loads a focused set of 5–10 tools. New servers join the registry without changing any agent code. Teams see only the tools they're authorized to access.

Demand-driven tool loading
Instead of connecting to all servers upfront, the agent asks: "What capabilities does this task need?" — then queries the registry for matching servers. This keeps tool sets small, model decisions focused, and context windows efficient.

Registry Architecture

An MCPRegistry stores server metadata as catalog entries:

@dataclass
class ServerRegistration:
    server_id: str
    name: str
    description: str
    capabilities: list[str]      # e.g. ["database", "sql", "read-only"]
    endpoint: str                # stdio command or HTTP URL
    transport: str               # "stdio" | "streamable-http"
    auth_required: bool
    allowed_teams: list[str]     # ["*"] = all teams, else ["eng", "support"]
    status: str                  # "available" | "unavailable"

The registry answers two queries:

query_by_capability(["database", "sql"], team="eng") → returns servers that have any of these capabilities and are accessible to the eng team
list_all(team="support") → all servers a team can access

Why load tools dynamically from a registry instead of connecting to all servers upfront?

Tool definitions consume tokens. 50 servers × 5 tools each = 250 tool descriptions in every model call. Beyond ~20–30 tools, model performance degrades — too many choices impairs decision-making. Dynamic discovery loads only the 5–10 tools actually needed for the current task, keeping the context focused and the model performant.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Capability-Based Selection, Multi-Tenant Access Control, Registry Health Checks, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.