Skip to main content
Glama

Knowledge report check

wever_knowledge-report-check
Read-only

Agent Knowledge: submit one knowledge report written for a principal, saying what the agent knows and what it is unsure of: its title, its audience, its headline as written and optionally its text; whether it states the claimed topics with no entries, the entries past their review date, the facts resting on one source and the claims their cited sources do not support, where each sits (beside the headline, in a later section, in an appendix or in a separate document) and how many it names; and optionally the record of each, as found by the coverage, freshness, source and grounding checks. The signed report says what sits beside the headline, checks every count against the record, and names a report that smooths over what the agent does not know: gaps, stale entries, single-source facts or unsupported claims left out, or stated as none against a record that holds some; then counts below the record’s, disclosures in an appendix or a separate document, and wording that calls the knowledge complete, comprehensive, up to date or verified while the record holds unknowns, with the fix for each. An observability summary for a principal is wever_observability-report-check, a reputation summary for a buyer is wever_reputation-report-check and classifying the failures a recorded run absorbed against its outcome is wever_trace-outcome-brief. Verdict gaps_smoothed_over, candor_gaps, candor_unverified or unknowns_disclosed. POST /api/knowledge-report-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-knowledge-contract. Human page: https://weverlabs.com/agent-knowledge/.

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": {
      "report": "<report>"
    },
    "name": "wever_knowledge-report-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
gapsNo
labelNoOptional name recorded in the report.
staleNo
recordNo
reportYes
unsupportedNo
single_sourceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it read-only and closed-world; the description adds concrete behavior beyond them: payment of 0.10 USDC per call with 10 free calls per 30 days, a required X-Wever-Wallet-Proof bound to the exact JSON arguments and route, and a returned Ed25519-signed receipt. It also explicitly states the tool reads only call material and performs no network request, fetch, money movement, message, sharing, configuration change, or external write.

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 front-loaded with purpose and every section carries useful content, but it is a single dense paragraph with run-on sentences and no structural breaks. The length and clause stacking make it harder to scan than a bulleted layout.

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 7-parameter nested tool with no output schema, the description covers purpose, validation logic, verdicts, payment/auth, and return type (signed receipt). It does not detail the output report's shape beyond verdict names, but that is a minor gap for correct invocation.

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 only 14% schema coverage, the description compensates by explaining the four gap categories (stated/placement/count) and the optional record of each from the coverage, freshness, source, and grounding checks. It omits any mention of the 'label' parameter, leaving one field unexplained.

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 opening sentence states a specific action—submit one knowledge report for a principal—and enumerates what the report must cover: title, audience, headline, optional text, and the four uncertainty categories. The description then distinguishes this check from the observability, reputation, and trace-outcome siblings by domain.

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 instructs the agent to submit a knowledge report and names sibling tools for adjacent summary types (observability, reputation, trace-outcome), giving clear domain context. It stops short of explicit 'use when / do not use when' conditions or prerequisites.

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