MCP Servers

The Model Context Protocol (MCP) is how AI agents reach external tools and data. An MCP server exposes a set of tools; an agent calls those tools over a transport. Alien Giraffe tracks every MCP server configured across the fleet and what it is used for.

What an MCP server looks like

Each MCP an agent is configured with has:

• a name (e.g. github, filesystem, postgres),
• a transport — how the agent talks to it,
• a set of tools it exposes, each of which can be individually enabled or disabled when mirrored.

Transports

Transport	Description
stdio	The agent spawns the MCP server as a subprocess and exchanges JSON-RPC over stdin/stdout. The most common transport for local tools.
http	The agent connects to a long-lived MCP server over HTTP streaming.
sse	Server-Sent Events streaming, used by some remote MCP servers.

Lander captures the transport for each MCP during discovery and reports it in inventory.

The known-MCP registry

The control plane maintains a registry of known MCP servers — curated definitions with a name, description, expected transports, and tool signatures. It is exposed at GET /admin/mcps/known.

The registry lets the dashboard enrich what it discovers in the wild: when a device reports an MCP named github, the control plane can show a friendly description and the tools that server is expected to offer, instead of just a bare name. An unrecognized server still works and is still mirrored — it just displays under its raw name.

See Supported MCPs for the servers in the registry and the per-server verification status.

Fleet-wide MCP views

Discovered MCPs are aggregated across every device so you can reason about them at fleet scale:

• MCP registry (GET /admin/mcps) — every MCP seen across the fleet. For each one:
  • devices_configured vs devices_enabled — how many devices have it configured versus actively enabled,
  • agents_configured vs agents_enabled — the same split by agent type,
  • agent_types — which agents use it,
  • transports — the transports observed.
• MCP usage (GET /admin/mcps/:mcpName/usage) — usage statistics for a specific MCP: tool-call counts and success/failure rates, derived from observability events.

flowchart LR
  MCP["github MCP"]
  MCP --> C["configured on 120 devices"]
  MCP --> E["enabled on 95 devices"]
  MCP --> U["3,400 tool calls / 7 days"]
  MCP --> R["2.1% denied"]

Configured vs enabled vs mirrored

These three states are distinct and worth keeping straight:

• Configured — the MCP appears in an agent’s config on a device.
• Enabled — the MCP (or a specific tool on it) is active rather than turned off.
• Mirrored — Lander has interposed its proxy so the MCP’s traffic is captured and audited. An MCP installed from the Connector is mirrored from the start; an MCP added by hand outside the Connector is configured but not mirrored (and is flagged as an unmanaged change).

A Connector-managed MCP is captured automatically — installing it through the Connector is what interposes the proxy. See MCP mirroring and the Install an approved MCP guide.

On the dashboard

The MCP views live under /admin/mcp-servers (the list, with configured/enabled device counts) and /admin/mcp-servers/:id (a single MCP’s detail: description, transports, the agent-support matrix, and usage statistics). The Monitor guide walks through them.