Crinkl Commerce MCP

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

With no annotations, the description fully discloses behavior: it describes pending approval (202), success (200), and expiration (410) states, and recommends a polling interval. No side effects are mentioned, which is appropriate for a non-destructive poll.

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 concise sentences, each adding critical information: purpose, return behavior, polling advice, and authentication. 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?

For a simple polling tool without an output schema, the description covers all essential aspects: what it does, when to use, expected responses, polling interval, and authentication. It is complete for the tool's 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 detailed descriptions for both parameters. The description adds context for the workflow but does not enhance parameter semantics beyond the schema. Baseline 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 explicitly states the tool polls for an API key after human approval, distinguishing it from sibling tools like pair-agent. It mentions the specific workflow and return codes, making the purpose clear.

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 specifies when to use the tool (after pairing code approval) and provides a polling interval (every 5 seconds). It also notes no authentication required. It implicitly guides against overuse by mentioning expiration (410).

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 lists the return data but does not mention any side effects, access requirements, rate limits, or other behavioral traits. The description is transparent about output but not about 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?

The description is a single sentence that is front-loaded with the purpose. It is somewhat lengthy due to listing many return items, but each item adds value. No extraneous information is present.

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?

Despite having no output schema, the description provides a comprehensive list of what the tool returns, covering authority levels, capability sets, governance controls, and more. For a retrieval tool with zero parameters, this is complete and informative.

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 schema coverage is trivially 100%. Per guidelines, baseline for 0 parameters is 4. The description does not need to add parameter information.

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 a specific verb 'Get' and clearly identifies the resource as 'Crinkl's canonical external agent capability catalog'. It distinguishes from sibling tools by listing the detailed components returned. This provides exceptional clarity on what the tool does.

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 explicitly state when to use this tool versus alternatives, nor does it provide exclusions. However, the purpose is clear enough to infer usage for retrieving agent capabilities. No guidance on when not to use is given.

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 carries the burden of disclosing behavior. It clarifies the data scope and returned fields but does not state that the tool is read-only, nor does it mention auth requirements beyond the apiKey parameter or rate limits.

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 long, with the main action and results front-loaded. Every sentence provides essential information without unnecessary elaboration.

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 low complexity and no output schema, the description adequately covers the return values (submission count, earned sats, wallet-level stats, satsPerReceipt). It could be slightly more explicit about the exact fields, but it is sufficient.

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 100% description coverage for the single parameter (apiKey). The description adds context by referencing 'per-API-key numbers', but does not provide additional semantic value 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 uses a specific verb 'Get' and clearly identifies the resource as 'your agent's submission count, earned sats, and wallet-level stats.' It distinguishes itself from sibling tools by focusing on agent-specific metrics versus cumulative or protocol-level 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 explains what data is shown (per-API-key vs wallet-wide) and includes satsPerReceipt rate, but it does not provide explicit guidance on when to use this tool versus alternatives or any conditions for use.

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 carries the full burden and details the return value (signed token with USD cents, spend count, timestamp) and data source (public cumulative feed, beta over alpha). It lacks explicit idempotency or permission info, but is otherwise 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?

Two sentences that are clear and front-loaded with the tool's purpose. No extraneous words, though the second sentence is slightly dense. Still 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?

The description explains the return structure despite no output schema, covers the data context (beta on alpha), and provides usage hints. No major omissions for a read tool.

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

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

Input schema has 100% coverage (both parameters described well). The description adds value by explaining startDate bounds the window, but does not significantly enhance asOfDate beyond schema defaults. 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 cumulative GMV from a public cumulative feed. It distinguishes itself from sibling tools like get-daily-gmv and get-trailing-gmv by specifying 'cumulative' and referencing the public feed.

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 advises to provide startDate to bound the window, offering some usage guidance. However, it does not explicitly compare with sibling tools or state when not to use it, leaving room for ambiguity.

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 carries the full burden. It discloses that the tool returns a cryptographic signature and mentions verifiability, but does not state safety traits (e.g., read-only, non-mutating) or permission requirements.

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

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

The description is three sentences, front-loaded with purpose, and every sentence adds value. No 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 tool has one parameter and no output schema, the description adequately explains the return fields (spend count, total USD cents, signature) and verification property. Minor gap: lacks mention of error conditions or idempotency.

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%; the description adds no extra meaning beyond the schema's description of the 'date' parameter. 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?

Description starts with a specific verb 'Get' and resource 'signed GMV summary', clearly stating it returns data for a single calendar date. It distinguishes from sibling tools like 'get-cumulative-gmv' and 'get-trailing-gmv' by specifying the scope.

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 retrieving a single day's verified GMV but does not explicitly state when to use this tool over siblings or provide exclusions. It lacks direct guidance on 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?

With no annotations, the description must disclose all behavior. It explains the cryptographic output but omits details like error handling (e.g., invalid spendId), prerequisites, or side effects.

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 purpose, no filler. Each sentence adds value.

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 (1 param, no output schema), the description adequately covers purpose and return values. Missing error conditions but overall sufficient for a proof retrieval 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%, so baseline is 3. The description does not add meaning beyond the schema's spendId description; it only restates the tool's purpose.

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 spend, listing the specific components returned (spend leaf hash, sibling hashes, root hash). This distinguishes it from sibling tools like get-daily-gmv or verify-issued-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 verification use cases but does not explicitly state when to use this tool over alternatives like verify-issued-gmv 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 effectively discloses the tool's behavior: it returns a public key in base64 format. It does not mention side effects, but none are expected, and the description covers the essential return value and purpose.

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, consisting of two to three sentences that immediately state the purpose and provide necessary details without any extraneous 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?

Despite lacking an output schema, the description fully explains what is returned (public key, base64) and its purpose, making the tool's usage clear and self-contained.

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, and the schema coverage is 100%. The description does not add to parameter semantics because there are none, but baseline for 0 parameters is 4.

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 the Ed25519 public key used by the Crinkl authority for signing attestation tokens. It specifies the format (base64) and distinguishes it from sibling tools, none of which get issuer keys.

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 the key's use for verifying signatures on tokens, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, though none exist among siblings.

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. Identifies as read-only ('Get') and notes data source (verified receipt attestations), but fails to disclose potential issues like empty results, authentication requirements, or rate limits. Adequate but minimal.

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, front-loaded with main purpose, no redundancy. Each sentence adds value: first defines function, second adds detail and provenance. Perfectly concise.

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 parameterless read tool, description covers purpose, outputs, and data source. Lacks specification of exact metric names or categories, but sufficient for typical usage. Minor gap for completeness but 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?

No parameters exist, so description must explain output. It effectively describes aggregated metrics (top brands, categories, concentration) and data source, compensating for lack of output schema. Justification exceeds baseline 3 due to clear enumeration of output details.

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 aggregates merchant and category distribution across verified spends, listing specific outputs like top brands and category breakdown. Distinguishes from sibling tools by focusing on merchant/category aggregation rather than GMV or settlement summaries.

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 aggregated merchant/category data but provides no explicit guidance on when to use this tool versus siblings like get-spend-distribution or get-protocol-summary. No exclusion criteria or context 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?

With no annotations, the description carries full burden. It states 'Returns a plain-text overview', indicating read-only behavior. It lists specific content areas, providing clarity on what the output includes. It does not disclose any side effects or safety concerns, but as a simple info retrieval tool, this is adequate.

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, each essential. The first defines the action and resource, the second provides usage guidance and output details. It is front-loaded and contains 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?

Given no parameters and no output schema, the description fully covers purpose, usage guidance, and output format. It specifies the content areas (pipeline, tokens, settlement). The tool is simple, and the description is 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?

The tool has zero parameters with 100% schema description coverage. The description adds value by explaining the purpose and output, making it clear that no input is needed. Baseline for 0 params is 4, and the description meets that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a concise explanation of what Crinkl is and how the protocol works.' It specifies the verb 'Get', the resource 'concise explanation', and lists covered topics (verification pipeline, token types, settlement model). This distinguishes it from sibling tools which focus on specific data like GMV or merchants.

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 advises: 'Use this first if you have no prior context about Crinkl.' This provides clear when-to-use guidance. It does not explicitly mention when not to use it or alternatives, but given sibling tools, it's implied that other tools are for specific queries after initial 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, the description fully discloses key behaviors: reward fields may be null due to async batching, spend token and GMV proof are always present, and suggests checking 'steps' and 'ok' for verification results. This provides rich behavioral context beyond basic read operation.

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?

Description is concise at five sentences, front-loading the purpose and adding critical behavioral notes without redundancy. Every sentence earns its place, making it easy for an agent to parse quickly.

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 complexity of proof bundles and no output schema, the description explains bundle contents, null field behavior, and verification steps. It could be enhanced by mentioning pagination or ordering (e.g., newest first), but overall provides sufficient context for an agent to understand the output.

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% (one parameter 'limit' with clear description). The tool description does not add any new information about the parameter beyond what the schema already provides, meeting the baseline but not exceeding it.

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 recently issued proof bundles for end-to-end verifiability, specifying contents (spend attestation token, GMV inclusion proof, reward commitment). It distinguishes from siblings by focusing on 'recently issued' and 'bundles', unlike narrower tools like 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?

Usage is implied: use when you need recent proof bundles for verification. However, no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives named despite sibling tools like get-gmv-inclusion-proof and verify-issued-gmv existing.

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 carries full burden for behavioral disclosure. It notes that values are deterministic, the policy hash covers the full parameter set, and updates occur daily. This provides useful context about data freshness and consistency. However, it does not mention permissions, rate limits, or potential side effects (though none are expected for a read).

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, each serving a clear purpose: stating the action, listing contents, and adding behavioral context. There is no redundant information. It is highly concise and well-structured, front-loading the verb and resource.

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 absence of an output schema and annotations, the description comprehensively explains what the tool returns (specific fields like policy version, hash, parameters, multipliers, reserve checkpoint) and its update cadence. This is sufficient for an agent to understand the tool's utility and output 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?

The input schema has zero parameters, so the description needs to add no parameter-level information. The baseline score for 0 parameters is 4, and the description meets this by providing context about what the tool returns without needing to elaborate on parameters.

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: retrieving the current Crinkl reward policy. It enumerates the returned fields, making the purpose specific. However, it does not explicitly differentiate from sibling tools like 'verify-reward-commitment' or other 'get-' functions, though the specificity of the resource and parameters (none) inherently distinguishes it.

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 by stating what is returned, but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'verify-reward-commitment'). There is no mention of prerequisites or when not to use it. The straightforward nature of a parameterless read tool reduces the need, but guidelines would still enhance agent decision-making.

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 bears the burden of disclosure. It specifies the tool is read-only and lists returned data fields. However, it omits potential authentication requirements or whether data is real-time/cached, but for a simple getter, 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, front-loading the purpose and return details, then adding context. Every sentence is essential with 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?

Given no output schema and zero parameters, the description adequately covers what the tool does and returns. It could mention update frequency or caching, but the core completeness for agent usage is high.

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 (100% coverage, empty), so baseline is 4. The description adds value by explaining the output fields and context beyond the schema, though not needed for parameters.

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 Bitcoin settlement statistics for the Crinkl network, listing specific returned metrics (BTC price, sats-per-receipt, Lightning payouts, claimed sats, wallet balances). This distinguishes it from sibling GMV-focused 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 implies usage for settlement layer metrics but provides no explicit guidance on when to use this tool versus alternatives (e.g., get-protocol-summary or get-reward-policy). No 'when not to use' or comparison with siblings.

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 carries full burden. It explains it returns a breakdown but omits details like output format, pagination, or authentication requirements. The transparency is adequate but incomplete.

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, front-loading the main purpose and adding specific output details without extraneous text.

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 and no output schema, the description covers the return content (breakdown by store category and CBSA) adequately. Minor missing detail on output structure, but overall sufficient.

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% and the only parameter 'days' is described in the schema. The description adds no extra meaning beyond 'trailing window', so 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 specifies that it retrieves geographic and category distribution of verified spends, listing the output dimensions (store category and CBSA metro code) and the analytical purpose. It clearly distinguishes from sibling tools like get-daily-gmv or 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 states the tool is used for analyzing distribution across geography and category, providing clear context. However, it does not explicitly mention when not to use it or list alternative tools for different needs.

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 explains that signals are cryptographically attested, go through OCR and verification, and contain no PII. This adds behavioral context beyond the basic 'get' operation. However, since no annotations are provided, more details on rate limits or pagination would enhance transparency.

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, front-loading the purpose and then providing informative details about signal content and a related tool. No extraneous information; every sentence adds value.

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 and no output schema or annotations, the description covers the main aspects: what the tool returns, the data provenance, and a related tool. It lacks explanation of what 'recent' means (e.g., time window) but is otherwise complete for a simple data retrieval 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?

