CriptoNous

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context by naming the fields the tab exposes, which matters since there is no output schema. It still omits units, freshness, and the meaning of "remaining".

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 short sentences, front-loaded with the core action and the field list. It is appropriately sized for a no-argument read tool. The unexplained "NFA" abbreviation is the one non-earning fragment.

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 no input parameters and no output schema, the description carries the burden of describing the return value, and it does so by listing the four exposed fields. An agent can act correctly on this. Remaining gaps are formatting/units and the ambiguous "NFA".

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline is 4. No parameter-level confusion is possible here.

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

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

States a specific verb+resource ("Consulta el tab de gasto del agent") and even enumerates the contents of that tab (daily cap, per-tx cap, remaining, allowlist). It is clear what the tool does, though it does nothing to distinguish itself from siblings like temple_get_receipt or temple_verify. The unexplained "NFA" token and the language switch to Spanish slightly dilute clarity.

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?

There is no statement of when to call this versus alternatives, nor any prerequisite or exclusion. An agent must infer that this is a pre-spend budget check rather than, say, a receipt lookup. The trailing "NFA" is opaque and provides no usable 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description's 'Público' does add useful context that no auth/credentials are needed, but it says nothing about rate limits, freshness, or catalog shape beyond the field list.

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

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

A single front-loaded sentence naming the resource first, then the returned fields, then the access note. 'Público' is a fragment but carries real information, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-argument, read-only catalog tool with no output schema, the description covers what it returns (SKUs, USDC prices, NFA) and that it is public. It is complete enough to invoke, with only minor gaps about catalog size or freshness.

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 takes zero parameters and the schema is empty, so there is nothing for the description to document – baseline 4 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?

States a specific verb (Devuelve) and resource (catálogo canónico del Templo Cripto Nous) and lists returned content (SKUs, precios USDC, NFA). It does not explicitly distinguish itself from the sibling tools, though the subject matter is clearly distinct from budget/pass/receipt operations.

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 only usage signal is 'Público', which implies no authentication is required. There is no statement of when to call this versus the other temple_* tools, and no prerequisites or exclusions are 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?

Adds real behavioral context beyond the annotations: it consumes a pass use (consistent with readOnlyHint=false and idempotentHint=false), emits a Receipt, and specifies the failure contract (fulfillment_failed on source failure with no use consumed). That failure/refund semantics is valuable and not derivable from structured fields.

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 compact sentences with no filler, front-loading the core action (consume a use, return reading) before the Receipt and failure notes. Appropriate length for the tool.

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 non-idempotent, mutating tool with 33% schema coverage and no output schema, the description covers behavior and failure mode well but leaves parameters and the returned reading structure unexplained. Adequate but with clear gaps.

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 only 33% (only 'symbol' is documented). The description never explains passId or sku, so it fails to compensate for the two undocumented required parameters beyond a vague allusion to the AccessPass.

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

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

The description names a specific verb+resource: it consumes one AccessPass use and returns a market reading ('lectura de los dioses'). It clearly differs from pure validation or tribute tools, though it does not explicitly name a sibling alternative.

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

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

Usage is implied rather than stated: it signals this is the paid-with-pass path ('sin nuevo pago'), hinting at a contrast with payment tools, but it names no alternatives and gives no explicit when-to-use or when-not-to-use conditions.

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?

Annotations already declare readOnly=true, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds that the payload is JSON and carries an 'HMAC v2' signature, which hints at verification/signing behavior, but it never says what happens on a missing or unverifiable receipt.

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

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

One short, front-loaded sentence with the identifier requirement stated up front; nothing is padded or redundant. The only drag is that several tokens are spent on unexplained abbreviations rather than useful 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?

For a simple one-parameter getter this is thin: no output schema exists, and the description does not describe the receipt structure, the meaning of the language/HMAC notes for the caller, or error behavior. An agent knows it fetches something, but not enough to use the result confidently.

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

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

Schema description coverage is 0% for the single required parameter, so the description carries the full burden — and it only echoes the parameter name ('por receiptId') without giving format, expected ID shape, or example. No compensating detail is provided.

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 verb/resource pair ('Obtiene un Receipt ... por receiptId') is identifiable, and the closing 'No es DTE/SII' differentiates it from tax-document tools. But qualities like 'élite', 'NFA 6 idiomas' and 'HMAC v2' are unexplained domain jargon that add no clarifying power, and the description never contrasts itself with the nearby temple_list_receipts sibling.

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 only usage signal is a negative one: 'No es DTE/SII', which tells the agent this is not a Chilean tax document. There is no guidance on when to call this single-receipt fetch versus temple_list_receipts, temple_verify, or temple_validate_pass.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two useful traits beyond them: results are scoped to the authenticated agent and returned most-recent-first. It says nothing about pagination, default limits, or result size.

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

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

