MCP Mirroring

Mirroring is the mechanism behind Alien Giraffe’s observability. Instead of asking agents to emit telemetry, Lander interposes a proxy between an agent and the MCP server it calls. Every JSON-RPC request and response flows through Lander, where it is attributed, audited, and governed — then forwarded to the real server.

In the managed model, mirroring is not something anyone turns on by hand. When an MCP is installed from the Connector, the Connector instructs Lander to provision it already routed through the proxy. Mirroring is therefore inherent to every Connector-managed MCP — it begins with the first call and needs no separate step.

Why proxy at all

MCP agents don’t emit a usable audit trail on their own. By sitting in the path, Lander can:

• see every tool call with its arguments and results,
• attribute each call to a specific agent and device,
• enforce the tool allow/deny policy the Connector set, and
• write a durable audit log locally and stream events to the Connector.

Crucially, it does this losslessly — the original MCP configuration is backed up atomically before Lander writes the proxied version, so the agent can be restored to its exact prior state whenever the Connector revokes the MCP.

Two mirroring modes

Lander uses one of two transports for the proxy, chosen per MCP by the Connector when it provisions the server.

stdio mode (default)

Lander writes the agent’s config so that, instead of spawning the real MCP server, the agent spawns Lander’s stdio proxy subprocess. That subprocess forwards JSON-RPC between the agent’s stdin/stdout and the real MCP server.

• Lightweight; a subprocess is spawned per MCP session.
• The agent’s identity is injected via the LANDER_AGENT_ID environment variable.
• No long-running daemon is required for the proxy itself.

sequenceDiagram
  participant Agent
  participant Proxy as Lander stdio proxy
  participant MCP as real MCP server
  Agent->>Proxy: JSON-RPC tools/call (stdin)
  Note over Proxy: attribute (LANDER_AGENT_ID)<br/>check tool policy<br/>append audit log
  Proxy->>MCP: forward request
  MCP-->>Proxy: result
  Note over Proxy: log result · emit event
  Proxy-->>Agent: JSON-RPC result (stdout)

HTTP-stream mode (daemon)

Lander writes the agent’s config to point at the local Lander daemon’s reverse proxy (http://localhost:8082/stream/proxy/<mcp-name>, via mcp-remote). The long-running Lander daemon (default port 8082) forwards to the real server.

• A single daemon serves all proxied MCPs.
• The agent’s identity travels in the X-Lander-Agent header.
• Requires the Lander daemon to be running (it is, as a launchd service).

Both modes support the same governance and audit features; they differ only in transport and process model.

Tool-level control

Each managed MCP carries a tool allow/deny policy, authored in the Connector — set when an admin approves the MCP and adjustable later under MCP Servers. Disabled tools are rejected at the proxy with a policy result of denied, which shows up in observability events with a deny reason. The rest of the server keeps working. The policy is pushed to Lander and applied locally; there is no local flag to edit.

Lossless restore

Before writing any agent config, Lander stores the original under originalConfig in ~/.lander.json. When the Connector revokes an MCP from a device, Lander puts the agent’s configuration back exactly as it was — the proxy is removed and the agent talks to the real MCP server directly again. Writes to ~/.lander.json are atomic (temp file + rename), so a crash mid-write can’t corrupt state.

What gets captured

For every proxied call, Lander records metadata and (unless redacted) full payloads to local JSONL logs, and emits an observability event to the Connector. The shape of that data is described in Observability events; the privacy controls are in Security & audit.

To do this end to end, follow Install an approved MCP.