Extending: MCP

Copilot is excellent at reasoning over code it can see and procedures you have written down, and blind to every system outside the editor. The list of consumers of a shared library, the open issues against it, the audit records in your tracker - all of it is one API call away and completely invisible to the chat.

In this course’s scenario that gap appeared immediately: before fanning subagents (focused checker agents run by a coordinator) across the consumers of shared-lib - the internal library other services import - you had to hand them the list. You found those consumers by hand - grep across repos, ask a teammate, squint at the service registry in a browser tab. The answer lives in an internal system, not in any file in the workspace.

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 talks to that system on one side and exposes a clean, described set of capabilities to Copilot on the other. Once connected, Copilot can call it like any other tool - it can ask the service registry “who depends on this library?” and get the answer itself, instead of waiting for you to paste it.

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

What this chapter builds

Wire up the thing that would have saved the manual hunt, then make it safe and contained:

• Connect · .vscode/mcp.json - the config file and the four ways to add a server, pointed at an internal service registry.
• Trust · confirm before it runs - why a new server does not start until you confirm it, how tool calls get gated, and what a sandbox can and cannot constrain.
• Scope · per-agent tool access - hand the registry to just the library-reviewer agent through its tools list, so the reach is contained to the work that needs it.

By the end, the library-reviewer agent from the custom-agents chapter can answer “who imports this?” on its own - and you have not handed every server to every conversation. Start by connecting one: .vscode/mcp.json.