Wever Labs Agentic Rails

Observability metric check

wever_observability-metric-check

Read-only

Agent Observability: submit the metrics an operator reports, each with its name, its kind (a success rate, a failure rate, an average or 95th percentile latency, an average cost per task or a task count), its figure, its unit, the number of runs it says it counts, its window and the run statuses it says it leaves out, together with the run records behind them, each with its id, date, status (succeeded, failed, partial, timed out or cancelled), latency and cost, and optionally the reporting period. The signed report recomputes every figure from the records over its stated window with only its named exclusions, and when it differs tries every set of unnamed failing statuses, smallest first, so it names numbers that cannot be derived: a figure the records do not give, a success rate with no stated denominator, averages and rates that hold only with the failures left out, and metrics computed over a window that excludes the days the runs went worse; then a stated run count the records do not give, a shorter window that hides nothing worse, no window and undated records, with the fix for each. An evaluation’s claims against its measured results are wever_evaluation-result-check, headline payment numbers with no commerce behind them are wever_volume-quality-check and a reputation claim against its job record is wever_reputation-claim-check. Verdict metrics_underivable, metric_gaps, metrics_unverified or metrics_derivable. POST /api/observability-metric-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": {
      "metrics": "<metrics>",
      "records": "<records>"
    },
    "name": "wever_observability-metric-check"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional name recorded in the report.
`period`	No
`metrics`	Yes	Each metric as reported.
`records`	Yes	The run records behind the metrics.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description goes well beyond them: it states there is no network request, fetch, money movement, message, sharing or external write; it discloses a paid URL of 0.10 USDC per call on Base via x402 exact plus 10 signed-wallet free calls per rolling 30 days; it specifies the X-Wever-Wallet-Proof binding to the exact JSON arguments and route; and it states the report carries an Ed25519 signed receipt. The only unaddressed trait is idempotentHint=false — that re-submitting a paid POST charges again is never said.

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

Conciseness2/5

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

The description is a dense run-on of several hundred words with the essential facts (verdicts, price, auth binding) scattered in the middle and end. It front-loads field enumeration that duplicates the schema instead of leading with what the tool does and when to use it. Sentence boundaries are unclear ('then a stated run count... with the fix for each'), making it hard to scan.

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

Completeness4/5

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

For a nested 4-parameter tool with no output schema, the definition covers the important ground: enumerated verdicts (metrics_underivable, metric_gaps, metrics_unverified, metrics_derivable), the complaint categories it can raise, the paid/authenticated call mechanics, and a contract link. What it leaves thin is the returned report structure beyond 'signed receipt' and verdict, which matters more given there is no output schema.

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

Parameters3/5

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

At 75% schema description coverage the schema already names most fields, and the description largely restates them in prose (metrics with name/kind/value/unit/denominator/window/excludes, records with id/date/status/latency/cost). It does add relational meaning the schema does not: the records are 'the run records behind' the metrics, and the report recomputes figures over the stated window 'with only its named exclusions', which tells the agent how metrics and records are coupled. That extra is modest against a long redundant restatement.

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

Purpose4/5

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

The description names a specific action (submit reported metrics plus the run records behind them) and a specific output (a signed report that recomputes every figure and names what cannot be derived), and it explicitly contrasts itself with wever_evaluation-result-check, wever_volume-quality-check and wever_reputation-claim-check. The core purpose is therefore identifiable, but it is buried under a long enumeration of schema fields ('its name, its kind, its figure, its unit, the number of runs it says it counts...') before the actual job of the tool is stated.

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?

The definition gives real routing guidance by naming three sibling checks and the conditions that select them: evaluation claims against measured results, headline payment numbers with no commerce behind them, and reputation claims against a job record. It does not state positively when this tool (rather than those) should be chosen, nor any prerequisite such as having complete run records, so the routing is one-sided.

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

All Wever Labs Agentic Rails tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?