Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xenia show me failures in the last 24 hours"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Xenia helps agents work better on your computer by providing a local MCP for them to check for repeated mistakes, and a tray icon with an overview page for you. Install and run on linux or mac with:
./bin/xeniaNeeds Python 3.11+
xenia_report
| One row is |
| What an agent set out to do, in its own words, and whether it got there. The label comes from its plan where it kept one and the outcome is read off the calls made under it. Ordered by what went wrong, not by the clock — pass |
| Something the user asked for, and how it turned out. |
| A kind of work that has failed more than once, worst first, grouped across sessions and repos — or, with |
| Work a session did again soon after it had already attempted the same thing. |
| Counts, failure rates, latency and reply size, per tool, broker, channel, host, repo or signature. |
| What was written, how often each file was rewritten, and how much of that hashed to what was already there. |
xenia_callsOne row of any of the above, broken into the individual calls behind it.
xenia_traceThe actions between an action_id failure and the fix, with both measures of
how long that took: the actions in between, and the clock time.
since (24h, 7d, or a date)
repo (work outside any checkout is filed under general)
limit applies to every view. Every reply opens with now and now_local,
because the record is UTC and the logs it gets lined up against usually are not.
Where tool, via, channel, session and signature are accepted they match exactly or as a glob (via: "acme-*"), and a signature from any view drills straight into the calls behind that row.
See ARCHITECTURE.md.
Individual calls, for the one question every xenia_report view raises and cannot answer: which call was that. A 'tools' row reporting a 33KB maximum does not say which call returned it, and one signature covering six journalctl runs is one row on purpose. Deliberately thin — action id, time, tool, status, duration, reply size and a short command, and nothing that repeats identically down the rows. Defaults to the heaviest replies first; pass the 'signature' or 'tool' from a report row to drill into it, and the 'action_id' it returns to xenia_trace. 'detail' is cut to 120 characters so a page of rows stays readable — xenia_trace on the same action id is where the whole command is, for any call and not only a failed one.
| Name | Required | Description | Default |
|---|---|---|---|
| via | No | Which broker carried the call: an MCP server name, or 'direct' for the shell. Globs, so 'acme-*' covers every server at one site. | |
| kind | No | Restrict to one kind of action. | |
| repo | No | Limit to one repository by name. Agent work outside any checkout is filed under 'general'. | |
| tool | No | Tool name, exactly or as a glob: 'Bash', 'mcp__acme-ssh__shell', 'mcp__acme*'. | |
| agent | No | Which runtime: claude or codex. | |
| limit | No | Maximum rows (default 20, capped at 500). Small on purpose: this is a drill-down, not a timeline. Raising it is the wrong move on a reply that came back truncated — rows here are whole shell commands, so a few hundred of them hit the reply ceiling and get cut. Filter instead. | |
| order | No | Sort by reply size (default), time taken, or when it ran. Calls that never returned sort last either way. | |
| since | No | Window to look back over: '24h', '7d', '30m', or a date like '2026-07-01'. Omit for all time. | |
| status | No | Restrict to one outcome. | |
| session | No | One agent run, by session id. Worth using on a machine running several agents at once, where a timeline is otherwise several agents interleaved. | |
| signature | No | 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. | |
| blocked_by | No | Restrict to calls the runtime refused, by who refused them: 'rule' for a hook or permission rule (the reason is on the row's error, and the fix is in a file), 'user' for a decline at the prompt. Calls that simply never completed carry neither. | |
| descending | No | Sort descending (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the disclosure burden. It exposes default ordering, the deliberate 120-character 'detail' truncation, the fact that rows are whole shell commands that can exceed reply ceilings, and that unanswered calls sort last. This is rich behavioral context beyond any annotation-level hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences front-load the purpose and then pack actionable behaviors without filler. Metaphorical phrasing like 'a 'tools' row reporting a 33KB maximum...' earns its place by encoding how rows behave, and the length is appropriate given 13 parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity, 13-param tool with no output schema, the description covers the drill-down workflow, row contents, sorting defaults, truncation caveat, and sibling handoffs. It even describes the return fields ('action id, time, tool, status, duration, reply size and a short command'), making it self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3, but the description adds significant practical semantics: 'signature' and 'tool' come from report rows, 'limit' is intentionally small and raising it backfires on truncated replies, 'order' defaults to bytes with unanswered calls last, and the returned 'action_id' is meant for xenia_trace. These nuances go well beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by answering exactly what the tool surfaces ('Individual calls') and frames it as the drill-down complement to xenia_report, explicitly distinguishing it from sibling xenia_trace by describing the thin row fields and where to go for full commands. This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use it: after a xenia_report row, pass 'signature' or 'tool' from that row to drill in, then hand the returned 'action_id' to xenia_trace. It also warns against raising 'limit' on truncated replies, directing the user to filter instead—clear context with exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| via | No | [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. | |
| kind | No | [repeats tools] Restrict to one kind of action. | |
| path | No | [disk] One absolute path, exactly or as a glob: '/home/*/.cache/*'. | |
| repo | No | Limit to one repository by name. Agent work outside any checkout is filed under 'general'. | |
| tool | No | [repeats tools disk] Tool name, exactly or as a glob: 'Bash', 'mcp__acme-ssh__shell', 'mcp__acme*'. | |
| view | Yes | Which of the six above. | |
| agent | No | [tasks repeats tools disk] Which runtime: claude or codex. | |
| limit | No | Maximum rows (default 200, capped at 500). | |
| order | No | [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). | |
| since | No | Window to look back over: '24h', '7d', '30m', or a date like '2026-07-01'. Omit for all time. | |
| search | No | [tasks] Substring match over the task label and the instruction it sat under. | |
| source | No | [tasks] How the task was identified: the agent's plan, the description on a call, or the shape of the work. | |
| status | No | [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. | |
| channel | No | [repeats tools] What kind of far side it reached: http, ssh, git, mcp, db, package, cloud, raw. | |
| goal_id | No | [instructions] One instruction, in full, by the id the other views return. | |
| session | No | [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_by | No | [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_count | No | [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. | |
| signature | No | [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. | |
| environment | No | [tools] Target environment of a remote call, e.g. production. | |
| within_minutes | No | [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_only | No | [tasks] Only tasks the agent called finished that the calls under them say were not. |
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.
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.
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.
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.
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.
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.
One action, the task it was working towards, its outcome, and — when a later action fixed it — every action in between, from that one session. This is how a failure was actually recovered from. A fix in a later session gives the two endpoints only: the work between them belongs to two sessions and threading it into one list by clock time would not be a reading of anything. Takes ANY action id, not only a failed one: it is also the way to read one call's arguments in full, since xenia_calls shortens them to keep its rows scannable and a recovery series is simply absent when there was nothing to recover from.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | The action to trace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses that the tool returns a session-specific series of actions, includes the task/outcome, and omits cross-session threading. It does not explicitly mention read-only nature or error cases, but it provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and meandering, with four complex sentences and several asides. It is not front-loaded and requires careful reading to extract the core functionality. While every sentence adds some context, the lack of brevity and unclear structure hurt usability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers key contextual elements: session scope, recovery semantics, and full argument retrieval. It lacks an explicit return format or error handling details, but for a single-parameter tool with no output schema, it provides sufficient context to understand expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of action_id ('The action to trace'). The tool description adds extra nuance (e.g., accepts any ID, not just failed ones) but does not fundamentally change parameter understanding, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly communicates that the tool returns a trace of an action's context (task, outcome, and intervening actions) and distinguishes itself from xenia_calls by offering full argument details. However, it lacks a direct imperative verb like 'trace' and is more descriptive than concise, which slightly muddles the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with xenia_calls, noting that xenia_trace is the way to read full arguments, and clarifies that it accepts any action ID, not just failures. It also explains the session-based limitation and when a recovery series is absent, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0xenia_callsxenia_reportxenia_traceScored across 3 tools
The three tools are clearly distinct: xenia_report provides aggregated views, xenia_calls provides individual call details, and xenia_trace provides a recovery trace. Each tool addresses a different level of analysis, with no overlapping purposes.
All tool names follow a consistent 'xenia_' prefix followed by a noun (report, calls, trace), forming a predictable pattern. The naming is uniform and intuitive.
With only 3 tools, the set is well-scoped for an observability server. Each tool earns its place, and the xenia_report tool consolidates multiple views without unnecessary fragmentation, keeping the surface focused.
The tool set covers the full observability workflow: aggregated reports (xenia_report), per-call inspection (xenia_calls), and detailed action tracing (xenia_trace). There are no obvious gaps, as the three tools enable a complete drill-down from summary to individual action.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI agent observability for production traces, natural-language insights, and improvement loops.
Monitoring that agents set up for themselves — cron jobs, CI/CD pipelines and AI agent runs.
AI agent run monitoring with incident replay and SLA receipts.
Data + AI observability — monitor and troubleshoot production-grade agents and the context they use.
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
