Crinkl Commerce MCP

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

With no annotations, the description fully explains the polling behavior, response statuses, and lack of authentication. However, it does not mention any polling timeout or rate limits, which would improve transparency further.

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?

Three concise sentences, front-loaded with purpose. Every sentence adds value: purpose, behavior, polling interval, and auth requirement. No extraneous words.

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 polling tool with no output schema, the description covers purpose, usage flow, response codes, and authentication. It lacks details on polling duration or error handling beyond 410, but is largely complete for its complexity.

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 100% with clear descriptions for both parameters. The description adds context by linking them to the pair-agent flow but does not introduce new semantics beyond what the schema provides, earning the baseline score of 3.

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 clearly states the tool polls for an API key after human approval of the pairing code. It specifies the flow, response codes, and polling frequency, distinguishing it from the sibling 'pair-agent' tool that initiates the pairing.

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?

Explicitly advises polling every 5 seconds and explains the meaning of each HTTP response code (202 pending, 200 ready, 410 expired). This gives clear when-to-use and how-to-use guidance without requiring additional context.

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

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

With no annotations provided, the description fully bears the burden of transparency. It details what is returned (live authority levels, delegated capabilities, governance controls, etc.) and mentions 'live' data, implying no side effects. This adequately discloses behavior beyond the schema.

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?

