Skip to main content
Glama
Sign In

AiSeek

by dev.aiseek
OverviewDiscussionsAdmin

Verify an evidence receipt

verify_receipt
Read-onlyIdempotent

Verify a receipt: recompute its digest from the stored record and report ok, digestMatches, canonicalForm, columnsMatch, evidenceRowsMatch and any problems. ok true means the record is unchanged since it was written. A receipt records an assessment; it is not a certificate that a claim is true. Use it before citing a receipt, after get_receipt has shown what it says; it does not return the content. Parameters: id is the receipt id you read with get_receipt (receipts[].id from get_change_history), never a change id; locale translates only the notice. Behavior: the check runs live on every call; problems name the failing part (DIGEST_MISMATCH, NOT_CANONICAL, COLUMN_MISMATCH:, EVIDENCE_ROWS_MISMATCH, PAYLOAD_UNREADABLE); an unknown or non-public id is an error. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.

Input Schema

NameRequiredDescriptionDefault
idYesThe receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read
localeNoLanguage of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)

Output Schema

NameRequiredDescriptionDefault
okYes
noticeYesA reminder that a receipt is not a certificate of truth, in the requested language
problemsYes
checkedAtYes
receiptIdYes
columnsMatchYes
canonicalFormYes
digestMatchesYes
payloadDigestYes
evidenceRowsMatchYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read"
    • removedInput schema / properties / locale / default
      Removed value: -"en"
    • changedInput schema / properties / locale / description
      Previous value: -"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)"
  2. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"The receipt id (a UUID), from the receipts that change_history lists"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare a safe read (readOnly/idempotent/non-destructive), but the description goes well beyond: the check 'runs live on every call', the enumerated failure codes (DIGEST_MISMATCH, NOT_CANONICAL, COLUMN_MISMATCH:<field>, EVIDENCE_ROWS_MISMATCH, PAYLOAD_UNREADABLE), the error on unknown/non-public ids, and quota semantics ('one call of the key's quota... a rejected argument costs nothing').

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

Conciseness4/5

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

Purpose, usage, parameters and behavior are front-loaded in a logical order with no filler sentences. It is dense and somewhat run-on, packing return fields, error codes and quota into one paragraph, which slightly hurts scanability.

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 verification tool with an output schema, the description still supplies everything needed to call it correctly: id provenance, locale scope, live-check behavior, failure vocabulary, error conditions and quota cost. Nothing an agent needs is missing.

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?

Schema coverage is 100% and the schema already documents both params well, so the baseline would be 3. The description adds real disambiguation beyond the schema by warning that id is 'never a change id' and clarifying that locale 'translates only the notice', which is not stated in the schema.

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?

States a specific verb and resource ('Verify a receipt: recompute its digest from the stored record') plus the exact outcome fields reported. It also explicitly distinguishes itself from the sibling get_receipt by noting it 'does not return the content', so an agent can route between them without opening a 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?

Gives an explicit when-to-use ('Use it before citing a receipt, after get_receipt has shown what it says') and a semantic boundary ('it is not a certificate that a claim is true'). It also names the upstream tool whose output supplies the id, leaving nothing to inference.

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

All AiSeek toolsInspect
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