Skip to main content
Glama

Observability trace check

wever_observability-trace-check
Read-only

Agent Observability: submit one run trace to find out whether the run can be reconstructed from it: each step with its id, its sequence number, its name, its kind (a tool call, a model call, a decision, a handoff, a message, a write or other), when it started and ended, the steps it follows from, the tool it called, whether its input and its result are recorded and its status; optionally the run with its task and start and end times; and the final outcome with its status, its text and the step it comes from. The signed report lists every step with its place in the run and whether its record is whole, and names what breaks reconstruction: no steps, steps another step reads from and numbers in the sequence that have no record, tool calls with no recorded result, steps with no timestamp or sequence number and steps sharing one timestamp, which leave the order of events unknowable, and a final outcome no recorded step leads to; then steps recorded before the steps they read from, calls with no recorded input, a succeeded outcome from a failed step, steps dated outside the run and steps that end before they start, with the fix for each. Classifying each recorded failure as recovered, worked around or fatal against the outcome is wever_trace-outcome-brief, a recovery attempt’s record is wever_recovery-record-check and incident claims against their timeline are wever_incident-evidence-check. A worked sample is wever_observability-trace-sample and the packet checklist is wever_observability-snapshot, both on https://weverlabs.com/mcp-free. Verdict trace_broken, trace_gaps, trace_unverified or trace_complete. POST /api/observability-trace-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-observability-contract. Human page: https://weverlabs.com/agent-observability/.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "steps": "<steps>"
    },
    "name": "wever_observability-trace-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
runNo
labelNoOptional name recorded in the report.
stepsYesEach step the trace records.
outcomeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description reinforces this with concrete detail: no network request, fetch, money movement, message, sharing, configuration change or external write. It adds what annotations cannot — the 0.10 USDC per-call price, the shared 10 free signed-wallet calls per 30 days, the X-Wever-Wallet-Proof binding to exact JSON arguments and route, and the Ed25519 signed receipt. The only gap is that the verdict semantics (e.g. what distinguishes trace_gaps from trace_unverified) are named but not defined.

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

Conciseness4/5

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

Front-loaded with purpose and verdicts, and every clause carries information — the long enumerations of reconstruction failures and ordering defects substitute for a missing output schema. The cost is a run-on semicolon chain that is hard to scan; the pricing/auth and routing sentences could be broken out more cleanly.

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?

There is no output schema, and the description compensates fully: it explains the signed report's contents, the specific defect classes it names, the verdict set, and the receipt. Combined with pricing, auth header requirements, contract URL and sibling routing, an agent has everything needed to invoke this correctly and interpret the result.

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

Parameters4/5

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

With 50% schema coverage on four parameters including nested objects, the description carries real weight: it maps every step field (id, sequence number, name, kind, start/end, follows, tool, input/result recorded, status) and flags the run object as optional with task and times, plus the outcome's status, text and source step. This goes beyond the schema's per-field descriptions by explaining which fields the reconstruction test actually consumes (e.g. sequence numbers and timestamps drive the ordering verdicts).

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?

Opens with a specific verb and resource plus the question it answers: 'submit one run trace to find out whether the run can be reconstructed from it', then enumerates the accepted step fields and the four verdicts (trace_broken, trace_gaps, trace_unverified, trace_complete). It also names three sibling tools and what each covers, so an agent can place this tool precisely in the catalogue.

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?

Explicitly routes adjacent needs elsewhere: failure classification goes to wever_trace-outcome-brief, recovery attempts to wever_recovery-record-check, incident claims to wever_incident-evidence-check, with a sample and packet checklist named for orientation. The preconditions (paid call, wallet proof) are stated up front rather than discovered at call time.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources