insumer

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

Annotations only declare safety hints; the description adds substantial behavior beyond them: ECDSA signing with a kid and post-quantum companion signature, per-result evaluatedCondition/conditionHash/anchoring block, 5-minute expiry for delegation conditions vs 30 otherwise, failReason on failure, and a credit cost (2 with merkle proof). It also clarifies that declaredLimits are reported, not simulated.

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?

It is long but densely packed, and the core purpose is front-loaded ahead of the condition inventory. It loses a point because the condition-type and chain enumerations duplicate the very thorough schema rather than deferring to it.

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 complex, 11-parameter tool with no output schema, the description covers condition semantics, chain coverage, signing/verification artifacts, expiry, cost, and failure reporting, so an agent has what it needs without the schema explaining return values.

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%, so the schema already documents all 11 parameters in depth, making 3 the baseline. The description restates condition types and chain support that the schema already carries, adding little parameter-level detail beyond what is structured.

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 first sentence states a specific verb and resource ('Verify 1-10 on-chain conditions for a wallet') plus the output shape ('signed yes or no for each, never the balance'), which differentiates it from sibling check tools. An agent immediately knows this is a multi-condition signed attestation service.

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 enumerates the condition types, supported chains, cost tiers, and when proof/format/declaredLimits apply, giving clear context for how to invoke it. However, it never names an alternative sibling (e.g. insumer_wallet_trust or insumer_batch_wallet_trust) or states when NOT to use this tool, so usage routing is left 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?

Goes well beyond the annotations by disclosing partial-success semantics (failed wallets get error entries, successful ones return full profiles), per-wallet independent signing with distinct TRST-XXXXX IDs, and an explicit credit model (3 per successful wallet, 6 with proof 'merkle', charged only on success). These are exactly the behavioral facts an agent needs before invoking a non-idempotent, credit-consuming batch call.

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?

Five tight sentences, each earning its place: purpose/scope, speed rationale, signing model, partial-success behavior, and cost. The core batch scope is front-loaded and 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 credit-metered, non-idempotent batch tool with no output schema, the description covers cost, batch size, per-wallet signing, and partial-failure behavior well. It does not describe what a 'trust fact profile' actually contains, a minor gap given there is 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 description coverage is 100%, so the schema already documents 'wallets' (1-10) and the 'proof' enum. The description restates the 'merkle' / 6-credit pairing already present in the schema, adding no real parameter meaning beyond it. 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?

States a specific verb (Generate) and resource (wallet trust fact profiles) with a clear scope constraint (up to 10 wallets in a single request). The batch semantics are unmistakable, but it never names the sibling insumer_wallet_trust, so differentiation from the single-wallet tool is only implied by 'batch' and 'faster than sequential calls'.

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?

'Shared block fetches make this faster than sequential calls' gives clear context for when this tool is the right choice (multiple wallets). There is no explicit when-not guidance or named alternative for the single-wallet case, but the usage context is understandable without inference.

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, idempotent, openWorld and non-destructive. The description adds real value on top: it discloses that it reads on-chain balances, that it returns tier and discount percentage per token, and notably that it never returns raw balance amounts (a privacy guarantee). That is meaningful behavior beyond the annotations.

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

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

Three short sentences, front-loaded with the core action, then the return shape, then the cost note. No filler 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?

With no output schema, the description does the right thing by summarizing the return value (tier and discount percentage per token). The free/no-credit note is useful. It is slightly incomplete on how the seven wallet parameters interact (which one to supply), but overall adequate 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 description coverage is 100%, so every parameter (merchant, and the per-chain wallet addresses) is already documented in the schema. The description adds no parameter-level syntax or selection guidance, so the 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?

States a specific verb (Calculate) and resource (discount) with clear scope ('for a wallet at a merchant'), so an agent immediately knows what it returns. It does not explicitly name a sibling to differentiate from (e.g. wallet_trust, validate_code), keeping it at a 4 rather than a 5.

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 or when-not-to-use guidance, and no reference to alternatives among the many sibling tools. The only usage-adjacent statement is 'Free: does not consume credits', which speaks to cost, not selection.

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 safety is covered. The description adds real context beyond them: it discloses that no authentication or credits are required and what each template object contains, which helps an agent decide to call it freely.

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 tight sentences with the purpose front-loaded and supporting detail (template contents, providers, auth cost) after. Every clause earns its place; 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?