A single front-loaded sentence that carries scope and ordering with no filler. Nothing is redundant or padding.

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 one-parameter list tool with no output schema, the description conveys what is returned (the caller's own receipts, newest first) and the annotations carry safety. However, the undocumented 'limit' parameter and the absence of any pagination or default-count guidance leave a real gap.

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

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

There is one parameter ('limit') with 0% schema description coverage, and the description never mentions it, so it does not compensate for the gap. An agent cannot learn from the definition whether 'limit' caps the result count or what the default is.

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

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

States a specific verb ('Lista') and resource ('receipts') plus a scope ('del agent autenticado') and ordering ('más recientes primero'). The plural/list framing naturally separates it from the singular sibling temple_get_receipt, but the description never explicitly names or contrasts that sibling.

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?

There is no when-to-use guidance, no statement of when to prefer this over temple_get_receipt, and no prerequisites or exclusions. Usage is only implied by the word 'Lista'.

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?

Annotations already declare the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=true). The description adds two useful facts beyond them: an API key is required, and a reusable AccessPass is issued after verify. It does not disclose cost/amounts, what the TributeRequest payload contains, or failure behavior, so it earns credit but not full marks.

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 short sentences, no filler, with the action statement front-loaded followed by the auth requirement and the downstream effect. Terse to the point of under-explanation, but nothing is redundant.

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 no-output-schema mutation tool this covers the auth requirement, payment asset and downstream artifact, which is more than many peers. It still omits what gets created server-side, any monetary amount or expiry for the TributeRequest, and error/retry semantics, leaving meaningful gaps for a payment-initiating call.

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% and the sole 'sku' parameter already carries a format hint with examples (hermes.pulse, session.24h). The description adds no meaning about sku selection or encoding beyond the schema, so baseline 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?

Names a specific resource (TributeRequest) and rail (SPL USDC Solana), and the title anchors it as the x402 payment-request step, so it is distinguishable from verify/consume siblings. However, 'Prepara TributeRequest' is bespoke jargon and the description never states in plain terms what preparing a tribute request accomplishes for the agent, leaving the core purpose only half 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 clause 'Tras verify se emite AccessPass reutilizable' implies a workflow: this tool precedes verify, which yields a reusable AccessPass. That gives implied ordering, but there is no explicit when-to-use vs alternatives guidance against siblings like temple_verify or temple_budget, and no stated preconditions beyond the API key.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the domain-specific guarantee that the pass is not consumed, which is meaningful beyond the generic annotations, but it says nothing about auth, error behavior, or what a failed validation looks like.

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 short clauses, front-loaded with the action and the key non-consuming constraint; nothing is padded. It is arguably over-terse rather than verbose, but every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and the description never indicates what validation returns (a boolean, a reason, the matched SKU set), nor does it cover the required passId. For a tool whose whole value is its verdict, the result contract is missing.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains 'sku' as an optional value checked against allowedSkus, which is real added meaning, but the required 'passId' is left entirely undefined and no format or lookup semantics are given for either parameter.

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

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

States a specific verb+resource ('Valida AccessPass') and adds the scoping qualifier 'vigente (sin consumir)', which implicitly separates it from the sibling temple_consume_pass. It does not name that sibling explicitly, so the differentiation is only partial.

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 parenthetical 'sin consumir' implies this is the non-consuming check variant, giving an implied when-to-use against temple_consume_pass, but no alternative is named and no preconditions or exclusions are stated.

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?

Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false and openWorldHint=true, so the safety profile is largely covered. The retry note mostly restates idempotentHint, but it does usefully frame the write effect (grants/passes are minted) in payment terms. Nothing is said about failure modes, what happens if the txSignature is invalid, or whether a prior grant blocks re-verification.

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 short sentences, front-loaded with the action and effect, with the retry caveat second. No filler; every clause carries 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?

Annotations carry the safety/idempotency profile and there is no output schema to explain, so the description need not cover return values. However, with three required, fully undocumented parameters and no mention of how to obtain a txSignature or what a successful verification yields, an agent is left guessing about inputs.

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

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

Schema description coverage is 0% and all three parameters (requestId, txSignature, payerWallet) are undocumented in both schema and description. The description implies a Solana USDC payment signature exists but never maps it to txSignature or explains the role of requestId (likely the idempotency key) or payerWallet, so the description fails to compensate for the coverage gap.

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

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

States a specific verb pair (verify SPL USDC payment) and the concrete effects (issue AccessGrant + AccessPass), so the agent knows exactly what happens. It does not, however, differentiate itself from close siblings like temple_validate_pass or temple_consume_pass, which an agent could easily confuse with 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?

"Idempotente: reintenta verify, no pagues dos veces" gives one operational guideline (safe to retry), which is implied usage rather than a when-to-use rule. There is no statement of prerequisites, no condition distinguishing it from temple_validate_pass/temple_consume_pass, and no 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.