Skip to main content
Glama

xenia_report

Analyze coding agent performance across tasks, failures, repeats, and tool usage. Identify recurring failures and inefficiencies to improve environment and instructions.

Instructions

How coding agents have been getting on with their work on this machine. One record, six views of it — choose what a row should be with 'view':

tasks one unit of work an agent named for itself, and whether it got there: achieved, partial, failed, abandoned or no_action. The outcome is read off the calls made under the task, never off the agent's claim about it; where the two disagree 'overstated' is 1 and 'declared' is what the agent said. Start here. instructions the same question one level up: one thing the user asked for, and how it turned out. The only view that carries whole prompts, which is why the rest carry a 'goal_id' — pass one back as 'goal_id' for the full text of that instruction. failures one kind of work that keeps failing, worst first, grouped across sessions. 'repos' names the checkouts it failed in, because that is where a fix goes; 'previously' is the same count over the window before this one, so a row failing 8 times against 0 is new and one against 12 is already getting better. 'recovered' is how often a later call put it right; many failures and few recoveries is a gap in the environment or the instructions, and the most actionable row here. Refusals split by who did the refusing: 'refused_by_rule' is a hook or a permission rule, and the reason is in 'example_error' — a config or code fix; 'declined_by_user' is a person saying no at the prompt, which is not yours to change. Pass 'example_action_id' to xenia_trace. repeats one piece of work a session did again minutes after it had already succeeded. This is the waste 'failures' cannot show, since none of it failed. Cost it in 'repeated_bytes' rather than 'repeated_ms': redoing work is rarely slow, but every repeat puts its whole reply back into a context. tools one tool, broker, host, repo or signature, with calls, failure rate, latency and reply bytes. Ask this rather than totalling rows yourself; order by 'total_bytes' for what floods a context rather than what takes time. disk one file (or repo, tool, session) with what was written to it, how often it was rewritten, and how much of that hashed to what was already there — 'unchanged' is bytes that reached the drive and changed nothing.

Rows come back under 'rows'. The tasks view also returns 'instructions', the text of each instruction its rows sat under, keyed by 'goal_id' — one entry per instruction rather than the same sentence repeated down every row. 'since', 'repo' and 'limit' apply to every view; each other parameter names the views that read it, and passing one to a view that does not is an error rather than a filter that quietly does nothing. For the individual calls behind any row, take its 'signature' to xenia_calls.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viaNo[repeats tools] Which broker carried the call: an MCP server name, or 'direct' for the shell. Globs, so 'acme-*' covers every server at one site.
kindNo[repeats tools] Restrict to one kind of action.
pathNo[disk] One absolute path, exactly or as a glob: '/home/*/.cache/*'.
repoNoLimit to one repository by name. Agent work outside any checkout is filed under 'general'.
toolNo[repeats tools disk] Tool name, exactly or as a glob: 'Bash', 'mcp__acme-ssh__shell', 'mcp__acme*'.
viewYesWhich of the six above.
agentNo[tasks repeats tools disk] Which runtime: claude or codex.
limitNoMaximum rows (default 200, capped at 500).
orderNo[repeats tools disk] Sort by. For tools: calls, failure_rate, p95_bytes, p95_ms, total_bytes, total_ms (default 'total_ms', the time the group actually cost). For disk: bytes_written, rewrites, unchanged, wasted_bytes, writes (default 'wasted_bytes'; use 'writes' when sizes are unknown). For repeats: repeated_bytes, repeated_ms, repeats (default 'repeats'; order by 'repeated_bytes' for what the redoing cost a context, which is where the cost of this view lands — redone work is rarely slow).
sinceNoWindow to look back over: '24h', '7d', '30m', or a date like '2026-07-01'. Omit for all time.
searchNo[tasks] Substring match over the task label and the instruction it sat under.
sourceNo[tasks] How the task was identified: the agent's plan, the description on a call, or the shape of the work.
statusNo[tasks instructions tools] Restrict to one outcome. For tasks and instructions: open, achieved, partial, failed, no_action, abandoned. For tools: started, ok, error, blocked, unanswered — where 'blocked' is a call something refused and 'unanswered' is one nobody answered before the session ended, which is counted as a failure nowhere.
channelNo[repeats tools] What kind of far side it reached: http, ssh, git, mcp, db, package, cloud, raw.
goal_idNo[instructions] One instruction, in full, by the id the other views return.
sessionNo[repeats tools disk] One agent run, by session id. Worth using on a machine running several agents at once, where a timeline is otherwise several agents interleaved.
group_byNo[tools disk] What one row covers. For tools: agent, channel, environment, host, intent, kind, repo, signature, status, tool, via (default 'tool'; a call with no such property — a file edit has no host — groups under null). For disk: agent, path, repo, session, tool (default 'path').
min_countNo[failures repeats tools disk] Drop rows below this many failures, repeats, calls or writes. Defaults to 2 for failures — one failure is an incident rather than a pattern — and to 1 elsewhere, so nothing is hidden unless you ask.
signatureNo[tools] The normalised identity of the work, as returned by the failures, repeats and tools views. This is how you drill from one of those rows into the calls behind it.
environmentNo[tools] Target environment of a remote call, e.g. production.
within_minutesNo[repeats] How close together two calls have to be to count as a repeat (default 10). Widen it for a slow-moving session; a large window starts counting honest re-runs.
overstated_onlyNo[tasks] Only tasks the agent called finished that the calls under them say were not.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it is exceptionally transparent. It discloses that outcomes are derived from calls rather than agent claims ('overstated'), how 'recovered' is computed, how refusals are split into rule-based vs user-declined, and that rows come back under 'rows'. It also explains error behavior for non-applicable parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but appropriately sized for a tool with 22 parameters and six views. It is well-structured: it front-loads the view taxonomy, then describes return shape and cross-view parameter behavior. Each sentence carries dense, purposeful information without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and an output schema, this description is unusually complete. It covers all six views, per-view fields and defaults, the return envelope, error semantics for inapplicable parameters, and the drill-down path to xenia_calls. No significant gaps were identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: it explains why to prefer 'repeated_bytes' over 'repeated_ms', what 'unchanged' means for disk writes, which order columns are relevant per view, and how 'within_minutes' can count honest re-runs. It also connects 'goal_id' back to full instruction text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a report on 'how coding agents have been getting on' and enumerates six distinct views, each with a concise one-line purpose. It also distinguishes itself from its siblings by instructing that a row's 'signature' should be passed to xenia_calls for individual calls behind the row.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: 'Start here' for the tasks view, 'Ask this rather than totalling rows yourself' for the tools view, and it calls the failures view 'the most actionable row here'. It also warns that passing a parameter to a view that does not read it is an error, which prevents misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iondrive-co/xenia'

If you have feedback or need assistance with the MCP directory API, please join our Discord server