agent-observability

Overview Schema Source Related Servers Discussions Admin

run

Execute agent-trace CLI commands with specified arguments, automatically appending --json for machine-readable output to debug agent traces.

Instructions

Run the agent-trace CLI with the given subcommand/args; --json is appended automatically so the result is machine-readable JSON. Only these subcommands support --json today: list, replay, inspect, diff, run. Real agent-trace --help output:

Run the agent-trace CLI (agent-observability-trace-cli).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`args`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Sep 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "runDictOutput",
+  "type": "object"
+}

First observedv0.1.0Aug 10, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that --json is appended automatically and that only certain subcommands support it, which is useful. However, it does not mention error handling, side effects, permissions, or what happens with unsupported subcommands, leaving behavioral transparency incomplete.

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

Conciseness3/5

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

The description is mostly concise, but it contains a strange interjection 'Real `agent-trace --help` output:' followed by a line that doesn't appear to be actual help output (or is truncated). This adds noise without value, slightly undermining the structure, though the core information is front-loaded.

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

Completeness3/5

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

For a simple tool with a single required parameter and an output schema present, the description covers the available subcommands and the automatic --json flag, but it omits details about the expected format of the args array and any failure modes. This is a moderate gap given the no-annotation context.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only says 'subcommand/args' without explaining the array structure—e.g., whether the first element is the subcommand or if it should be a single string. There are no examples or format details, so the meaning of the 'args' parameter is poorly specified.

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 states it runs the agent-trace CLI, specifies that it takes subcommands/args, and notes that --json is appended automatically for machine-readable output. It also enumerates the supported subcommands, making the tool's purpose precise and unambiguous even without sibling tools.

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

Usage Guidelines4/5

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

While there is no alternative tool to compare against, the description gives useful context by listing which subcommands support --json (list, replay, inspect, diff, run). This implicitly guides the agent on what commands are valid. However, it doesn't explicitly state when to use this tool versus another or provide exclusion criteria.

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

Deploy Server

Other Tools

runA