The input schema already fully describes the single parameter (limit, default 20, max 50). The description does not add any additional semantic meaning beyond what the schema provides, so baseline score 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 action ('Get') and the resource ('recent verified spend activity signals'), with specific details about what the signals contain and exclude. It distinguishes from sibling tools by focusing on spend signals and referencing resolve-cbsa for metro area conversion.

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 a cross-reference to resolve-cbsa for converting CBSA codes, implying a usage companion. However, it does not explicitly state when to use this tool versus other sibling tools like get-cumulative-gmv or get-protocol-summary, nor does it mention any limitations or prerequisites.

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?

Despite no annotations, the description adds behavioral context by noting each day's figure is backed by individually signed spend attestation tokens, indicating data provenance and verifiability beyond what the schema offers.

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: purpose, content, and behavioral detail. No redundant or unnecessary text.

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?

The description explains what is returned (daily verified GMV figures) but does not specify the structure (e.g., list of objects with date and amount) or ordering. Adequate but could be more complete for a tool without an 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 coverage is 100%, so baseline is 3. The description mentions 'rolling N-day' which reinforces the 'days' parameter but adds no new semantic detail beyond what the schema's description already provides.

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 rolling N-day GMV trend summary with daily verified figures, distinguishing it from siblings like get-daily-gmv (single day) and get-cumulative-gmv (aggregate over all time).

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 trend analysis but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusion or alternative names 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?

Discloses no authentication required (key safety info) and that it's a read-only operation via 'get'. No contradictions with annotations (none provided). Could add data freshness or error info, but adequate for 0-param 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?

Two sentences, front-loaded with purpose, no waste. Every sentence adds meaningful context.

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 0 params, no output schema, and no annotations, the description covers purpose, usage, and safety. Could mention if list is static/dynamic, but complete enough for agent selection.

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; baseline is 4. Description adds value by explaining what the tool returns (approved DKIM vendor domains) and its purpose, exceeding baseline.

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 specific verb 'get' and resource 'vendors' (DKIM vendor domains) from a public endpoint. Distinguishes from siblings by focusing on approved DKIM vendors for search seeding.

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 seeding Gmail searches and mentions unknown vendors are queued for review. No explicit when-not-to-use or alternatives, but context is clear for this simple read 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 full burden. It discloses the generation of a 4-character code, the need for human approval in the Crinkl PWA, the return of the code and expiration time (10 minutes), and the lack of authentication. Could be improved by mentioning any side effects or state changes, but no contradictions.

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 consists of two sentences, both front-loaded with the key action and then details. Every sentence adds value, with no wasted words. It is concise and well-structured.

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 the flow, return values (code and expiration), and prerequisites ('No authentication required'). It sufficiently informs an agent about what to expect, making it contextually 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?

The schema description coverage is 100% for the single parameter 'deviceToken', and the schema already explains it as a 64-character hex string to store for later use. The tool description adds no additional meaning beyond the schema, so a baseline 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 specifies the action ('Start the human-authorized agent pairing flow') and the resource ('agent pairing'). It distinguishes itself from siblings like 'claim-api-key' by being the initiation step. The verb 'start' and the noun 'pairing flow' are specific and unambiguous.

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

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

The description provides context by stating 'No authentication required' and implies this is the first step in the pairing process. However, it does not explicitly mention when not to use this tool or list alternatives, though the sibling list makes it 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It mentions handling both metro and non-metro codes, but does not discuss side effects, data sources, caching, or error handling. The description is adequate but could be more transparent about how the resolution works.

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, containing three focused sentences that each add essential information: the core function, an example, and handling of edge cases (non-metro codes). No unnecessary words or 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?

For a simple lookup tool with one parameter and no output schema, the description sufficiently explains input, output, and edge cases. It could explicitly state the return value format, but the examples imply a human-readable string. Overall, it is complete for the tool's 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?

The input schema covers the single parameter 'code' with 100% description coverage. The tool description adds value by providing specific examples of valid codes (e.g., '35620', 'non-metro:US-TX') and explaining the output format, which goes 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 defines the tool's purpose: resolving CBSA codes to metro area names. It includes concrete examples ('35620' → 'New York-Newark-Jersey City, NY-NJ') and covers non-metro codes, distinguishing it from sibling tools which serve unrelated functions.

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 about when CBSA codes appear (spend signals, distribution data) and gives the expected input format. However, it does not explicitly state when not to use this tool or compare with alternative tools, though the sibling list shows no directly related 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?

Discloses that the email is discarded, only four fields retained, and enumerates possible HTTP status codes. Without annotations, it carries the full burden. Could mention idempotency or rate limit specifics, but status codes provide partial transparency.

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 essential: purpose, reason for full email, and outcome/status codes. No fluff, front-loaded with main action.

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 and two well-documented parameters, the description covers input requirements, behavioral details, and possible responses. It is complete for a tool of this 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 descriptions already present. The description adds slight value for 'eml' by mentioning DKIM verification necessity, but 'apiKey' is not enhanced. 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 submits a DKIM-verified billing email to mint a spend token and earn sats, with specific verb+resource. It distinguishes from siblings like verify-receipt by including the minting step.

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?

Explains the requirement for the full email due to DKIM and describes post-verification processing. Lists return codes (201, 202, 409, 422, 429) that guide usage. Lacks explicit when-not-to-use or alternatives, but context 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?

With no annotations, the description carries the full burden. It enumerates all five verification steps (signature checks, Merkle inclusion, ID matching), providing clear behavioral insight. It does not disclose error conditions, performance characteristics, or whether the verification is on-chain vs off-chain, but overall it is quite transparent for a verification 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?

Two concise sentences: the first states purpose and inputs, the second details verification steps and highlights value. Every sentence is informative with no 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 tool's complexity (5 params, 4 required, nested objects, no output schema), the description adequately explains what it does but misses output format (e.g., success/failure indicators, error types) and prerequisites (e.g., required tokens must be previously obtained). This gap reduces 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?

Schema coverage is 100%, so baseline is 3. The description adds context by explaining how each parameter participates in the verification steps (e.g., spend token signature check, GMV token signature, Merkle proof), elevating the semantic understanding beyond the schema's brief labels.

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 'Perform full end-to-end verification of a spend's inclusion in verified GMV' with a specific verb and resource. It lists five distinct verification steps, distinguishing it from sibling tools like 'verify-receipt' and 'verify-reward-commitment' by asserting it as the 'strongest possible verification' and covering the entire journey from scan to settlement.

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 the most thorough verification ('strongest possible verification', 'single call that proves a receipt's entire journey'). However, it does not explicitly state when not to use it or suggest alternatives for lighter checks, leaving the selection partially implicit.

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 carries full transparency burden. It discloses that the email is discarded after verification and explains why the full email is required (DKIM signature verification over original bytes). This adds useful behavioral context 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 concise: three sentences, front-loaded with purpose, followed by return data and a rationale. Every sentence adds value with 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?

Given no output schema, the description adequately explains the return value (vendor, amount, date, DKIM status). It also covers the disposal behavior and rationale, making it complete for a preview 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%, so baseline is 3. The description adds some rationale for the 'eml' parameter but does not introduce new meaning beyond what the schema already provides.

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 uses a specific verb (preview) and resource (DKIM verification), and distinguishes itself from sibling tools like 'submit-receipt' which actually creates a spend.

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 when to use this tool: for previewing without committing to a spend. However, it does not explicitly name alternatives or state conditions when not to use it, leaving some ambiguity.

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 carries full burden. It discloses that the tool performs cryptographic checks (read-only), explains what reward commitments are, and why verification is important. It does not cover failure modes or output format, but the behavioral intent is clear.

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 every sentence adds value. No redundant 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 no output schema, the description does not mention return values. It explains the purpose and when to use, but misses prerequisites like how to obtain the token. Still adequate for a verification 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%, and the description adds context by explaining that the token is a full reward commitment JSON object used for verification and that it prevents retroactive manipulation. This goes beyond the schema's basic 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's purpose: verifying the cryptographic integrity of a reward commitment token. It specifies three concrete checks (Merkle tree, batch signature, reward amounts) and distinguishes it from siblings like verify-issued-gmv and verify-receipt by focusing on reward commitment tokens.

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 the tool should be used before payout to prevent manipulation, providing a clear usage context. However, it does not explicitly state when not to use it or provide alternatives among siblings.

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