Skip to main content
Glama

Observability coverage check

wever_observability-coverage-check
Read-only

Agent Observability: submit the list of an agent’s action types, each with the tools it uses and whether its runs are traced and logged; the tools the agent reaches, each with whether calls go through the traced path and the other ways the agent reaches it (a direct API key, a shell, a browser session); and either recent runs with whether a trace and log records were kept for each, or which runs keep traces and logs (all runs, a sample with its share, failures only, successes only, on request or none). The signed report lists each action, tool and run selection with its coverage, and names the blind spots: action types with no trace, tools reachable outside the traced path, and records kept for some runs but not others; then actions traced and not logged, tools an action uses that the list leaves out and reachable tools no action names, with the fix for each. Whether a gateway sits in front of every paid or external call is wever_gateway-coverage-check, which tools are exposed to an agent at all is wever_tool-exposure-check and whether one run’s trace reconstructs is wever_observability-trace-check. Verdict blind_spots, coverage_gaps, coverage_unverified or fully_covered. POST /api/observability-coverage-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": {
      "actions": "<actions>"
    },
    "name": "wever_observability-coverage-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
runsNoRecent runs with whether records were kept for each.
labelNoOptional name recorded in the report.
toolsNoEach tool the agent reaches.
actionsYesEach action type the agent takes.
selectionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that this is a paid POST (0.10 USDC per call on Base via x402, shared 10 free signed-wallet calls per rolling 30 days), that X-Wever-Wallet-Proof must bind the exact JSON arguments and route, and that the response carries an Ed25519 signed receipt. It also enumerates what is explicitly not done (no network request, fetch, money movement, message, sharing, config change or external write), which sharpens rather than merely repeats the read-only annotation.

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 content is front-loaded with the input inventory before the report description and routing, which is the right order. However, it is delivered as one long semicolon-chained paragraph with heavy clause nesting, making it harder to scan than the information warrants; breaking the input, output, and pricing blocks apart would cost nothing.

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?

For a five-parameter, nested-object tool with no output schema, the description covers the missing pieces: what the signed report contains, the enumerated verdicts, the specific blind-spot and gap categories plus their fixes, and the full payment/auth/receipt contract. Nothing an agent needs to construct a correct paid call is absent.

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 80% schema coverage the baseline is 3, but the description adds real structure by explaining how the arrays relate: actions carry their tools plus traced/logged flags, tools carry traced_path plus other_paths, and runs carry per-run traced/logged. It also spells out the selection semantics (all runs, a sample with its share, failures only, successes only, on request or none), which the schema only encodes as an enum. The optional 'label' parameter is not mentioned in the description, which keeps this below 5.

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 names the specific resource (an agent's observability coverage across action types, tools and run selections) and the specific operation (submit the inventory, receive a signed report of blind spots and coverage gaps). It also explicitly separates itself from three sibling checks, so an agent can pick the right tool without opening any schema.

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?

Alternatives are named with the exact question each answers: gateway placement is wever_gateway-coverage-check, exposure is wever_tool-exposure-check, single-run reconstruction is wever_observability-trace-check. That is explicit routing rather than implied usage, and the verdict vocabulary (blind_spots, coverage_gaps, coverage_unverified, fully_covered) further signals the scope of the check.

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