Trust before it runs

You’ve added the service-registry entry to .vscode/mcp.json, and VS Code has noticed it. Notice what didn’t happen: it didn’t connect. An MCP server is a program - possibly one you didn’t write - that’s about to reach into systems outside your editor on Copilot’s behalf. That’s exactly the kind of thing you want a deliberate yes in front of, not a silent default.

Confirm trust before the server starts

When you add a server, or change its configuration, Copilot asks you to confirm trust before it starts that server. Until you do, the entry sits in the file inert. This is the same instinct as the diff-review habit from your very first change: nothing reaches outside a boundary until a human keystroke says it can. Adding the config is describing a connection; trusting it is opening it.

If you ever want to revisit that decision - you’ve stopped using a server, or you want to re-evaluate one you trusted in a hurry - run “MCP: Reset Trust” from the Command Palette. It clears your trust decisions so the next start prompts you fresh. Cheap to reach for; reach for it whenever a server’s behavior surprises you.

Tool calls get confirmed too

Trusting the server to start is one gate. Tool-call approval is a separate client, permission, server, and organization-policy decision. When Copilot wants to call a tool the registry exposes - say, “list the consumers of shared-lib” - the client may ask for confirmation, auto-approve it, or apply a sandbox or policy rule. Check the current permission state instead of assuming every call behaves identically.

When confirmation is enabled, it is a useful default because a tool call can have effects you didn’t anticipate. But confirmation behavior is configurable, and a trusted server may still be subject to different policies in different clients.

The sandbox: a controlled exception

A server entry can declare a sandbox, which lets its tool calls run without per-call confirmation by constraining what they’re allowed to do. Two keys govern it (on macOS and Linux):

• sandboxEnabled - turns the sandbox on for that server.
• sandbox - the rules the sandbox enforces: which parts of the filesystem the server may touch, and what network access it may use.

The trade is explicit and worth understanding: you’re swapping per-call confirmation for up-front constraints. A registry server that only ever makes read-only queries to one internal host is a reasonable thing to sandbox - you box it into “read these paths, reach that host, nothing else,” and then let its calls run unprompted inside those walls. A server that can write or reach anywhere is one you’d think harder about before lifting the confirmation prompt.

One thing to keep straight

It’s tempting to file all of this under “Agent mode,” since that’s where you’ll watch Copilot call the registry mid-loop. Don’t. MCP isn’t agent-mode-only. The tools, resources, and prompts a server contributes are available across chat and agents - Ask can read a registry resource to answer a question, any mode can pull in a server-provided prompt. What Agent mode adds is autonomy: it executes those tool calls itself, in a loop, which is why the confirmation gates above matter most there. The trust model is general; it just bites hardest where Copilot is acting on its own.

You’ve got a trusted, optionally sandboxed server. But right now it’s wired at the workspace level - every conversation in this repo can reach it. For a high-blast-radius library, that’s broader than you want. Next: scope it to one agent.