Extending: MCP

In the last chapter you packaged your team’s audit-event convention as a Skill — a portable SKILL.md Copilot could pick up in both repos and follow without you re-explaining it. That solved a knowledge problem: a procedure Copilot didn’t know, written down once, available everywhere. But there’s a different kind of gap a Skill can’t close, and you’ve already hit it.

Back when Act 1 opened, you needed to know which services actually import shared-lib. You fanned subagents out to check them — but first you had to hand them the list. You found those twelve consumers by hand: grep across repos, ask a teammate, squint at the service registry in a browser tab. Copilot couldn’t find them itself, because the answer doesn’t live in any file in your workspace. It lives in an internal system — a service registry, an issue tracker — that Copilot has no way to reach.

That’s the limit. Copilot is excellent at reasoning over code it can see and procedures you’ve written down. It is blind to every system outside the editor. The list of consumers, the open issues against the library, the audit records in your tracker — all of it is one API call away and completely invisible.

What MCP gives Copilot

MCP — the Model Context Protocol — is the standard wire for closing that gap. You connect Copilot to an external system through an MCP server: a small process that speaks to that system on one side and exposes a clean, described set of capabilities to Copilot on the other. Once a server is connected, Copilot can call it the way it calls any other tool — which means it can ask the service registry “who depends on shared-lib?” and get the answer itself, instead of waiting for you to paste it.

Worth saying plainly up front, because it’s a common misconception: MCP is not an agent-mode-only feature. A server contributes tools, resources, and prompts, and those are available across chat and agents alike — Ask can read a resource, any mode can pull in a prompt. What is true is that tool execution — Copilot actually calling the registry mid-task and acting on the result — shines brightest in Agent mode, where it’s already running a loop. The reach is general; the autonomy is where it pays off.

What this chapter builds

We’ll wire up the thing that would have saved you the manual hunt in Act 1, then make it safe and scoped:

• Connect an MCP server — the .vscode/mcp.json file and the four ways to add a server, pointed at an internal service registry — Connect · .vscode/mcp.json
• Trust before it runs — why a new server doesn’t start until you confirm, and how tool calls get gated — Trust · confirm before it runs
• Scope a server to one agent — hand the registry to just the library-reviewer agent, so the reach is contained to the work that needs it — Scope · per-agent servers

By the end, the library-reviewer you built in Act 1 will be able to answer “who imports this?” on its own — and you’ll have done it without handing every server to every conversation. Start by connecting one: .vscode/mcp.json.