With no output schema, the description must convey what comes back, and it does name the fields each template carries (schema IDs, attester addresses, decoder contracts) plus example providers. It stops short of indicating the shape/count of the list response, but it is adequate for a zero-parameter 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 ('List') and resource ('compliance templates available for EAS attestation conditions'), and even explains the domain role of the templates (pre-configured schema IDs, attester addresses, decoder contracts). An agent can distinguish this from siblings like insumer_attest or insumer_wallet_trust without opening a schema.

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 ('a condition can name the template instead of raw EAS parameters'), which tells the agent why templates matter, but it never says explicitly when to call this tool versus insumer_attest or how to feed results into a condition. Usage is inferable rather than 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds the useful scope note that only 'public' profile data is returned, but says nothing beyond that about behavior, limits, or error conditions.

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 sentence, front-loaded with the verb and resource, with the field inventory appended compactly. Nothing is wasted and nothing redundant is repeated from the schema.

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 output schema, the description helpfully enumerates the payload categories (token tiers, NFT collections, discount mode, verification status), which is exactly the kind of return-value context needed. An agent can call this correctly from the description plus annotations, though error or not-found behavior is unaddressed.

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 a single parameter and schema description coverage is 100%, so the schema already documents the required 'id' with its pattern and length constraints. The description adds nothing about the identifier semantics, 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?

States a specific verb ('Get') and resource ('merchant profile') and even enumerates the profile's contents (token tiers, NFT collections, discount mode, verification status). It does not, however, distinguish itself from the sibling insumer_list_merchants, so an agent must infer that this is the single-entity fetch vs. the collection listing.

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 gives no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as insumer_list_merchants or insumer_check_discount. The agent only sees a one-line purpose statement with no selection criteria.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description still adds real behavioral context: no authentication required, the key algorithms returned, and crucially the failure semantics ('an unknown kid is unverifiable, not refuted'). That last point is a genuine behavioral disclosure an agent cannot get from 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?

Three dense sentences, each earning its place: what is returned, what it is for, and how to consume it safely. The most important content (what the tool returns) is front-loaded, and nothing is padded.

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 full burden and does so: it describes the return structure (key types, kids, AKP entries), the verification use case, the matching rule, and the no-auth requirement. Nothing an agent needs to call or interpret this tool 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?

