AI Agents

An AI agent is a coding or desktop application that uses MCP servers to reach tools and data — Claude Desktop, Claude Code, Gemini CLI, Codex CLI, and similar. Alien Giraffe discovers these agents on each endpoint and tracks them fleet-wide.

Discovered agent types

Lander ships adapters that know where each supported agent stores its MCP configuration and how to parse it:

Agent type	Identifier	Configuration source
Claude Desktop	claude-desktop	~/Library/Application Support/Claude/claude_desktop_config.json
Claude Code	claude-code	~/.claude.json (global + per-project scopes)
Gemini CLI	gemini-cli	~/.gemini/settings.json
OpenAI Codex CLI	codex	~/.codex/config.toml

Each adapter handles that agent’s specific format — flat JSON, per-project scopes, or TOML — and normalizes the result into a common shape.

Discovery is not the same as full support. What Lander can install, enforce, and observe differs per agent: Claude Code and Codex expose prompts, responses, and exact token counts, while Claude Desktop takes managed MCPs but has no skills concept. See the Supported Agents reference for the capability-by-capability matrix, and Supported MCPs for the servers on the other side.

How discovery works

Lander reads the agents’ own configuration files; it does not require the agents to be running. For each installed agent it extracts the list of configured MCP servers and consolidates everything into a single unified view at ~/.lander.json.

Discovery stays current automatically:

• File watching — Lander watches each agent’s config file with fsnotify and reacts to changes within a debounce window (about 500ms).
• Polling backstop — a periodic poll (about once a minute) catches anything the watcher misses.

When the configuration changes, Lander updates its unified config and pushes a fresh inventory to the control plane. A change Lander didn’t make on the Connector’s behalf — someone editing the config by hand — is additionally reported as an unmanaged change in the audit trail, since MCPs are meant to be installed from the Connector. See Security & audit.

Agent identity on every call

When Lander mirrors an MCP, it attributes each proxied tool call to the calling agent so that observability events can be sliced per agent:

• stdio transport — the agent ID is injected via the LANDER_AGENT_ID environment variable when Lander rewrites the agent’s config.
• HTTP transport — the agent ID travels in the X-Lander-Agent header.
• Fallback — unknown if no identity is present.

This is what lets the dashboard answer “which agent made this call” rather than just “this device did.”

Agents in the control plane

The control plane rolls per-device agent data into fleet-wide aggregates:

• Agent aggregates (GET /admin/agents) — the distinct agent types seen across the fleet, with device count, MCP count, and status distribution for each.
• Devices per agent (GET /admin/agents/:agentType/devices) — every device running a given agent type, with owner, status, version, MCP count, and last check-in.
• MCPs per agent (GET /admin/agents/:agentType/mcps) — the MCP servers configured for a given agent type across the fleet.

These power the dashboard’s agent views, where you can answer questions like “how many machines run Claude Code, and which MCPs do they reach?” Next: the MCP side of that question — MCP servers.