What you will build
A capability inventory for one pre-approved, harmless MCP server. This chapter is an architecture exercise first; it does not ask you to register a filesystem server or expose a host Docker socket.
- Agent in microVM
- Host-side MCP gateway
- Host or remote server
- External resource and side effect
Conceptual flow. Follow the lesson for prerequisites, exact commands and verification limits.
Read the mechanism
Model Context Protocol lets an agent discover and call tools through a server. The transport does not itself establish where a tool executes or which resources it can reach. A tool named “read” can still have side effects; annotations and names are claims to inspect.
Docker Sandboxes’ local MCP gateway is on the host side of the microVM boundary. Remote servers execute remotely. Local stdio servers execute on the host; an OCI-packaged local server or an explicit Docker command uses host Docker. It does not automatically inherit the sandbox’s private Engine.
This gateway is separate from Docker Desktop’s MCP Toolkit. Registration makes a server known to the gateway; loading/exposing it makes it available to a sandbox. A direct MCP client configured in an agent is another path and may not pass through gateway governance.
Worked example · capability card
Use read-only inventory commands for servers already approved in your environment. Start with sbx mcp ls, then consult sbx mcp inspect --help for the installed inspection syntax. Do not dump OAuth tokens or private server configuration.
Fill this card from observed metadata:
Registration name:
Canonical server identity:
Transport: remote HTTP or local stdio
Execution location:
Host user / container isolation:
Tool names and actual operations:
Filesystem and network reach:
Authentication scope:
Sandboxes to which it is exposed:
Gateway or direct-client path:
Policy and approval support:For a design-only lab, use a mock “catalog” server with list_examples and read_example tools over synthetic records. Draw what changes if it is a local process versus a remote service. Neither version needs your real files.
A static MCP set chosen at sandbox creation makes the initially exposed server list explicit. Dynamic discovery can offer flexibility, but then server loading itself becomes a capability to govern. Do not confuse registration approval with approval of every subsequent tool call.
Expected observations
The diagram should place the server on its real execution side, with arrows to actual resources. If a local server can write host files, the risk remains even when the requesting agent is isolated.
A server present in the registry is not necessarily visible to the current sandbox. A listed tool is not necessarily invocable under policy. Capture those as separate observations.
Troubleshooting
When a tool is missing, check registration, exposure mode, agent integration and authentication separately. Avoid re-registering a broader server as a workaround. When a call succeeds outside the intended policy path, inspect whether the agent was configured with a direct client.
Interview practice
Why can a local MCP server defeat an otherwise careful filesystem boundary?
The server may run with host permissions and expose operations on host files. The sandbox invokes a capability across the boundary; it does not relocate the server into the microVM.
What is the difference between registration and invocation governance?
Registration controls which servers can be introduced. Invocation controls actual requests to tools, resources or prompts. Both are necessary when their risks differ.
Completion check
Explain every arrow on the MCP diagram and classify each tool by actual capability, not its name. Record any path that bypasses the gateway.
Sources and version notes
Checked 6 October 2026; current baseline: sbx v0.46.0. MCP gateway
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.