Scope a server to one agent

The registry server you connected is wired at the workspace level, which means ordinary chat can reach it once trusted - no declaration needed. For a low-stakes tool that is fine. But a registry that can enumerate a dozen services’ worth of internal dependencies is exactly the kind of reach you would rather grant on purpose than leave open by default.

There is a tighter way to wire it. Cast back to the reviewer - the custom agent that holds the compatibility rules of shared-lib, the course’s illustrative internal library, imported by about a dozen services. That reviewer is precisely the consumer of the registry: when it is checking whether a change breaks anyone, it needs to know who imports the library. Almost nothing else in your day needs that.

The agent’s tools list is the scope

A custom agent’s frontmatter carries a tools list - the tools and MCP servers that agent is allowed to use. To reach a server’s tools, the agent’s list names the server with a /* suffix (syntax per the custom agents configuration reference, verified September 2026):

---
name: library-reviewer
description: Reviews changes to shared-lib for breaking changes and API contract violations.
tools:
  - read
  - search
  - 'service-registry/*'
---

With that entry, library-reviewer can call the registry’s tools when it needs them; an agent whose list omits the entry cannot. The reach travels with the persona: the same file that carries the reviewer’s job description and its read-only base tools now also carries its one deliberate connection to an external system.

What about mcp-servers in the agent file?

You may see an mcp-servers frontmatter property in the cloud custom-agent configuration reference. As of September 2026, GitHub documents it as not used in VS Code and other IDE custom agents - it configures additional MCP servers for the GitHub.com cloud agent only, and it takes an object form mapping server names to full server configurations. For IDE agents, the tools list above is the mechanism.

So the scoping decision splits in two: which servers exist for this workspace lives in .vscode/mcp.json; which agents may use a given server lives in each agent’s tools list. The registry can be workspace-visible (your teammates’ agents may want it too) while each agent must declare it to call it.

Why scope it at all

Scoping is not bureaucracy - it is the same judgment that runs through this whole stretch of the course. Every capability you hand an agent is reach it can use without asking you each time. On a shared library, where a wrong move ripples to a dozen apps, each grant should be deliberate: this agent, this server, for this reason - the control principle again, boundaries granted on purpose.

The precise boundary: workspace wiring governs chat; a custom agent’s tools list gates that agent only. Workspace-level MCP says “chat in this repo can reach the registry,” and ordinary chat needs no declaration to call a trusted server. An agent-scoped tools entry says “this agent can, because that is its job” - an agent whose list omits the entry cannot call it, while chat still can. If you want to keep the registry out of chat too, that is a workspace-wiring change (the connect lesson) or the chat’s tool-configuration toggle, not the agent file.

It also makes the reviewer portable in the right way. The agent file carries its rules, its base tools, and the name of the one external system it depends on. Hand the file (plus the repo’s mcp.json) to a teammate and they get a reviewer that already knows who imports the library.

Where the careful work stands

Look at what this stretch of the course has assembled. A library-reviewer that knows the compatibility rules and can query the registry itself. Subagents - focused checkers run by a coordinator - that fan a breakage check across every consumer. A skill that carries the audit-event convention. The machinery for changing a many-consumer library safely is in place.

There is one question all of it has been building toward: when the agent actually runs - calls the registry, edits a file in the library, executes a command - how much do you let it do before you look? That is the next chapter, where the question every safeguard built so far has been circling gets its own setting. Next chapter: Permissions & autonomy.