Skip to main content
Glama

Knowledge entry check

wever_knowledge-entry-check
Read-only

Agent Knowledge: submit one knowledge entry: its id, the claim as written, its source with its name, where a reader finds it (a URL, a document id with its page or section, or a record id), its kind and whether a reader outside the agent can open it, the date the claim holds for, the scope it applies to (where and to whom), its review date and its expiry date; and optionally the moment to read it at. The signed report reads the entry piece by piece, the claim, the source, the date, the scope and the review, giving each as present, missing or present with a gap, and names each missing piece: no source, no date, no scope, and no review or expiry date; then a source marked as one no reader outside the agent can open, a review or expiry date already past at the reading moment, and a claim that says always, never, all, every or guaranteed, wider than any one source can show, with the fix for each. A worked sample entry done right beside a flawed one is wever_knowledge-entry-sample and the packet checklist is wever_knowledge-snapshot, both on https://weverlabs.com/mcp-free. Where one stored memory came from is wever_memory-provenance-check, and which agent took an action under which authorization is wever_actor-attribution-check in Agent Accountability. Verdict entry_incomplete, entry_gaps, entry_unverified or entry_complete. POST /api/knowledge-entry-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": {
      "entry": "<entry>"
    },
    "name": "wever_knowledge-entry-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofNoThe moment to read the entry at.
entryYes
labelNoOptional name recorded in the report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare read-only, non-open-world and non-destructive, and the description adds real context on top: it reads only material in the call, performs no network fetch or external write, costs 0.10 USDC via x402 with 10 free signed-wallet calls per 30 days, requires X-Wever-Wallet-Proof bound to the exact JSON arguments and route, and returns an Ed25519 signed receipt. It stops short of describing latency or failure/retry behavior.

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 two enormous semicolon-chained sentences that restate the entire input schema field-by-field before getting to the report behavior, pricing, and links. The submission spec is front-loaded, but the run-on structure and redundant field recap make it hard to scan and much longer than needed.

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-object tool with no output schema, the description covers the important ground: what is inspected, the four verdict values (entry_incomplete, entry_gaps, entry_unverified, entry_complete), the receipt, payment terms, and contract/page links. Only input formatting details (date syntax) and error behavior are left unaddressed.

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 67% schema coverage, the description still adds meaning beyond the schema: it explains that 'checkable' means a reader outside the agent can open the source, that location may be a URL, document id with page/section, or record id, and that scope is 'where and to whom'. It also ties each field to the corresponding report finding, which the schema does not do. Date string formats remain unspecified in both places.

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 states a specific verb and resource: submit one knowledge entry and receive a signed report that grades each piece (claim, source, date, scope, review) as present, missing, or present-with-a-gap. It names several siblings for adjacent concerns (wever_knowledge-entry-sample, wever_knowledge-snapshot, wever_memory-provenance-check, wever_actor-attribution-check), though it does not distinguish itself from the closest knowledge-* checkers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the enumeration of failure modes the report detects, and the description routes to a sample entry and a checklist. However, it never says when an agent should pick this tool over the nearest siblings (knowledge-source-check, knowledge-grounding-check, knowledge-freshness-check), so the selection decision is left to inference.

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