Skip to main content
Glama

Evaluation scoring check

wever_evaluation-scoring-check
Read-only

Agent Evaluation: submit one scoring rubric and its judge setup: the rubric version, what it scores, the scale’s lowest and highest scores and step, and each scale point with its anchor and whether a worked example is attached; who scores (a model, people, an automatic metric or a mix) with the judge model, whether its version is pinned and its prompt fixed, its temperature, whether it is the model being scored, and its calibration (against human labels, known answers or nothing, on how many items and at what agreement); and the spot check, whether people check a share of the scores, what share, who checks and how often they disagree. The signed report says point by point whether the scale is anchored, whether a model judge is calibrated and pinned, whether a person spot-checks judged scores and whether scores compare across runs, and names an unanchored scale, an uncalibrated model judge, judged scores no person checks and an unpinned judge, then every unanchored point, points off the scale, no worked examples, an unversioned rubric, calibration agreement under 0.7 or on fewer than 50 items, an unfixed judge prompt, a sampling judge, a judge scoring itself, a spot check under one in twenty or by the builders and spot-check disagreement over 0.2, with the fix for each. This reads the rubric and judge behind a score: a trust score computed from verified completed work is wever_agent-trust-scorecard and whether a job’s delivered work meets its acceptance criteria is wever_deliverable-check. A worked rubric is wever_evaluation-rubric-sample on https://weverlabs.com/mcp-free. Verdict scores_unreliable, scoring_gaps, scoring_unverified or scoring_consistent. POST /api/evaluation-scoring-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-evaluation-contract. Human page: https://weverlabs.com/agent-evaluation/.

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": {
      "rubric": "<rubric>"
    },
    "name": "wever_evaluation-scoring-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
judgeNo
labelNoOptional name recorded in the report.
rubricYes
spot_checkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld=false/destructive=false, and the description adds substantial context beyond them: reads only material in the call with no network request, fetch, money movement or external write; costs 0.10 USDC per call on Base via x402 with 10 signed-wallet free calls per 30 days; requires X-Wever-Wallet-Proof bound to the exact arguments and route; returns an Ed25519 signed receipt. It also enumerates the possible verdicts (scores_unreliable, scoring_gaps, scoring_unverified, scoring_consistent), which the annotations cannot convey.

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 entire input enumeration is delivered as one enormous run-on sentence, then a second long sentence re-lists the same concepts as report findings and thresholds. The duplicated enumeration (describe the field, then describe the same field again as a flag) inflates length without helping the agent call the tool. Only the leading clause and the routing sentences are efficiently structured.

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?

There is no output schema, so the description reasonably explains the report contents, the four verdicts and the signed receipt. Payment, auth binding, endpoint and contract/page links are all present. The only shortfall is that a caller still cannot tell how findings are ordered or sized in the returned report.

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

Parameters5/5

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

Schema description coverage is only 25%, so the description carries the burden and does: it walks through rubric version, criteria, scale min/max/step, each point with anchor and worked example, judge kind/model/version pinning/prompt fixing/temperature/self-scoring/calibration against human labels or known answers with item count and agreement, and the spot check done/share/who/how much disagreement. It also names the concrete failure thresholds the inputs are compared against, which the schema does not express.

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 opening clause gives a specific verb and resource: submit one scoring rubric plus its judge setup and receive a signed point-by-point report. It also explicitly distinguishes itself from wever_agent-trust-scorecard (trust score from verified completed work) and wever_deliverable-check (acceptance criteria). The core purpose is clear, though it is buried under a long enumeration of nested fields rather than stated crisply up front.

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?

It names two sibling tools and the condition that selects each ('a trust score computed from verified completed work is wever_agent-trust-scorecard'), and points to wever_evaluation-rubric-sample for a worked rubric. That is real routing guidance, but there is no explicit statement of when this check is inappropriate or what prerequisites the caller must have (e.g. must a rubric already exist?).

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