Server Quality Checklist

Tool Scores

• attribution_badgeA
  4.2/5.0
  Behavior3/5

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

  No annotations provided; description is brief and does not disclose any side effects, permissions, or limitations, but simple badge generation likely non-destructive.

  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?

  Single sentence with no unnecessary words, front-loading the action and purpose.

  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 zero-parameter, no-output-schema tool, the description covers purpose and embedding context, though exact Markdown format is unspecified.

  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?

  Input schema has zero parameters with 100% coverage; description adds no param info, baseline per rules is 4.

  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 a Markdown badge for embedding, signaling content checked with Groundcheck, distinguishing it from sibling tools.

  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 mentions embedding in README/report, providing usage context, though no explicit when-not-to-use or alternatives.

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

• check_citationsA
  4.6/5.0
  Behavior4/5

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

  No annotations were provided, so the description carries full burden. It discloses that the tool returns a per-claim report with verdict, sufficiency, and a conformal guarantee, plus a signed receipt. It also mentions limitations. However, it does not explicitly state if the tool is read-only or destructive, though the nature of fact-checking implies read-only.

  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 well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS) and is concise, packing essential information into a short paragraph without 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?

  Given no output schema and no annotations, the description covers purpose, usage, parameters, limitations, and distinguishes from siblings. It includes details about the return format and receipt, which is sufficient for most use cases. The only minor gap is not specifying the exact structure of the claim report beyond verdict and sufficiency.

  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 description adds context to the schema: 'text = the prose (claims extracted automatically)' and reiterates the range for maxClaims. Since schema coverage is 50%, the description compensates by clarifying the meaning of 'text' and that claims are extracted automatically.

  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 (fact-check), resource (claims in a block of text), and explicitly distinguishes from the sibling verify_claim by noting it is the batch form. It also specifies the use case: AI-generated drafts before publishing.

  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?

  The description provides explicit guidance on when to use the tool ('before you publish or act'), when not to ('Use verify_claim for a single claim'), and details limitations such as skipping questions/opinions and maxClaims bounds.

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

• attest_deliveryA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavioral traits: it judges only consistency (not service quality), records payment receipt but requires separate on-chain confirmation, and notes that schema conformance is structural. It also mentions the paid nature of the hosted engine and links to documentation for verification.

  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 well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE) and front-loaded key points. Though slightly long, every sentence adds value and there is no redundancy.

  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?

  Despite lacking an output schema, the description thoroughly explains the return types (delivery_verdict, payment binding, attestation) and notes that the full response is a self-contained dispute artifact. It also provides example output and mentions the need to save it, ensuring completeness for an agent.

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

  Parameters5/5

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

  Schema description coverage is 100%, but the description goes beyond by explaining each parameter's role in context (e.g., responseText is 'the delivered payload verbatim', paymentReceipt is 'X-PAYMENT-RESPONSE value'). An example call further clarifies how to use the parameters together.

  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 purpose as 'Neutral delivery verification for agentic commerce.' It specifies that it verifies delivered content and returns a signed receipt binding payment to delivery to content. This distinguishes it from siblings like verify_claim, as it focuses on delivery integrity rather than fact-checking.

  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?

  The description gives explicit usage instructions: 'call AFTER a paid third-party call whose output you will act on or account for.' It provides branching logic based on delivery_verdict (consistent -> proceed, degraded -> caution, inconsistent -> do not rely, unverifiable -> no contradiction). It also advises saving the receipt for dispute evidence.

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

• extract_claimsA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description carries full burden. It discloses rule-based, deterministic extraction, limitations (skips non-factual statements, under-splitting), and payment model. No contradictions 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?

  Well-structured with clear sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every sentence adds value, front-loaded with purpose and usage.

  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?

  Complete for a 2-parameter tool without output schema. Explains return format, limitations, example, and payment context. No gaps.

  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 description adds usage context (maxClaims range, default, example). Minimal extra semantics beyond schema, so slight deduction from perfect.

  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 explicitly states the purpose as splitting text into atomic factual claims for verification loops. It uses specific verbs and resources and distinguishes from sibling tool check_citations.

  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?

  Provides clear guidance on when to use (e.g., before grounding, for budgeting, proving claims) and explicitly names check_citations as an alternative for combined extraction and grounding.

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

• resolve_instrumentA
  5/5.0
  Behavior5/5

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

  No annotations provided, but description fully compensates: discloses conservative matching ('matched=false' rather than guessing), states it does not price instruments or resolve crypto, and mentions return includes 'provenance and a signed receipt'. Very transparent.

  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?

  Highly structured with clear sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Each sentence adds value, no fluff. Efficient and well-organized.

  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?

  Comprehensive for a resolution tool with no output schema: describes what is returned (FIGI records, provenance, receipt) and limitations (no pricing, no crypto). Covers all essential aspects for correct invocation.

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

  Parameters5/5

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

  Schema has 67% coverage; description adds meaningful context for all 3 parameters: explains `query` purpose, notes `idType` auto-detection, and specifies range and default for `maxResults`. Goes beyond schema info.

  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?

  Clearly states the verb 'resolve' and resource 'security identifier to canonical FIGI records via OpenFIGI'. Distinguishes from sibling tools by focusing on instrument resolution and disambiguation.

  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?

  Explicitly advises to call 'BEFORE acting on any claim, order, or document', explains why (disambiguation, provenance), and suggests preferring explicit identifiers. Provides clear context for when and how to use.

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

• verify_claimA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: returns verdict, sufficiency, guarantee, per-part atoms, and receipt. Explains weakest-link splitting, limitations on recent/private claims, and guarantee only on calibrated deployments.

  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?

  Well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every sentence adds value, no redundancy.

  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?

  Despite no output schema, description details all return fields and how to use results (e.g., gate on sufficiency and verdict). Limitations and example make it complete for agent use.

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

  Parameters5/5

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

  Schema coverage is only 50% (maxSources missing description). Description adds critical detail: claim must be 'ONE complete declarative sentence' and maxSources range 1-10 with default 5, exceeding schema info.

  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?

  Description starts with 'PURPOSE: Fact-check one claim against live sources' and lists specific outputs. Clearly distinguishes from sibling tools like check_citations and extract_claims by focusing on verification with a gate-ready result.

  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?

  Explicit guidelines: 'Call BEFORE asserting or acting on a fact you are unsure of' and 'Prefer over an LLM's own judgment'. Also provides conditions for abstaining and gating decisions.

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