Server Quality Checklist

Tool Scores

• get_receiptA
  3.8/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable context: raw prompt/response are never stored, receipts contain proof material only, and no wallet is needed. This clarifies the public nature and auth requirements beyond the annotations.

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

  Conciseness5/5

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

  Two concise sentences with the key action and constraints front-loaded. The free tag and public nature are stated first, followed by the content and the privacy caveat. Every sentence earns its place; no redundancy.

  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?

  Despite having no output schema, the description lists the receipt's contents and clarifies the public nature. It covers the parameter adequately, and annotations handle safety. The only missing piece is an explicit note about the return structure, but the listed fields serve as a sufficient guide for a fetch operation.

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

  Parameters3/5

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

  Schema coverage is 100% with a clear description for attestation_id ('Attestation id (att_…)'). The tool description adds no extra semantic detail beyond what the schema provides, so the baseline of 3 applies.

  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 description clearly states the verb 'fetch' and the resource 'public receipt for an attestation', listing the specific proof material included (content hash, model, timestamps, Ed25519 signature, Merkle anchor proof). It distinguishes itself from siblings by focusing on fetching a receipt rather than notarizing or verifying.

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

  Usage Guidelines2/5

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

  The description does not provide explicit when-to-use guidance or contrast with alternatives like verify_attestation. The 'FREE' qualifier hints at a cost aspect but doesn't explain scenarios where this tool is preferred over its siblings.

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

• notarize_batchA
  4.2/5.0
  Behavior4/5

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

  With annotations declaring readOnlyHint=false (mutation), the description adds valuable disclosure beyond what annotations provide: the operation costs $0.005 USDC, requires WALLET_PRIVATE_KEY or SOLANA_PRIVATE_KEY, and produces persistent signed attestations. This surfaces the cost and auth prerequisites an agent needs before invoking, which is genuinely helpful and consistent with the annotations.

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

  Conciseness5/5

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

  Two sentences with zero waste: the core capacity and benefit are front-loaded, and the cost/auth detail is appended. Every clause earns its place and no structured data is repeated.

  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 single-parameter tool with nested objects fully documented in the schema, the description covers purpose, capacity, use case, cost, and auth. The only gap is the response/return format (no output schema exists), which is a minor omission given the tool's simplicity and the richness of the annotations.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema fully documents prompt, model_id, response, and client_timestamp including the content-hash inclusion caveat. The description does not add meaning beyond the schema, so the baseline of 3 applies—the schema carries the burden and does so adequately.

  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 (notarize), a specific resource (AI inferences), and a batching capacity (up to 20, one signed attestation per record). The phrase 'Ideal for audit trails and agent pipelines' conveys the intended use case. It clearly differentiates from notarize_inference via the batch capacity, so an agent can tell them apart.

  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?

  Provides clear context ('Ideal for audit trails and agent pipelines') that an agent can use to decide when batching is appropriate. However, it does not explicitly name the sibling notarize_inference or state the trade-off (single vs. batch), so the exclusion is implied rather than explicit.

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

• verify_attestationA
  4.3/5.0
  Behavior4/5

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

  Annotations already establish read-only, open-world, non-destructive behavior. The description adds valuable context: it's free, requires no wallet, returns specific verification artifacts, and the Merkle proof depends on batch sealing. This goes beyond the structured annotations by disclosing operational conditions (sealing) and cost implications.

  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?

  The description is a single, dense sentence that front-loads the key value proposition ('FREE — verify any attestation') and packs in usage instructions, return contents, and a caveat (sealing). It is efficient and well-structured, with no fluff, though slightly packed with clauses.

  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 read-only verification tool with 6 params (1 required) and no output schema, the description covers what inputs to provide, what results to expect, and a timing constraint (batch sealed). It does not describe error cases or output formatting, but given the tool's simplicity and the annotations, it is sufficiently complete for an agent to select and invoke it correctly.

  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%, so individual descriptions are clear. The description adds semantic value by clarifying the 'either/or' relationship between content fields (prompt, response, model_id) and content_hash, and by implying client_timestamp affects the hash. This logical grouping is not explicit in the schema alone, so the description earns a boost above baseline.

  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 description clearly states the tool's verb ('verify') and resource ('any attestation issued by the notary'), and specifies it returns signature check, hash comparison, and Merkle proof. This distinguishes it from siblings like notarize_inference (creation), get_receipt (retrieval), and notary_pubkey (key access) without ambiguity.

  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 explicitly instructs how to call it: supply attestation_id plus either original content (prompt, response, model_id) or content_hash. It also notes the batch must be sealed for the Merkle proof and 'No wallet needed' as a prerequisite. It does not explicitly name alternatives, but the context makes it clear this is the verification tool versus the other siblings.

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

• notarize_inferenceA
  4.5/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=false and destructiveHint=false, and the description complements this with critical behavior: the notary does not store prompt/response (privacy), costs $0.001, and requires specific private keys. It also details the return payload. This goes beyond annotations, though it does not cover failure modes or idempotency nuances. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is compact and well-structured. The main action is front-loaded in the first sentence, followed by essential details (return type, privacy, cost, key requirements). Every sentence adds necessary information without redundancy. It is appropriately sized for a tool with payment and privacy implications.

  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 paid, side-effecting tool with no output schema, the description provides a comprehensive picture: it lists return items (attestation, hash, Merkle status), privacy guarantees, cost, and required credentials. It covers the prerequisites and expected behavior thoroughly, leaving little ambiguity for an agent deciding to call it.

  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 has 100% parameter description coverage, so the baseline is 3. The description adds value by specifying that {prompt, response, model_id} are the triple used for hashing and that client_timestamp is optional and included in the content hash. This clarifies the relationship between parameters and the receipt's integrity, elevating the score above baseline.

  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 description opens with a specific verb and resource: 'Get a cryptographic receipt for one AI inference.' It clearly states what is returned (signed Ed25519 attestation, sha256 hash, Merkle status) and what is not stored, distinguishing it from batch notarization and verification siblings. The purpose is unambiguous.

  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?

  The description explicitly says 'one AI inference,' implying not for batch use, and mentions the payment requirement (x402 with wallet keys), which is a critical prerequisite. However, it does not explicitly name alternatives like notarize_batch or get_receipt, leaving some routing to the agent. The context is clear enough but lacks direct when-not-to-use guidance.

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

• notary_pubkeyA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: the key format, offline verification capability, and that it's free. This goes beyond the annotations without contradicting them, enhancing the agent's understanding of the tool's behavior.

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

  Conciseness5/5

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

  A single sentence that packs all essential information: free, key type, encoding, raw length, use case, and no wallet requirement. No wasted words, front-loaded with the most important fact (FREE) followed by the resource.

  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 zero-parameter, read-only tool with no output schema, the description fully addresses what the agent needs: the return value's format and the offline verification context. The annotations cover safety, so nothing critical 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?

  The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema coverage is 100% (empty object). No additional parameter info required.

  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 description clearly states the tool returns the notary's Ed25519 public key in a specific format (base64, raw 32 bytes) for offline signature verification. It distinguishes itself from siblings like notarize_inference and verify_attestation by focusing on key retrieval rather than notarization or attestation operations.

  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 explicitly mentions 'for fully offline signature verification' and 'No wallet needed', giving a clear use case. While it doesn't name alternative tools or say when not to use them, the context is sufficient for an agent to understand when this key-fetching tool is appropriate.

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

• notary_statsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's addition of 'FREE' and 'No wallet needed' provides useful access/cost context beyond structured data. The 'live' attribute also adds a real-time behavior detail. These are valuable but not exhaustive; no mention of rate limits or response format is made, though annotations cover the safety profile.

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

  Conciseness5/5

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

  The description is a single concise sentence with high information density. It front-loads 'FREE' and 'live aggregate stats,' then lists the key data points, and ends with a clear access requirement ('No wallet needed'). Every word earns its place.

  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 simple read-only stats tool with no parameters and no output schema, the description covers the essential information: what data it returns and the access prerequisites. While it doesn't specify the exact response structure, the enumerated fields give an agent sufficient context to understand the output. There is no missing information that would prevent 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?

  The tool has zero parameters and schema coverage is vacuously 100%. The description does not need to explain parameters. For a no-argument tool, the baseline of 4 is appropriate; there is nothing further to clarify about inputs.

  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 description clearly states the tool provides 'live aggregate stats' and enumerates exactly what data is included: total notarizations, 24h volume, top models by attestation count, sealed/anchored Merkle batches. This distinguishes it from siblings like notarize_inference or verify_attestation, which perform actions rather than reporting statistics.

  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?

  The description implies usage by positioning this as an aggregate stats endpoint with no wallet needed, suggesting it is for general monitoring. It does not explicitly mention 'use this for stats, not for specific records,' but the contrast with sibling tools like get_receipt and verify_attestation is implicit and sufficient for an agent to route appropriately.

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