Install an Approved MCP

In Alien Giraffe, MCP servers are added to a device from the AlienGiraffe Connector, not by editing an agent’s config by hand. A user requests an MCP from the catalog, an admin approves it, and the Connector instructs Lander to install and configure it on the device. Because the Connector provisions it, the MCP is routed through Lander from its very first call — every tool call is observed and governed automatically, with no separate “mirroring” step. For the mechanism behind that, read MCP mirroring.

Prerequisites

The Connector (control plane) running, with the MCP catalog populated (Install the Control Plane).
Lander installed and registered on the target device (Install Lander) so it shows up in Fleet → Devices.
An AI agent (Claude Code, Claude Desktop, Gemini CLI, Codex CLI, …) present on the device for the MCP to attach to.

1. Request an MCP from the catalog

As a user, open MCP Servers → Catalog in the Connector and browse the available MCP servers. Pick the one you need — we’ll use github as the example — choose the device (or agent) it should be installed for, and submit a request.

The request enters a pending state and is visible to administrators. Nothing is installed yet.

2. Admin approves the request

An administrator reviews pending requests in Admin → MCP Requests and either approves or denies each one. Approval is where governance happens: the admin can set the tool allow/deny policy for the MCP (for example, disabling delete_repo and transfer_repo) before it ever reaches the device.

Approving the request marks the MCP approved for that device. Denying it records the decision and notifies the requester; nothing changes on the endpoint.

3. The Connector installs it on the device

Once approved, the Connector instructs Lander to provision the MCP:

Lander writes the MCP into the target agent’s configuration for the user — they don’t touch a config file.
The MCP is installed already routed through Lander’s proxy, so it is observed and governed from the first call.
The tool allow/deny policy set at approval is applied at the proxy.

4. Use it — traffic is captured automatically

In the agent, invoke a tool on the new MCP — for example, ask it to list issues or read a file through github. There is nothing extra to turn on: every call already flows through Lander, which attributes it, applies policy, writes the local audit log, and streams an observability event to the Connector.

5. See it in the dashboard

The calls show up in the Connector within moments (reporting is best-effort and batched):

Observability → Events (/admin/observability/events) — filter by MCP github to see individual calls, their agent, result, tokens, and duration. A tool blocked by the approval policy shows a denied result.
MCP Servers (/admin/mcp-servers) — github now shows usage and the allowed/denied split across the fleet.

6. Change policy or remove it

All of this stays in the Connector:

Adjust tool policy — update the MCP’s allow/deny policy in MCP Servers; the Connector pushes the change to Lander.
Remove the MCP — revoke it from the device in the Connector. The Connector tells Lander to restore the agent’s configuration to its exact pre-install state (the original is backed up losslessly) and stop capturing.

What about editing the config directly?

Editing an agent’s config file by hand (for example, hand-adding a server to ~/.claude.json) bypasses the approval and policy path. Lander detects the change through file-watching and reports it to the audit log as an unmanaged modification, so it surfaces in Admin → Audit Logs for review. Always add and remove MCPs through the Connector. See Audit & Compliance for how these events appear.

Recap

flowchart LR
  A["User requests MCP\n(Connector catalog)"] --> B["Admin approves\n+ sets tool policy"]
  B --> C["Connector installs\nvia Lander (proxied)"]
  C --> D["Agent calls tool"]
  D --> E["Observed & governed\nevents in dashboard"]

Next: tour the dashboards in Monitor Agents & MCPs, or tighten controls in Audit & Compliance.