Observability Events

An observability event describes a single MCP tool call: who made it, what it did, how much it cost, and whether policy allowed it. Events are the raw material for every dashboard and metric in the platform.

Where events come from

When Lander mirrors an MCP, it produces an event for each tool call and:

1. writes it to local JSONL audit logs on the endpoint, and
2. batches it and streams it to the control plane at POST /v1/devices/events, signed with the device key.

Ingestion is best-effort and batched — transient control-plane outages don’t drop the local audit trail.

Anatomy of an event

Each event carries identity, action, outcome, and usage fields:

Field	Meaning
event_time	When the call happened (endpoint clock)
agent_type	The calling agent, e.g. claude-code
mcp_name	The MCP server invoked
tool	The tool called on that server
event_type	The kind of event (invocation, result, error)
result	allowed, denied, or error
deny_code / deny_reason	Why a call was denied (when result = denied)
error_message	Error detail (when result = error)
rule_applied	The policy/rule that produced a deny
model	The model driving the agent, when known
session_id	Groups calls within one agent session
group / actor_email	Org grouping and the human owner
tokens_in / tokens_out	Token usage attributed to the call
duration_ms	How long the call took
skills	Skill names involved in the call
prompt	The request prompt, optionally truncated
metadata	Arbitrary additional JSON fields

The full reference, with example payloads, is in the Observability Event Schema.

Results: allowed, denied, error

Every event resolves to one of three outcomes, which is the primary lens for analysis:

flowchart LR
  Call["MCP tool call"] --> P{Policy}
  P -->|tool enabled| Allowed["allowed"]
  P -->|tool disabled / rule hit| Denied["denied\ndeny_code + rule_applied"]
  Call -->|upstream failure| Error["error\nerror_message"]

• allowed — the call passed policy and was forwarded.
• denied — the proxy blocked it (for example a disabled tool); deny_code, deny_reason, and rule_applied explain why.
• error — the call was attempted but failed upstream; error_message carries the detail.

Aggregation in the control plane

The control plane turns the event stream into browseable and summarized views:

• Event browser (GET /admin/observability/events) — paginated, filterable list of individual events. Filter by date range, agent type, MCP name, result, and deny code.
• Summary (GET /admin/observability/summary) — aggregates: total events, the allowed/denied/error split, summed tokens_in/tokens_out, and the count of unique MCP servers.

These also feed the per-MCP usage stats described in MCP servers and the dashboards covered in the Monitor guide.

Local audit logs on the endpoint

In parallel with reporting, Lander writes per-MCP JSONL logs under ~/.lander/logs/<mcp-name>/:

• access.log — metadata for every request: method, JSON-RPC id, agent id, duration, status.
• query.log — full payloads for tool calls: tool name, arguments, and results.

Logs are size-rotated (default 10 MiB per file, up to 5 rotated siblings per MCP) and retained for off-box collection by your log pipeline. The query.log stream — which can contain sensitive arguments — can be disabled globally or per MCP from the Connector; see Security & audit for the redaction controls.