The tool takes zero parameters, so per the baseline this scores 4. The description adds nothing about parameters because there are none to describe, and it correctly directs the agent to match on the kid in the response rather than any input.

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 and resource ('Get InsumerAPI's public signing keys as a JWKS') and names the exact contents (ECDSA P-256 key, ML-DSA-65 post-quantum key as RFC 9964 AKP entries). An agent can immediately distinguish this from the attestation/trust siblings, which consume these keys rather than expose them.

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 context in which the keys matter ('signatures on attestation and trust responses verify against these keys') and gives a concrete consumption rule ('match an entry by the kid, never by position'). It does not name a sibling alternative or an explicit when-not condition, but the usage context is unambiguous.

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, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond them: it identifies the data source as the public directory and enumerates the returned fields (company name, website, tokens accepted, discount info), which matters because there is no 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?

Two short sentences, zero filler, with the core action (browse the public merchant directory) front-loaded ahead of the filter and return detail. Every clause 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?

For a read-only list tool with a fully documented schema, the description covers source, filters and return fields, which is enough given there is no output schema. It could mention pagination behavior or result ordering, but nothing essential to correct invocation 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 100%, so both filters and the pagination parameters are already documented with types, bounds and examples. The description echoes the token and verification filters but adds no format or syntax detail beyond the schema, so the 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?

Specific verb+resource: 'Browse merchants in the public directory', clearly a listing tool and distinguishable from the singular insumer_get_merchant sibling by the plural resource and browse framing. It stops short of explicitly naming the sibling, so it is not a full 5.

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 only implied — the description says what can be filtered but never states when to choose this list tool over insumer_get_merchant, nor any prerequisites or exclusions. Adequate but with a clear routing gap.

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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that it's a registry listing with filtering, which supplements the annotation's title but does not repeat safety traits. It does not, however, disclose pagination, sorting, or rate limits, which are relevant for a potentially large 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?

The description is a single, efficient sentence that front-loads the core action and lists the filter options. There is no waste or filler, though it could be slightly more specific about the registry scope.

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 is a read-only list with three optional parameters, full schema coverage, and rich annotations, the description is adequate but does not explain return behavior (e.g., format, pagination) despite no output schema being provided. For a registry listing, this is a notable gap because the agent cannot anticipate response structure.

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%, so the schema already documents all three parameters (type, chain, symbol) with descriptions and an enum for type. The description only repeats the filtering dimensions without adding syntax, format, or default behavior, so it does not add meaning beyond the schema. 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 a specific verb ('List') and resource ('registered tokens and NFT collections in the Insumer registry'), and the filtering capability is explicit. However, it does not differentiate itself from sibling tools like insumer_list_merchants; the registry concept is clear but sibling routing is absent.

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 explicit guidance on when to use this tool versus alternatives, no mention of prerequisites, and no indication of when filtering is necessary versus optional. The agent must infer usage from the name and description alone.

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?

Goes well beyond the annotations by disclosing that no authentication is required, no credits are consumed, no wallet or token data is exposed, and that the response carries valid/invalid status with a reason. Those are exactly the operational facts an agent needs and that readOnlyHint/idempotentHint cannot convey.

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?

Four short sentences, front-loaded with the action and resource, then use context, then return shape and cost/safety guarantees. Every sentence carries distinct information with no 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?

With one fully documented parameter and no output schema, the description supplies the missing pieces itself: it describes the return value (valid/invalid plus reason) and the auth/credit profile. Nothing needed to invoke or interpret the call is absent.

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 single parameter already documents the INSR-XXXXX format with a matching regex pattern. The description restates the format but adds no syntax, casing, or normalization detail beyond the schema, so the 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?

States a specific verb and resource ("Validate an INSR-XXXXX discount code") and scopes it to merchant backends during ACP/UCP checkout. It does not, however, distinguish itself from the sibling tool insumer_check_discount, which an agent could easily confuse it with.

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?

Gives a clear situational context: use it from merchant backends during ACP/UCP checkout to confirm validity, discount percent, and expiry. It stops short of naming alternatives or stating when not to use it (e.g. vs insumer_check_discount).

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 annotations covering readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, the description adds substantive context: the signed profile structure, behavior for missing chain wallets (rows kept with evaluated: false), semantics of checks (held/not held, never a balance), the conditionSetVersion logging instruction, cost (3 credits, 6 with proof), and return shape (per-dimension pass/fail counts and summary, no score). It doesn't detail failure modes beyond the proof enum's decline behavior in schema, but that's largely covered in the schema. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and then flows through optional chain behavior, signed profile semantics, cost, and a URL. Every sentence provides useful information. It's a bit dense (multiple clauses per sentence) but remains digestible and appropriately sized for the tool's complexity.

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 8 parameters (1 required), no output schema, and the complexity of multi-chain evaluation, the description is quite complete: it explains the signed profile structure, behavior for missing wallets, check semantics, return values (counts and summary), and cost. The only minor gap is that it doesn't explicitly state authentication requirements or rate limits, but annotations and the URL provide partial coverage.

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 schema descriptions for parameters like wallet, suiWallet, tronWallet, etc., are detailed and include patterns and effects (adds dimension, lets rows evaluate). The description adds high-level semantics about which chains add dimensions versus only enabling evaluation, but much of this is also present in the schema. With full schema coverage, 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 states a specific verb and resource (generate a signed wallet trust fact profile for an EVM wallet) and elaborates the content (presence checks organized into named dimensions) and the target consumer (AI agent-to-agent trust decisions). It clearly distinguishes itself from siblings like insumer_attest or insumer_batch_wallet_trust by specifying the signed profile artifact and optional multi-chain behavior.

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 conveys when to use it (agent-to-agent trust decisions) and includes operational guidance like logging conditionSetVersion and never rejecting on it, plus cost information. However, it does not explicitly say when not to use it or compare to siblings such as insumer_attest or batch variants.

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