The description is a single sentence that lists many data elements. While slightly long, it is well-organized and front-loads the main purpose ('Get Crinkl's canonical external agent capability catalog'). Every part adds value, though it could be split for 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?

Given zero parameters and no output schema, the description comprehensively explains what the tool returns, including a detailed list of data categories. It fully equips an agent to understand the tool's output without needing additional documentation.

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?

The input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter info. Baseline 4 is appropriate as no further context is required.

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 clearly states the tool returns 'Crinkl's canonical external agent capability catalog' and enumerates specific data items like authority levels, delegated capabilities, and gateway/MCP details. It distinguishes itself from sibling tools by focusing on agent capabilities, which none of the listed siblings do.

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?

The description implies use for retrieving agent capabilities but does not explicitly state when to use it or when not to. No alternatives or exclusions are mentioned, leaving the agent to infer usage context. However, the purpose is clear enough that guidance is not critical.

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

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

No annotations provided, so description carries burden. Discloses auth requirement (apiKey) and return details, but lacks discussion of side effects, rate limits, or data freshness.

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?

Two concise sentences with front-loaded purpose; efficient and to the point.

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 simple tool with one parameter, description adequately covers what is returned and the distinction between per-API and wallet stats. Lacks output format but acceptable given no output schema.

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 covers 100% of parameter with description; description adds only slight additional context (e.g., 'Crinkl agent API key') beyond schema.

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?

Clearly states what the tool does: returns submission count, earned sats, and wallet-level stats. Distinguishes between per-API-key and wallet-wide numbers, and mentions key return value satsPerReceipt.

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?

Implies usage for agent stats, but does not explicitly state when to use this tool versus the many sibling get-* tools or provide 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.

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

The description discloses that the tool returns a cryptographically signed token with specific fields and mentions the live beta cumulative total. However, with no annotations provided, it lacks details on side effects, authentication, or rate limits, so transparency is moderate.

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?

The description is three sentences and includes necessary details without significant fluff. It could be slightly more streamlined but is generally well-structured and efficient.

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?

Given no output schema, the description explains the return value effectively. It covers purpose, parameter behavior, and output format. While missing error handling and endpoint details, it is largely complete for a straightforward read-type 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 coverage is 100%, providing baseline 3. The description adds value by clarifying the startDate parameter's purpose with the specific default date (2026-01-27), giving contextual meaning beyond the schema's generic description.

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 clearly states the tool gets cumulative GMV from a public cumulative feed and mentions the specific beta/alpha context. However, it does not explicitly differentiate from siblings like 'get-trailing-gmv' or 'get-daily-gmv', which could lead to confusion.

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?

The description suggests providing startDate to bound the window but does not provide when-to-use or when-not-to-use guidance relative to similar sibling tools. No alternatives are mentioned, leaving the agent to guess which GMV tool is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It discloses return fields (verified spend count, total USD cents, cryptographic signature) and verification using Ed25519, providing good behavioral context without missing critical disclaimers.

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?

Two sentences, each purposeful. The first defines the core action, the second details return values and verification. There is no unnecessary text, and it is front-loaded with the key purpose.

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 one parameter, no output schema, and no annotations, the description sufficiently covers the tool's function and return details. It is complete for a simple retrieval tool, though it could mention return format.

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 100% with a single parameter described in the schema. The description adds marginal value by reiterating 'specific calendar date (UTC)' but does not enhance meaning beyond the schema.

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 clearly states 'Get the signed GMV summary for a specific calendar date (UTC)', specifying the verb, resource, and scope, and distinguishes it from siblings like get-cumulative-gmv and get-trailing-gmv.

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?

The description implies use for a specific date but does not explicitly compare to alternatives or provide when-not-to-use guidance. It lacks exclusions or context for choosing this over similar tools.

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

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

No annotations are provided, so the description bears the full burden. It explains the return values and the verification purpose, but does not disclose potential side effects, authentication needs, or rate limits. The description is transparent about the output but lacks broader behavioral context.

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?

Three sentences: first states the action, second lists returned values, third explains the value proposition. No redundant words; front-loaded with the core purpose.

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?

Given the simple input and output, the description is largely complete. It covers purpose, return values, and the verification context. However, it could briefly note that the spend must already be included in a daily GMV, which is implied but not explicit.

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 100% for the single parameter spendId, and the schema already provides a clear description. The tool's description adds context about the proof but not about the parameter itself. Baseline 3 is appropriate as the schema carries the parameter documentation.

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 clearly states the tool retrieves a Merkle inclusion proof for a specific spend, specifying the returned components and the cryptographic verification purpose. This distinguishes it from sibling tools like get-daily-gmv and get-cumulative-gmv.

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?

The description implicitly guides usage by explaining that the proof allows independent verification, but does not explicitly state when to use this tool versus alternatives like verify-issued-gmv or other GET tools. The context of cryptographic verification is clear, but no exclusions are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a public key in base64 format and is a read operation. It does not discuss potential failure modes or caching behavior, but for a simple retrieval, this is sufficient.

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?

The description is two sentences, both essential. It front-loads the main action and provides immediate context on the key's usage. No wasted words.

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 tool with no parameters and no output schema, the description covers the key information: what it does, why it's used, and the output format. Minor gaps, such as whether the key is stable or cached, exist but do not severely impact completeness.

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?

The input schema has no parameters (schema coverage 100%), so the description doesn't need to document parameters. It adds value by specifying the output format (base64), which is not in the schema. This exceeds the baseline score of 4 for zero-parameter tools.

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 clearly states that the tool retrieves the Crinkl authority's Ed25519 public key, which is used to verify signatures on attestation tokens. This distinguishes it from sibling tools that deal with GMV, merchants, or receipts.

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?

The description explains when to use the tool: to get the public key for verifying token signatures. It does not explicitly mention alternatives or when not to use it, but given the unique purpose among siblings, the context is clear.

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

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

The description only mentions data source (verified receipt attestations) but lacks details on side effects, authentication, rate limits, or behavior when no data is available. With no annotations, the description should disclose more operational traits.

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?

Three sentences, each adding value: first states action, second lists outputs, third specifies data source. Very efficient with no filler.

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?

Describes outputs adequately but omits return format, pagination, or any edge cases. Given no output schema and no params, a bit more detail on result structure would improve completeness.

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?

No parameters exist in the input schema (0 params, 100% coverage). The description does not need to add parameter info, and the baseline of 4 is appropriate given no work needed.

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?

Description clearly states it returns aggregated merchant and category distribution across verified spends, listing specific outputs (top store brands, category breakdown, concentration metrics). This differentiates it from sibling tools like get-spend-distribution or get-protocol-summary.

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?

No guidance on when to use this tool versus alternatives (e.g., get-spend-distribution, get-settlement-summary). The description implies it's for merchant-level analysis but does not explicitly state conditions or exclusions.

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

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

Since no annotations are provided, the description must convey behavioral traits. It states that it 'Returns a plain-text overview,' implying a read-only operation with no side effects. It could be more explicit about requiring no authentication or state changes, but the description is transparent enough for a simple retrieval tool.

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?

The description is extremely concise with two sentences, front-loading the purpose and usage guidance. Every sentence adds value: first defines the tool, second provides when-to-use context and output format.

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?

Given the tool has no parameters and no output schema, the description is complete. It specifies the purpose, usage context, and return type (plain-text overview of verification pipeline, token types, settlement model). No further information is needed.

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?

The input schema is empty with no parameters, and schema description coverage is 100%. According to guidelines, baseline is 4 for 0 parameters. The description does not add parameter semantics because none exist.

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 clearly states the tool's purpose: 'Get a concise explanation of what Crinkl is and how the protocol works.' It uses a specific verb ('Get') and resource ('explanation of the protocol'), and distinguishes it from sibling tools like get-merchant-summary or get-gmv-inclusion-proof by focusing on protocol overview.

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?

The description explicitly says 'Use this first if you have no prior context about Crinkl,' providing a clear when-to-use guideline. However, it does not mention when not to use it or name alternative tools, though the context of being a first-step overview is sufficient.

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

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

No annotations provided, so the description carries full burden. It discloses that rewardCommitmentToken and batchAnchor may be null due to asynchronous batching, and instructs on checking per-step verification results. This goes beyond basic function to explain behavioral nuances.

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?

The description is concise with upfront purpose and subsequent detail. Each sentence adds value, though it could be slightly more streamlined without losing information.

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?

Given the tool has one optional parameter, no output schema, and no annotations, the description provides comprehensive context: what the bundles contain, their limitations, handling of null fields, and verification instructions. This is sufficient for an agent to understand invocation and interpretation.

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 100% with a clear description for the single 'limit' parameter. The description does not add further semantic value beyond what the schema already provides, so baseline score of 3 applies.

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 clearly states the tool retrieves 'recent gateway-issued artifact bundles for portable spend/GMV verification' and lists specific items included. It distinguishes from sibling tools like 'get-gmv-inclusion-proof' by focusing on recent bundles.

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?

The description provides context on what the bundles are used for and explicitly clarifies they are not proof of Bitcoin settlement or chain finality. It directs users to check 'steps' and 'ok' fields. However, it does not explicitly state when to prefer this tool over siblings or exclude scenarios.

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

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

With no annotations, the description fully addresses behavioral traits: it mentions 'Updated daily', 'deterministic', and clarifies that the policy hash covers the full parameter set. This leaves no ambiguity about side effects or freshness.

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?

The description is two sentences, front-loaded with the main action, and includes all necessary details without redundancy.

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?

Given no parameters, no output schema, and the tool's simple nature, the description fully covers what the tool returns and its behavior (daily updates, determinism). No additional information is needed.

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?

The tool has no parameters, so the description's role is minimal. However, it adds value by describing the output fields, providing context that goes beyond the schema's lack of properties.

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 clearly states the action ('Get the current Crinkl reward policy') and lists the specific resources returned (policy version, hash, parameters, multipliers, reserve checkpoint). It is distinct from sibling tools which focus on GMV, merchants, etc.

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?

While no explicit when-to-use or alternatives are mentioned, the description is contextually clear for a read-only getter. The sibling tools are unrelated, making usage straightforward. A minor improvement would be stating that this is the canonical source for policy data.

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

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

No annotations provided, so description carries full burden. Discloses that the tool returns settlement metrics and is not a verifier, but does not mention rate limits, authentication, or data freshness. Adequate but not thorough.

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?

Three sentences: purpose, detailed output list, a caveat. Front-loaded, no wasted words.

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?

No output schema, no annotations. Description covers returned fields and a key limitation. Missing context on when to use among 21 sibling tools, but otherwise complete.

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?

Zero parameters, schema coverage 100%. Baseline is 4; description adds no parameter info but does not need to since none exist.

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?

Description begins with a specific verb-resource combination 'Get reward settlement statistics' and lists distinct metrics, clearly differentiating from sibling tools like get-protocol-summary or get-gmv-inclusion-proof.

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?

Implies usage by describing output, but lacks explicit guidance on when to use this tool vs siblings. The caveat 'it is not a chain-finality or payout-proof verifier' is helpful but not a full usage guide.

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

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

No annotations are provided, so the description must stand alone. It describes the output (breakdown by category and CBSA) but lacks details on side effects, error behavior, or data freshness. However, it is a read-only operation and the description is accurate.

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?

The description is two sentences (32 words), front-loaded with the main purpose, and contains no wasted words.

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 simple tool with one optional parameter and no output schema, the description sufficiently explains the output and scope. Minor omission: the parameter is not mentioned, but it's optional and documented in the schema.

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 100% (one parameter 'days' with a clear schema description). The tool description adds no additional parameter information, so it meets the baseline of 3.

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 clearly states it returns geographic and category distribution of verified spends over a trailing window, differentiating it from sibling tools focused on GMV, proofs, or merchant data.

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?

The description implies usage for analyzing spend distribution but does not explicitly state when to use it versus alternatives or when not to use it.

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

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

With no annotations, the description fully discloses the data's verification process (OCR, store resolution, hard verification) and content (store name, category, CBSA code, spend amount, no PII). It could mention rate limits or default behavior (e.g., limit default 20) but effectively conveys what the tool does and its properties.

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?

The description is two concise sentences that convey purpose, data details, and a cross-reference to another tool. Every sentence adds value with no redundancy or filler.

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 tool with a single parameter and no output schema, the description completely covers what the tool does, what data it returns, and how to interpret the output (CBSA codes). It is self-contained and gives sufficient context for an AI agent.

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 100% with the 'limit' parameter fully described in the input schema. The tool description does not add any additional meaning to the parameter beyond what the schema provides, so a baseline score of 3 is appropriate.

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 clearly states the tool retrieves 'recent verified spend activity signals' from the Crinkl network, specifying the resource and action. It distinguishes itself from sibling tools by detailing the nature of signals (cryptographically attested, passed OCR extraction, etc.) and referencing resolve-cbsa for metro names, which is not done by other tools.

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?

The description provides context on what the tool returns (recent verified signals) and advises using resolve-cbsa for CBSA code conversion. It does not explicitly state when not to use this tool or provide exclusive alternatives, but the guidance is clear for a straightforward retrieval tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the returned figures are 'verified' and 'backed by individually signed spend attestation tokens,' which adds some context about data integrity. However, it does not mention read-only nature, rate limits, or permissions required.

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?

The description is concise with two sentences. The first sentence front-loads the main purpose, and the second adds valuable detail about data verification. No unnecessary words or repetition.

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?

Given the lack of an output schema, the description explains the output consists of daily GMV figures with verification details. However, it does not specify output structure, ordering, date format, or pagination, leaving some ambiguity for an AI agent.

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 100% as the only parameter ('days') is described in the schema (default 7, max 90). The description adds the term 'N-day' but does not provide additional semantics beyond what the schema already conveys. Baseline 3 is appropriate.

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 clearly states it retrieves a rolling N-day GMV trend summary, specifying the verb 'Get' and the resource as a trend summary. It implies differentiation from sibling tools like get-daily-gmv (single day) and get-cumulative-gmv (cumulative), but does not explicitly distinguish, leaving room for ambiguity.

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?

The description provides no guidance on when to use this tool versus alternatives such as get-daily-gmv or get-cumulative-gmv. It vaguely mentions 'enabling trend analysis' but does not specify use cases or when not to use it.

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

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

With no annotations provided, the description carries the full burden. It states 'No authentication required', indicating a public endpoint and a safe read operation. It does not disclose data freshness, rate limits, or response format, but for a simple list retrieval, this may suffice.

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?

The description is only two sentences, concise and front-loaded. Every sentence adds value: the first states the core action, the second provides usage context and authentication requirement.

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?

Given the simplicity of the tool (no parameters, no output schema needed), the description covers the key aspects: what is retrieved, why it's used, and authentication status. It could mention the return format, but the use case is clear enough.

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?

The tool has no parameters, so the schema coverage is 100%. The description does not need to add parameter semantics, but the baseline is 4 for zero-parameter tools. No further detail is required.

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 clearly states the tool retrieves 'currently approved DKIM vendor domains' from a specific endpoint, using specific verb 'Get' and resource 'vendor domains'. It is distinct 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.

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

The description explains that standalone agents use this list to seed Gmail searches and that unknown vendors are queued, providing context for when to use it. It also notes that no authentication is required. However, it does not explicitly state when not to use it or mention alternatives.

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

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

Discloses generation of 4-character code, return of code and 10-minute expiration, and that no authentication is needed. Adequate given no annotations.

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?

Two sentences, no filler. Front-loaded with the action and key details (code, expiration, no auth). Efficient and clear.

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 simple tool with one parameter and no output schema, the description covers purpose, behavior, and usage hints completely.

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 describes deviceToken as 'A random 64-character hex string.' Description adds critical context: 'Store this — needed to claim the API key.' Adds value beyond schema.

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 uses specific verb 'start' and resource 'human-authorized agent pairing flow'. It differentiates from sibling 'claim-api-key' by noting the generated code is needed for claiming the key.

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?

States 'No authentication required' and instructs to store the deviceToken for claiming the API key. Does not explicitly list when not to use, but the context is clear.

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

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

The description discloses the core behavior (conversion) and special handling of non-metro codes. However, it does not mention error handling for invalid codes or the return format, which would be helpful given the absence of an output schema.

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?

Three sentences are concise and front-loaded with the core purpose. Every sentence adds necessary detail without redundancy.

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?

Given the simplicity of the tool (one parameter, no output schema), the description covers the essential functionality and context. Minor omission: no mention of error behavior for unrecognized codes.

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?

The schema already covers the parameter description (100% coverage), but the tool's description adds value by contextualizing where CBSA codes appear (spend signals, distribution data), supplementing the schema's example.

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 clearly states the tool resolves CBSA codes to metro area names, provides concrete examples of input/output, and distinguishes it by explicitly mentioning it handles both standard 5-digit codes and non-metro codes.

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?

The description implicitly indicates usage when CBSA codes are encountered in spend signals/distribution data. There are no sibling tools performing similar functions, so no explicit usage exclusions are necessary, but guidance on when not to use is absent.

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

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

No annotations provided, but description fully discloses: email is discarded after verification, retained fields (vendor, date, total, currency), and all five possible HTTP return codes with meanings.

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?

Three sentences, front-loaded with the main action, efficient explanation of the process and outcomes without redundancy.

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?

Fully explains the lifecycle (submit, verify, retain, discard), return codes, and queuing behavior. No gaps given the tool's complexity and lack of output schema.

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 already covers both parameters with descriptions. Description adds valuable context: eml must be base64-encoded and required for DKIM verification; apiKey is a 'Crinkl agent API key'.

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?

Clear verb ('submit') and resource ('billing email') with specific constraints (DKIM-verified). Distinguishes from siblings like 'verify-receipt' by emphasizing the full submission and token minting process.

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?

States the prerequisite (DKIM-verified billing email) and the action to take (submit for token). Does not explicitly list non-use cases or alternatives, but context is clear.

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

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

With no annotations provided, the description fully discloses the verification steps and limitations. It mentions the optional batchAnchor parameter and its effect on the verification scope, leaving no behavioral ambiguity.

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?

The description is a single paragraph that is dense but not overly long. It front-loads the purpose and verification steps. However, it could be more scannable with bullet points or structured sections.

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?

Given the tool's complexity (5 parameters, nested objects, no output schema), the description covers the key aspects: verification steps, limitations, and the effect of the optional parameter. It does not describe return values or error conditions, but without an output schema, this is acceptable.

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?

While the input schema already provides 100% coverage with descriptions for each parameter, the description adds significant meaning by explaining how the parameters are used in the verification logic and the role of the optional batchAnchor. This goes beyond the schema's basic descriptions.

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 clearly states the tool verifies a spend/GMV artifact bundle and lists five specific verification checks. It distinguishes itself from sibling tools like verify-receipt and verify-reward-commitment by focusing on multi-artifact verification, and it explicitly defines its scope as portable artifact verification.

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?

The description explains that this tool performs portable artifact verification and does not assert payout, chain finality, or validator quorum unless specific artifacts are provided. This gives clear context for when to use it, though it does not explicitly name alternative tools for those other assertions.

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

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

No annotations provided, so the description carries full burden. It discloses that the email is discarded after verification, which is important behavioral info. Could mention error handling or side effects, but overall transparent.

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?

Three sentences, each adding unique value: purpose, return data, and disposal. Front-loaded with the key action and no wasted words.

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 2 required parameters and no output schema, the description adequately covers what the tool does, what it returns, and a key behavioral detail (email discarded). Could mention size limits or response format, but sufficient for the complexity.

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 100%, baseline 3. The description adds value by specifying that 'eml' is base64-encoded and explaining its necessity for DKIM verification. It also clarifies the format of 'apiKey' with 'crk_...' prefix.

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 clearly states the tool's purpose: preview DKIM verification of a billing email without creating a spend or earning sats. It distinguishes from siblings like submit-receipt by emphasizing the preview nature and safety.

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?

The description explains when to use the tool (preview before submission) and why the full email is required for DKIM verification. It implies not to use when intending to actually submit the receipt, but doesn't explicitly list alternatives beyond the context.

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

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

With no annotations provided, the description carries the full burden. It explains the cryptographic checks and the purpose of binding allocations to prevent manipulation. However, it does not disclose failure behaviors, side effects (though likely read-only), or return details.

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?

The description is concise with three sentences. It front-loads the main action, then details checks, then provides context. No unnecessary words.

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?

Given a simple one-parameter tool with no output schema, the description covers verification purpose and checks. However, it omits return value information and error handling. Sibling tools suggest a verification suite, but this tool's boundaries are not fully specified.

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 100% for the single 'token' parameter, and the description adds no additional semantics beyond the schema's type and description. The tool's main description provides context for the token's role, but no parameter-specific guidance.

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 clearly states the action ('Verify a reward commitment token's cryptographic integrity') and specifies the resource. It details what checks are performed (Merkle tree, signature, amounts) and distinguishes this from sibling verification tools like verify-issued-gmv and verify-receipt.

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?

The description does not provide explicit guidance on when to use this tool versus other verification tools, nor does it mention prerequisites or conditions. Usage context is only implied through the tool's function.

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