Every receipt wefetch issues. Anyone can verify one.
Scored across 4 tools
Each tool has a clearly distinct role: monthly aggregate retrieval, receipt listing, single-receipt verification, and receipt issuance. The boundaries between get_statement and list_receipts are especially clear because one is a signed monthly summary while the other is a filtered receipt list.
All four tools follow a consistent snake_case verb_noun pattern: get_statement, list_receipts, verify_receipt, write_receipt. The convention is predictable and easy for an agent to follow.
Four tools is well-scoped for a focused receipt issuance and verification service. Each tool covers a distinct part of the lifecycle without unnecessary surface area.
The surface covers issuing, listing, verifying, and reporting on receipts, which matches the core domain. Minor gaps remain, such as no standalone non-verifying receipt fetch and no pagination beyond the 500-receipt limit, but these are workable around.
The signed statement for a month (YYYY-MM): receipts issued, by result, by country and by key id, the receipts that supersede earlier ones, and the chain tip.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing that the statement is *signed* and includes superseded receipts plus the chain tip — non-obvious contents not derivable from annotations — but says nothing about size, latency, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the resource and then enumerates contents; no filler. The nested list of contents is slightly comma-heavy but each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full annotations and an output schema, the description covers what the statement contains without duplicating return-value documentation. The only material gap is the meaning of the default/empty month.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single month parameter, so the description must carry meaning: it does specify the YYYY-MM format, which the schema omits. However, it never explains the empty-string default (presumably current month), leaving the most ambiguous case undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the signed statement for a month) and enumerates its contents — receipts by result, country, key id, superseding receipts, and the chain tip. It is clearly distinct from list_receipts or verify_receipt, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the month parameter signals a periodic reporting query, but there is no statement of when to choose this over list_receipts or verify_receipt, nor any prerequisite or exclusion noted. An agent must infer the selection criteria from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List receipts, newest first, by barcode (subject), country (market) or date (since, YYYY-MM-DD); up to 500.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| market | No | ||
| subject | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value with the result ordering ('newest first') and a result cap ('up to 500'), but leaves the default page size (50 in schema) and pagination behavior unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the verb, resource and ordering, then packs the filter mapping and cap into the tail. Nothing is wasted, though the parenthetical 'field (param)' notation is terse and 'up to 500' is slightly ambiguous between a max limit and a total result cap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and the tool is simple with zero required parameters. Still missing for a four-parameter list tool are the meaning of limit, whether omitted filters mean 'all', and any hint of paging beyond 500 results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it maps three of four parameters to real-world meaning: subject=barcode, market=country, since=date with an explicit YYYY-MM-DD format. Only 'limit' is left implicit, conveyed only obliquely by the 'up to 500' ceiling, and the empty-string defaults are not addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List receipts') plus the ordering ('newest first') and the three filter axes. It is clearly distinguishable from write_receipt and verify_receipt by its enumeration framing, though it never names a sibling to contrast with get_statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the enumeration tool for browsing receipts by barcode, country or date. There is no explicit when-to-use versus get_statement, no statement about what happens when all filters are omitted (presumably all receipts), and no guidance on paging past the cap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one receipt by id (pm_…), in public: the receipt, its hash, id, signature and chain link checked, the receipts that supersede it, and the public key it was signed under.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by enumerating what actually gets checked: the receipt, its hash, id, signature, chain link, superseding receipts, and the signing public key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the action and id format front-loaded, followed by the check list. The clause structure ('in public: the receipt, its hash, id, signature and chain link checked, the receipts that supersede it…') is slightly run-on and loses parallel form, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return shape, yet it usefully previews what verification covers. A note on failure behavior (what a failed verification looks like) would round out the picture for a 1-param, annotated read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the single parameter — and it does, giving both the meaning (a receipt id) and the expected 'pm_…' prefix. Nothing is added about the id's provenance or validity rules beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify one receipt by id') plus a concrete id-format hint (pm_…), which separates it from list_receipts and write_receipt by implication. It never names a sibling or explicitly contrasts scope, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'in public' signals the verification is a public, unauthenticated check, which is implied guidance about context. There is no explicit when-to-use or when-not rule, and no routing to get_statement or list_receipts for other receipt needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue one receipt (issuer credential required, as the credential argument or a Bearer header). subject = the barcode; market; core_version; profile_version; answer_hash; match_hash; result = verified · listed · stale · unknown with the four readings (source_authority, disagreement, freshness, authorisation); supersedes = an earlier receipt id, when this one replaces it. Never revokes.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| result | Yes | ||
| subject | Yes | ||
| freshness | Yes | ||
| credential | No | ||
| match_hash | Yes | ||
| supersedes | No | ||
| answer_hash | Yes | ||
| verified_at | No | ||
| core_version | Yes | ||
| disagreement | Yes | ||
| authorisation | Yes | ||
| profile_version | Yes | ||
| source_authority | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-read-only, non-destructive, non-idempotent write. The description adds real value beyond them by disclosing the issuer credential requirement (argument or Bearer header), scoping the mutation with "Never revokes," and explaining that replacement is via supersedes rather than overwrite. It stops short of describing what happens on duplicate issuance or failure, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It opens with the core action and the critical auth caveat, but degenerates into a long semicolon-chained list that is hard to parse. Information is dense and mostly earns its place, though the run-on structure hurts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, 11-required mutation tool with an output schema (so return values needn't be explained), the description covers authentication and the most consequential fields. However, several required parameters remain semantically opaque, leaving an agent to guess at values for a write operation, which is a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden. It defines the crucial parameters well (subject = barcode, result = verified/listed/stale/unknown, the four readings, supersedes) but leaves several others (verified_at, market, core_version, profile_version, answer_hash, match_hash) as bare names with no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: "Issue one receipt," and bounds the operation with "Never revokes," so an agent can tell it creates rather than removes records. It does not name any of the siblings (verify_receipt, list_receipts, get_statement) to explicitly route between them, but the action and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the credential requirement and the supersedes mechanism tell the agent what preconditions and replacement scenarios look like, and "Never revokes" rules out a revocation use case. There is no explicit when-to-use-vs-sibling guidance (e.g., vs verify_receipt), which keeps this at minimum-viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_statementlist_receiptsverify_receiptwrite_receiptIssue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Verify Seal AI decision receipts: signed evidence anyone can check, no account needed.
Market evidence with receipts: every claim resolves to a real stored record you can fetch back.
Ed25519 receipts over work artifacts: issue and verify offline, no account, no chain, no network.
Add one secure layer between your agents and this server.
