Tenzro Ledger MCP

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

No annotations, so description carries full burden. It correctly implies read-only behavior ('Show') and reveals that config changes are on-chain governance-driven. Doesn't mention authentication or rate limits, but for a parameterless 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?

Two sentences, front-loaded with core purpose. Second adds important constraint and cross-reference. Minimal waste.

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 simplicity (0 params, output schema present), description covers key aspects. Could mention more about related siblings or data interpretation, but overall adequate.

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, so baseline is 4. Description adds value by listing what config components are returned, but not necessary due to zero 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?

Description clearly states verb 'Show' and resource 'current adaptive burn-rate config' with specific components (base/local/paymaster burn bps, treasury complements). It distinguishes from sibling adaptive_burn_get_recommendation by noting the config changes only via governance proposals.

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?

Provides context on when to use (to see current config) and implicitly when not (since changes come from proposals, use adaptive_burn_get_recommendation for recommendations). Points to a specific sibling for further 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?

No annotations are provided, so the description must carry the behavioral burden. It describes what metrics are shown but does not declare read-only nature, authentication needs, or refresh behavior.

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

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

Two sentences, no wasted words, front-loaded with the action 'Show...'.

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-parameter tool with an output schema, the description adequately lists return items and purpose. Minor gap: no mention of time bounds or caching.

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 0 parameters with 100% coverage, so the baseline is 4. The description does not need to add parameter 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?

The description clearly states the tool shows supply-side metrics snapshot and lists specific items (block height, circulating supply, etc.), distinguishing it from adaptive_burn siblings like get_config or get_recommendation.

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 context by stating it drives the recommendation engine, but does not explicitly compare to alternatives or state when not to 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?

Explicitly declares 'no side effects' and describes the return fields (action, magnitude, floor flag). Without annotations, this provides sufficient behavioral context for a read-only recommendation 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, no wasted words. First sentence lists output details, second states behavioral safety. 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?

For a 0-parameter tool with an output schema, the description is complete: it lists key return fields and states the pure, side-effect-free nature. No 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?

Input schema has 0 parameters; schema coverage is 100%. According to guidelines, baseline is 4. Description adds no parameter info as none are needed.

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

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

Description uses specific verb 'Show' and resource 'current adaptive-burn recommendation', lists possible action values (NoChange, IncreaseBurnPct, etc.), magnitude bps, and the auto-proposal floor flag. It clearly distinguishes from sibling tools like adaptive_burn_get_config and adaptive_burn_get_metrics by focusing on the recommendation output.

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

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

States 'Pure function of metrics + targets, no side effects' which informs the agent it's safe to call. However, it does not explicitly compare to alternatives or state when not to use it, though the context implies usage for obtaining the current recommendation.

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 carry behavioral disclosure. It reveals that Wave 1 returns empty results and why, which is valuable. However, it omits details like pagination, response format, or access restrictions, leaving gaps.

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 with no filler. The first sentence states the action and scope; the second adds critical context about the empty list. Every word 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?

Given the tool's simplicity (no parameters) and presence of an output schema, the description adequately covers the essential context: what the tool returns and an important temporary limitation. Slightly more detail on the output could push it to 5, but it's 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 tool has zero parameters with 100% schema coverage, so the description need not add parameter details. The description effectively covers the absence of inputs.

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 lists pending and historical adaptive-burn governance proposals, with a specific verb ('list') and resource. It also includes a notable caveat that Wave 1 returns an empty list due to pending infrastructure, setting expectations precisely.

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

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

While the purpose is clear, the description lacks guidance on when to use this tool versus siblings like 'list_proposals' or other adaptive_burn tools. No explicit context for choosing this over alternatives is provided.

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

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

No annotations are provided, so the description carries the full burden. It describes the return type (metadata with specific fields) but does not detail behaviors like required permissions or error conditions. However, for a simple read-only info tool, this is sufficient and does not contradict any annotations (none present).

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 conveys all necessary information without any wasted words. It is front-loaded with the action and resource, making it highly efficient.

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

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

Given the tool has no parameters, no annotations, but an output schema, the description explicitly lists the key fields in the output (version, mandate types, VC formats, issuer DID methods), providing enough context for an agent to understand what to expect. It is complete for its simplicity.

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, and the schema coverage is 100% trivially. With no parameters, the description does not need to add parameter info, so the baseline score of 4 is appropriate.

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

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

The description clearly states the tool returns AP2 protocol metadata, enumerating specific items: version, supported mandate types, supported VC formats, and issuer DID methods. The verb 'Return' indicates a read operation, and the resource is well-defined among siblings like ap2_sign_mandate, ap2_validate_mandate_pair, and ap2_verify_mandate, all of which have distinct purposes.

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 usage context is implied: this tool provides metadata about the AP2 protocol capabilities before engaging in mandate-related operations. It does not explicitly state when not to use it or mention alternatives, but the purpose is straightforward enough that an agent can infer its appropriate use case.

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 key behaviors: signing with Ed25519, auth requirements, return of a VDC, and constraint that signer_did must match the wallet's controller DID. It does not describe side effects or error conditions, but the core signing behavior is well covered.

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 long, front-loaded with the core action and output, and includes essential constraints. Every sentence adds value without redundancy or filler.

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

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

Given the tool has an output schema (not shown), the description appropriately focuses on inputs and behavior. It could be more complete by mentioning whether the signed mandate is stored or returned only, but the return of a VDC is clearly stated. Overall, it provides sufficient context for an agent to decide when and how to use the 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 has 100% coverage, but the description adds substantial meaning beyond the schema descriptions. It explains that mandate must match mandate_kind, that the wallet's Ed25519 key signs the canonical preimage, and that signer_did must match the controller (principal for checkout, agent for payment). This provides critical context for agent interpretation.

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 'Sign an AP2 mandate... returning a verified Verifiable Digital Credential (VDC)', providing a specific verb and resource. It clearly distinguishes from sibling tools like ap2_validate_mandate_pair and ap2_verify_mandate, which handle validation/verification rather than signing.

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 clear prerequisites (DPoP+JWT auth, Ed25519 wallet, matching signer_did) and context for when to use the tool. However, it does not explicitly state when not to use it or point to alternatives like ap2_validate_mandate_pair for verification.

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 full burden. It discloses the validation behavior and optional delegation enforcement, but does not state whether the operation is read-only, what permissions are required, or any side effects. The tagline 'TDIP identifies. AP2 authorizes. Tenzro settles' adds high-level context but doesn't fully compensate for missing behavioral details.

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

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

The description is highly concise: two sentences front-load the core purpose and checks, with the second sentence adding context for the optional parameter and a memorable tagline. Every sentence adds value without redundancy.

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

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

Given the existence of an output schema (not shown), the description covers the essential aspects: purpose, key checks, optional parameter behavior. It does not detail error cases or integrate sibling comparisons, but for a 3-parameter tool with no nested objects, it is largely 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?

Schema coverage is 100%, but the description adds meaning beyond the schema by explaining the relationship between checkout_vdc and payment_vdc and the purpose of enforce_delegation. It clarifies that the validation ensures PaymentMandate references CheckoutMandate and that optional delegation cross-checking occurs.

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 validates an AP2 v0.2 Checkout+Payment mandate pair for consistency, specifying the checks performed (reference matching, amount/item constraints, VDC verification). The verb 'Validate' and the resource 'mandate pair' are specific, and the description distinguishes this from siblings like ap2_verify_mandate (singular) or ap2_sign_mandate.

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 is for validating a pair of mandates before settlement, but it does not explicitly contrast with sibling tools or state when to use this version of the pair in the workflow. It provides context for the optional enforce_delegation parameter but lacks explicit when-to-use or when-not-to-use guidance compared to 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 fill the gap. It discloses that the tool checks 'VDC proof, issuer, and schema', but does not mention side effects (likely none), authentication requirements, or behavior on failure. 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?

The description is a single, well-structured sentence that front-loads the verb and resource. No redundant words; every phrase conveys necessary information.

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

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

Given the tool's simplicity (one parameter, output schema present), the description covers the key aspects: what verification does, what it checks, and applicable mandate types. No major 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?

The only parameter 'vdc' is well-described in the schema, and the tool description adds context by noting the components verified (proof, issuer, schema) and mandate types (Intent, Cart, Payment). This adds value beyond the schema alone.

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

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

The description clearly states the action ('verify'), resource ('AP2 mandate / Verifiable Digital Credential'), and specific checks ('VDC proof, issuer, and schema'). It distinguishes from sibling tools like ap2_sign_mandate and ap2_validate_mandate_pair by focusing on single mandate verification.

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

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

The description implies usage for verifying a single AP2 mandate but does not explicitly state when to use this tool versus alternatives like ap2_validate_mandate_pair. No when-to-use or when-not-to-use guidance is 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?

Despite no annotations, description details SHA-256 verification, atomic commit on final chunk, and return values. Covers behavioral traits well.

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

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

Two sentences, no wasted words. Front-loaded verb and structured flow.

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?

Output schema exists; description covers complete lifecycle from verification to return. No gaps for a chunk write.

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 has 100% description coverage. Description adds context about chunk_index's role in manifest but does not significantly extend beyond schema.

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

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

Description clearly states the tool writes one inbound snapshot chunk, distinguishing it from siblings like get_snapshot_chunk and offer_snapshot. Verb and resource are specific.

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

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

No explicit guidance on when to use or not use this tool. Missing prerequisites like needing a snapshot manifest and not mentioning 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 provided, the description carries the transparency burden. It discloses state change and notification, which is good, but lacks details on authorization requirements, error conditions, or idempotency. Adequate but not comprehensive.

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 the main action, then details state change, side effect, and return value. No unnecessary words, 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's simplicity (two parameters, clear action), the description covers the core behavior well. The existence of an output schema reduces the need to detail return values. Minor gaps in failure handling and prerequisites prevent a perfect score.

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 both parameters described. The description does not add extra meaning beyond the schema; it only reiterates the parameters implicitly. Baseline score is appropriate.

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

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

The description clearly states the tool's purpose: assigning a task to a specific agent on the Tenzro Task Marketplace. It specifies the state change ('Moves task from open to assigned state') and side effects (notifies agent, returns updated task record), effectively distinguishing it from sibling tools like cancel_task or complete_task.

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 it (for assigning tasks) but does not explicitly state alternatives or when not to use it. No mention of preconditions like task being in open state or agent readiness, which would help guide appropriate usage.

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

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

The description discloses the core behavioral invariant (post-mint supply <= attested reserves) and the rejection condition for no/insufficient reserves. With no annotations, it carries the full burden and does so effectively, though it omits details like permissions or reversibility.

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 entirely non-redundant. Every word adds value: condition, rejection, and reference to a mirrored tool. No fluff.

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 output schema exists, the description covers the core feature and failure mode well. However, it lacks context about what 'attested reserves' means or how they are set, which is critical for correct use. Slightly incomplete but still 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?

Schema coverage is 50% (amount and token_id have descriptions). The description does not elaborate on parameters beyond the schema, providing no additional meaning for 'to', 'caller', or the existing ones. It adds no parameter-level value.

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 mints a tokenized asset under a specific condition (post-mint supply <= attested reserves) and rejects if reserves are insufficient. The verb 'mint', the resource 'tokenized asset', and the conditional constraint are all explicit, distinguishing it from generic mint 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 minting with 1:1 backing but does not explicitly compare with sibling mint tools like 'crosschain_mint' or 'mint_nft'. There is no guidance on when to use or not use this tool, nor any mention of 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?

No annotations, so description carries full burden. It discloses rate limiting via daily mint/burn limits. Missing details like whether existing limits are overwritten or if special permissions are required.

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

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

Two focused sentences, front-loaded with purpose. No fluff.

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?

Output schema exists, only description needed to explain authorization logic. Could mention what happens on re-authorization but overall adequate for a simple auth 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 covers all 4 parameters with descriptions. Description adds context about rate limiting but doesn't significantly extend parameter meaning. 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?

Clearly states it authorizes a bridge for crosschain mint/burn operations using ERC-7802 standard. Distinct from sibling tools like crosschain_mint/crosschain_burn which perform the actual transfers.

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

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

Explicitly states that only authorized bridges can mint/burn tokens, implying this tool is used before crosschain operations. No explicit when-not-to-use or alternatives, but context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions creating a session and returning results but does not disclose side effects (e.g., state mutation), required permissions, or potential risks.

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

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

The description is extremely concise: one sentence for the action and one for the return, with no unnecessary words. It is front-loaded and efficient.

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

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

For a simple tool with 3 parameters, full schema coverage, and an output schema, the description covers purpose, key parameters, and return values. It lacks behavioral context but is otherwise complete.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds no extra meaning beyond echoing the schema (e.g., 'time limit' matches 'duration_secs'). 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 the verb 'authorize', the resource 'temporary session for a wallet', and key attributes (allowed operations, time limit). It distinguishes from sibling tools like 'revoke_session' and 'create_wallet' by emphasizing temporary sessions with constraints.

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 (when needing a temporary session with specific operations and duration) but does not explicitly state when not to use or contrast with alternatives like 'revoke_session' or other authorization tools.

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

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

No annotations provided, and the description only states the operation without detailing side effects, authorization needs, reversibility, or error conditions. The correlation ID hint is marginally helpful but insufficient.

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

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

The description is concise with two sentences, but the second sentence about correlation ID adds useful information. Could be improved by structuring parameter details.

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 cross-chain tool with 6 parameters and an output schema, the description lacks essential details about the message format, gas parameters, and return value. Incomplete for effective use.

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 the description offers no explanation of parameters like source_chain, destination_chain, payload_hex, etc. The agent must infer meaning solely from parameter names.

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 ('Dispatch an Axelar GMP `call_contract` message') and provides additional context about correlation ID. It distinguishes from sibling tools by specifying the exact operation.

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

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

No guidance on when to use this tool versus alternatives like hyperlane_dispatch or wormhole_bridge. No exclusions or prerequisites mentioned.

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 only states 'Look up', which implies a read operation, but does not detail side effects, access requirements, or any constraints. The description is insufficiently transparent.

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

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

The description is a single sentence of 9 words, with no wasted text. It is front-loaded with the action and resource, making it easy 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 tool's simplicity (one parameter, no complex behavior), the description is almost sufficient. The existence of an output schema reduces the need to describe return values. However, it could be slightly more complete by mentioning the format of payload_hash or the nature of the returned message.

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 0% description coverage for the only parameter. The description adds meaning by stating the lookup is 'by payload hash', which clarifies the parameter's purpose beyond the raw schema. This compensates for the lack of schema descriptions.

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

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

The description uses a specific verb 'Look up' and explicitly identifies the resource as 'Axelar GMP message' with the lookup criterion 'by payload hash'. This clearly distinguishes it from sibling tools like axelar_call_contract or hyperlane_get_message.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or comparison with similar tools like axelar_call_contract or hyperlane_get_message.

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 burden. It describes the operation as listing chains and provides examples, but does not disclose whether the list is dynamic, cached, or if there are any side effects. The read-only nature is unstated.

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 wasted words. Efficient and clear.

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

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

Given zero parameters and an output schema, the description is fairly complete. It lists chain categories and examples, but could be more explicit about the exact scope of 'supported' chains.

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 are no parameters in the schema, so the description adds context (list of chains) beyond what the schema provides. Schema coverage is 100%, and the description enhances understanding.

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 'List supported Axelar chains' which is a specific verb+resource. It distinguishes from siblings like axelar_call_contract and hyperlane_list_chains.

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

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

No explicit guidance on when to use this tool vs alternatives. While context is implied, explicit usage notes are absent.

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

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

With no annotations, the description must disclose behavioral traits. It only states 'pre-pay' but omits idempotency, failure modes, effects if already paid, or any side effects. The agent cannot assess risks beyond obvious mutation.

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?

Extremely concise single sentence that front-loads the action and resource. No filler. However, could incorporate more useful details without becoming verbose.

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

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

For a tool with 6 required params, no param descriptions, no annotations, and an output schema not elaborated, the description is insufficient. It omits crucial context like how to obtain the payload_hash, valid chains/tokens, and return value format.

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

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

Schema description coverage is 0% (6 parameters, none described). The description adds zero information about any parameter meanings, formats, or constraints. This leaves the agent blind to what each parameter represents.

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 (pre-pay) and the resource (Axelar Gas Service) with the context of a previously-dispatched message. It differentiates from sibling tools like axelar_call_contract and axelar_get_message by specifying this is a payment action for an already dispatched message.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., must have called axelar_call_contract first), and no conditions for when not to use it. The agent is left to infer usage from the name 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?

With no annotations, the description carries the full burden. 'Read' implies a safe, idempotent operation, but there is no mention of behavioral traits such as error handling, rate limits, or response structure beyond what the output schema provides. It does not disclose if the record is always returned or what happens if the validator does not exist.

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 with no superfluous words. It efficiently conveys the core purpose.

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

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

Given the tool is simple with one parameter and an output schema, the description is mostly adequate. However, it lacks guidance on error conditions and does not leverage the context of sibling tools to differentiate usage. For a low-complexity tool, it meets minimum viability but has noticeable 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?

There is only one parameter 'validator' with 0% schema description coverage. The description adds minimal context by specifying 'for a Tenzro validator', but does not clarify the expected format (e.g., address, ID). The schema only gives type 'string', so the description must compensate but fails to provide sufficient semantic detail.

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 verb 'Read' and the resource 'Babylon finality-provider record', specifying it is for a 'Tenzro validator'. This distinguishes it from sibling tools like 'babylon_list_finality_providers' (which lists multiple) and 'babylon_register_finality_provider' (mutation).

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

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

No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The description only states what it does, not the context or exclusions. For example, it does not mention that this tool retrieves a single record while 'babylon_list_finality_providers' retrieves all.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning if it is read-only, requires authentication, or has any side effects. Lacks depth for a tool with no annotation support.

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 with no wasted words. It is front-loaded and efficiently conveys the tool's purpose.

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

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

While an output schema exists, the description does not link to related tools or explain how this listing integrates with other Babylon operations. It is minimally complete but lacks contextual guidance for an agent.

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

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

Schema coverage is 0%, so the description must add meaning. It hints that the 'validator' parameter is a finality provider identifier, but does not clarify format, examples, or constraints. Provides minimal but not sufficient context beyond the schema.

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

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

The description clearly states the tool lists BTC delegations for a finality provider. It uses a specific verb 'list' and resource 'BTC delegations', and the scope 'for a finality provider' differentiates it from sibling tools like 'babylon_list_finality_providers' which lists providers.

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

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

No explicit guidance on when to use this tool vs alternatives. However, the context implies it should be used after selecting a finality provider, but no exclusions or when-not-to-use scenarios 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?

With no annotations provided, the description does not disclose behavioral traits such as read-only nature, rate limits, or pagination. The minimal description offers no additional context beyond the action.

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, front-loaded sentence with no superfluous words. Every word 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?

Given the tool's simplicity (no parameters, output schema exists), the description adequately states the tool's purpose. However, it lacks any mention of return format or limits, but the output schema covers that.

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, so the description cannot add parameter meaning. Baseline score of 4 applies since schema coverage is 100% and no parameter details are needed.

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

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

The description uses the specific verb 'List' and resource 'every registered Babylon finality provider,' clearly distinguishing from sibling tools like 'babylon_get_finality_provider' which fetches a single provider.

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 a broad listing use case but provides no explicit guidance on when to use or avoid this tool, or any alternatives. It is adequate for a simple tool but lacks depth.

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

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

No annotations provided, so the description carries full burden. It mentions registration and subsequent economic security but lacks details on side effects, permissions, reversibility, or state changes.

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, zero waste, front-loaded with the core action. 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?

Despite having an output schema, the description omits behavioral context, return value explanation, and prerequisites. Inadequate for a registration/mutation tool with no annotations.

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 btc_pk has a description). The description adds no additional meaning for validator or commission_bps, and for btc_pk it merely echoes the schema.

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

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

The description clearly states the action ('Register') and the specific resource ('Tenzro validator as a Babylon finality provider'), effectively distinguishing it from sibling tools like babylon_get_finality_provider and babylon_submit_finality_signature.

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

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

No guidance on when to use this tool versus alternatives (e.g., when to register vs get or list). The description does not specify prerequisites, exclusions, or context 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?

Discloses the important behavioral consequence of equivocation slashing BTC delegations. However, it does not mention other traits like destructive hint, authorization requirements, or rate limits. With no annotations, the description partially fills the gap.

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 with no superfluous words. The first sentence states the action, the second adds key behavioral context. Every word 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?

Given the tool's complexity (submission with slashing risk) and lacking output schema details, the description does not mention prerequisites (e.g., being a finality provider) or parameter formats for validator and block_hash. The output schema exists but is not shown, so completeness is moderate.

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?

Only one parameter (eots_signature) has a description, providing format info ('0x-prefixed hex'). validator and block_hash lack any description. With schema coverage at 33%, the description should compensate but does not fully explain all 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?

Description clearly states the action: 'Submit an EOTS over a Tenzro block hash.' The verb 'submit' and resource 'EOTS' are specific. It also distinguishes from sibling tools like babylon_get_finality_provider by mentioning the consequence of equivocation.

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

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

No explicit instructions on when to use this tool versus alternatives (e.g., other Babylon tools). The description implies usage when submitting a finality signature, but lacks guidance on prerequisites or exclusion 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has side effects. The description adds minimal value beyond the tool name.

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

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

The description is extremely concise at 4 words, but it lacks necessary detail. It is efficient but under-specified for an AI agent.

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 simplicity and the existence of an output schema, the description does not explain return values or provide sufficient context. For an agent to correctly use this tool, more information is needed about the parameter and result.

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 0% description coverage, and the description does not explain the meaning of the 'validator' parameter (e.g., what format, how it relates to a finality provider). The parameter name is somewhat self-explanatory but not fully.

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 verb 'Sum' and the resource 'BTC delegations for a finality provider', which is specific and distinguishes from sibling tools like babylon_list_delegations (list all) and babylon_get_finality_provider (get provider info).

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., babylon_list_delegations) or any context about prerequisites or suitability.

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 exist, so the description carries full burden. It discloses the tool is read-only ('without executing the transfer') and lists the return content. However, it does not mention potential errors, authentication needs, or idempotence, but these are less critical for a quote 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: first defines purpose and output, second states use case. No unnecessary words, front-loaded with key information.

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

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

Given no annotations, the description adequately covers the tool's purpose and output. The existence of an output schema is mentioned. It could include a note on required authentication, but the simple nature of a quote tool makes this 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?

Schema description coverage is 100%, so parameters are already well-documented. The description adds no new parameter-specific information beyond stating it's for previewing costs. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool gets a bridge quote without executing the transfer, specifying the return values (estimated output amount, fees, time, recommended route). It distinguishes itself from transfer-execution tools like bridge_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 explicitly advises using this tool 'for previewing costs before committing to a bridge transfer.' It does not explicitly list when not to use or mention alternatives, but the context is clear and the sibling tools (e.g., bridge_tokens) are distinct.

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; description fails to disclose side effects, permissions, fees, execution semantics (immediate? atomic?), or response expectations, leaving the agent underinformed for a complex mutation 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?

Two short sentences front-load purpose, then detail routes and adapters, with no unnecessary words. Efficiently 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?

Although the purpose is clear, the description omits key context for a multi-chain bridge tool: prerequisites (e.g., approved tokens), process steps, adapte-specific logic, and output handling, leaving the agent unable to fully understand the tool's role in a workflow.

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 has 100% coverage with clear parameter descriptions; the description adds context on supported chains and adapters but no additional constraints or semantics beyond schema (e.g., which assets are available per chain).

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

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

Clearly states the verb 'bridge' and resource 'tokens between blockchains', specifies supported chains and adapters, distinguishing it from sibling tools like authorize_crosschain_bridge or bridge_quote.

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 token bridging but lacks explicit guidance on when to use this vs alternatives (e.g., getting a quote first via bridge_quote) or handling prerequisites like authorization.

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 hook_target contract is called with hook_calldata after tokens arrive on destination chain. No annotations are present, so the description carries full burden. It does not mention authorization requirements or edge cases, but the core behavior is well described.

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: first states the main action, second explains the hook call and exemplifies use cases. No wasted words, front-loaded with the key 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?

Tool has 7 required parameters, output schema exists, and no nested objects. Description explains the hook mechanism adequately. It does not mention return values, but output schema covers that. No prerequisites or error conditions are discussed, but the core functionality is complete for a bridge tool with hooks.

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 baseline 3. The description adds no additional meaning beyond what the schema provides (e.g., hook mechanism). It does not explain how to construct hook_target or hook_calldata.

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

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

Clearly states verb (Execute) and resource (bridge transfer with deBridge post-fulfillment hook). Distinguishes from sibling bridge tools by highlighting the hook feature, which is unique among siblings.

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 composable cross-chain operations (e.g., bridge + swap, bridge + stake) but does not explicitly state when not to use or provide alternatives. Could be improved by contrasting with bridge_tokens or debridge_create_tx without hooks.

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 provides key behavioral details: input formats (hex or base58btc) and normalization to canonical 64-hex. However, it does not disclose any authentication requirements or potential errors.

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 front-loading the purpose and key behavior. Every sentence adds value 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?

For a simple 1-parameter tool with an output schema, the description covers input formats and normalization. It could mention the output format, but the output schema makes this less critical.

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 of the 'address' parameter in the input schema repeats the same information as the tool description, adding no new meaning beyond the schema.

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

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

The description clearly states the verb (Get) and the resource (CAIP-10 account id for a Tenzro address), distinguishing it from sibling tools like caip2 (chain ID) and caip19 (asset ID).

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

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

No explicit guidance on when to use this tool versus alternatives like caip2 or caip19. The usage is implied by the description but not differentiated in context.

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

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

With no annotations provided, the description carries full burden but only states 'Get' without indicating whether it is a read-only operation, requires authentication, or has side effects. It does detail namespace structure but omits behavioral traits.

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

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

Extremely concise: one sentence and a compact list of namespaces. Information is front-loaded and every element contributes to understanding. 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 the tool's moderate complexity and presence of an output schema, the description covers namespace structure adequately. However, it lacks behavioral context (e.g., read-only, permissions) that would make it complete. The agent can infer usage but not fully.

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%, but the description adds valuable context beyond field descriptions: explains the slip44 namespace with a specific coin index, clarifies role of token_id for token vs nft, and introduces collection_id alias. This meaningfully augments 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?

Clearly states the tool returns a CAIP-19 asset id and enumerates three namespaces with concrete examples (slip44, token, nft). This provides clear purpose, though it could further distinguish from sibling CAIP tools like caip2 and caip10.

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

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

No explicit guidance on when to use this tool versus alternatives such as caip10 or caip2. The description implies use for generating CAIP-19 identifiers but offers no context about prerequisites or exclusion 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?

With no annotations, the description carries full burden. It describes the return schema and notes the evm_chain_id sidecar. It implies a read operation and no destructive behavior. It could mention whether authentication is needed or if it always succeeds, but for a simple getter it 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 extremely concise: two sentences that front-load the purpose and then detail the return structure. Every sentence adds value with no waste.

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

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

Given the tool has no inputs and an output schema exists, the description covers the return format and a key detail (evm_chain_id sidecar). It could mention if there are any prerequisites (e.g., node must be synced) but is largely complete for a simple getter.

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 are no parameters, so schema coverage is 100%. The description adds value by explaining the return fields, which is the only relevant semantic information. Baseline for zero 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's purpose: 'Get the CAIP-2 chain id for this node'. It provides the exact format and return structure, distinguishing it from sibling tools like caip10 and caip19 which have different purposes.

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

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

The description implicitly tells when to use (when you need the node's CAIP-2 chain ID) but lacks explicit guidance on when not to use or mention of alternatives. The specificity of the tool makes its use case clear, so it scores well.

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 full burden. It discloses the refund effect and returns a confirmation, but it does not mention irreversible consequences, error conditions, or what happens if the task is not found or already completed.

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 distinct purpose: purpose, constraint, and behavior/return. It is front-loaded and contains no unnecessary words.

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

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

Given the tool's simplicity (2 params, output schema exists), the description covers the core aspects: what it does, who can use it, and what happens after cancellation. Missing error handling is a minor 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?

Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra meaning beyond the schema, which is adequate for a baseline 3.

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

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

The description clearly states the verb 'cancel' and the resource 'task', specifying it cancels 'pending or active' tasks on the Tenzro Task Marketplace. This distinguishes it from siblings like assign_task, complete_task, and delegate_task.

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 explicit authorization constraint ('Only the original requester can cancel') and mentions refunds. However, it does not explicitly state when not to use this tool or point to alternatives like complete_task for finished tasks.

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?

Without annotations, the description partially discloses behavior: assignment and conditional escrow locking. However, it omits details on side effects, authorization needs, reversibility, and how auto vs manual selection resolves.

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?

Single sentence is concise and front-loaded with the primary action. However, could benefit from structured breakdown (e.g., separate conditional clause) to improve scannability.

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 five parameters with auto/manual logic and escrow interaction, the description is incomplete. It does not address required intent_id, auto selection behavior, or payee role, leaving the agent underinformed for correct invocation.

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?

Only the 'payer' parameter gains meaning from the description (conditional locking). The schema covers solver_did (40% coverage), but other parameters (intent_id, auto, payee) are unexplained, leaving significant gaps.

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 assigns a solver to a capital intent and mentions a conditional escrow locking behavior. However, it does not explicitly differentiate from siblings like capital_intent_open or capital_intent_quote, though the action is distinct.

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

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

No guidance on when to use this tool versus alternatives (e.g., capital_intent_open, capital_intent_quote). The description does not state prerequisites, exclusions, or typical contexts for assignment.

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 carry the behavioral burden. It discloses the action (refund and fail), which implies mutation/destruction. However, it does not detail side effects, authorization needs, or output format, leaving gaps.

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 focused sentence that efficiently conveys the core function and reference. Every word serves a purpose.

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

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

For a simple tool with one parameter and an output schema, the description covers the essential operation but omits details about the output, postconditions, and specific context of when compensation is appropriate. It is adequate but not comprehensive.

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 0% and the description does not explain the parameter intent_id. While the parameter name suggests its purpose, the description should explicitly state that it is the identifier of the capital intent to compensate.

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 the specific verb 'Compensate' and resource 'capital intent', explaining the effect 'refund the principal escrow and fail'. It distinguishes from sibling tools like capital_intent_execute and capital_intent_settle by its unique action.

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

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

No guidance on when to use this tool vs alternatives like workflow_step_compensate or other capital intent tools. The mention of mirroring tenzro_capitalIntentCompensate provides a reference but not actionable usage 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?

No annotations are provided, and the description lacks any behavioral details such as idempotency, side effects, permissions required, or what constitutes a successful recording. The simple phrase 'Record one executed settlement leg' provides minimal 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 extremely short (one sentence). While it is concise, it lacks structure and omits important details. It is not verbose, but it is under-specified.

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 annotations, a minimal description, and a relatively complex action (recording a settlement leg), the description is incomplete. It does not mention output, expected behavior, or edge cases. The presence of an output schema is not leveraged in the description.

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?

Only 50% of parameters have schema descriptions (leg has a string description; intent_id does not). The tool description adds no additional meaning beyond the schema. For instance, it does not clarify the expected format of the leg object or the purpose of intent_id.

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 ('Record') and the resource ('one executed settlement leg of a capital intent'), which is specific. However, there is a slight ambiguity as the tool name suggests executing, while the description says recording an already executed leg. Still, it distinguishes from siblings like capital_intent_open or capital_intent_settle.

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

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when to avoid it. For example, it is unclear how this differs from capital_intent_settle or capital_intent_verify.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It hints at compliance (reg regime, KYC, ceilings) but does not disclose side effects, authorization needs, idempotency, or consequences of failure. For a mutation tool, this is insufficient.

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 efficiently convey the tool's purpose and reference. No fluff, but structure could be improved by front-loading the primary action and constraints. Minor points for brevity.

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 presence of an output schema, return values are covered. However, the description lacks context on prerequisites, state changes, or how 'opening' differs from other capital_intent operations. The mention of mirroring another tool helps but does not fully standalone.

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

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

Schema coverage is 100% with a detailed description of the 'intent' object. The description adds marginal value by implying the intent must be 'signed', though the schema marks signature as optional. No further enrichment beyond the schema.

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

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

The description clearly defines the action ('Open') and resource ('signed Capital Intent') with detailed context about regulated capital allocation, objectives, and compliance elements. It explicitly distinguishes itself by noting it mirrors 'tenzro_capitalIntentOpen', aiding sibling differentiation.

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 lacks explicit guidance on when to use this tool versus sibling tools like capital_intent_assign, capital_intent_execute, etc. It mentions the tool is for opening a 'signed' intent but does not provide when-not or alternative instructions.

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 fully disclose behavioral traits. It indicates a write operation ('submit a solver bid') but omits details like authorization requirements, side effects, or the ranking process. The agent lacks information on whether the bid is replaceable or what happens upon submission.

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 very concise (one sentence, 16 words) but sacrifices necessary details. It is front-loaded with the main action, but missing parameter info and usage context makes it less effective.

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 5 parameters with 0% schema coverage and no annotations, the description is severely incomplete. The tool also has an output schema (not shown) that could explain return values, but the description does not reference it. An agent cannot reliably invoke this 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?

None of the 5 parameters are described in the input schema (0% coverage). The description does not explain the meaning of required fields like intent_id or solver_did, nor the optional parameters (plan, price, eta_secs). An agent cannot understand what values to provide.

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: 'Submit a solver bid to fulfil a capital intent'. It specifies the ranking criteria (ERC-8004 + KYA) and notes it mirrors another tool, which helps distinguish it from sibling tools like capital_intent_assign or capital_intent_execute.

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

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

The description provides no guidance on when to use this tool versus its siblings (e.g., capital_intent_assign, capital_intent_execute). It only mentions 'mirrors tenzro_capitalIntentQuote', but does not explain the context or prerequisites for submitting a bid.

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

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

The description discloses basic behavioral traits (release escrow, write feedback, finalize) but lacks details on state prerequisities, permissions, reversibility, or side effects. Without annotations, it carries some burden but is insufficient.

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 (two sentences) with no wasted words. It front-loads the core actions. However, structure could be improved by separating parameter hints.

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 2 parameters, siblings, and an output schema, the description fails to explain state transitions, prerequisites, or return value usage. It misses crucial context for a settlement action.

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%, yet the description adds no parameter meaning. It does not clarify the roles of 'intent_id' (required) or 'payee' (optional). Completely fails to compensate for lack of schema documentation.

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

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

The description clearly states the tool's purpose with specific verbs ('release escrow, write ERC-8004 feedback, finalize with a receipt') and resource ('capital intent'). It distinguishes from siblings like capital_intent_open and capital_intent_execute by focusing on 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?

No guidance on when to use this tool vs alternatives (e.g., capital_intent_compensate, capital_intent_verify). The mention of 'mirrors tenzro_capitalIntentSettle' does not provide meaningful usage 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?

No annotations are provided, and the description gives minimal behavioral context. It does not disclose whether the operation is read-only, requires authentication, or any side effects. The condition 'requires all legs settled' is a precondition, not a behavioral trait.

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

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

The description is extremely concise with two sentences, front-loading the core purpose. 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?

Despite having an output schema, the description does not explain what the verification result indicates or how to interpret it. Given the complexity of the capital intent lifecycle (multiple sibling tools), the description lacks sufficient context for correct invocation.

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 the description does not explain the 'intent_id' parameter beyond its name. The parameter's purpose is vaguely implied by the tool name, but no details on format or expected values are given.

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

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

The description clearly states the action ('verify') and the resource ('capital intent's proofs'), and distinguishes it from sibling tools like capital_intent_assign, capital_intent_settle, etc., which cover other lifecycle stages.

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

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

Explicitly mentions a precondition ('requires all legs settled'), guiding the agent on when to use this tool. However, it does not specify when not to use it or provide alternative tools for unverified intents.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It correctly indicates a read operation ('Get') and lists return fields. However, it does not mention potential side effects, error conditions (e.g., chain not found), or authorization requirements, leaving some gaps.

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

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

The description is extremely concise: a single sentence that immediately states the purpose and follows with a list of return fields. Every word earns its place 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 simplicity of the tool (single parameter, no output schema details needed as one exists), the description is largely complete. It could mention that the chain must be a valid TNZO chain, but otherwise it covers the essential information for selection and invocation.

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 only parameter 'chain' is described with examples). The description adds 'by chain name' and the context of retrieving a single pool, but it does not supplement the parameter description beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get a single TNZO CCT pool by chain name.' It clearly states the action and distinguishes itself from the sibling tool cct_list_pools by specifying 'single' versus 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 implies when to use this tool (to get a single pool, not a list) but does not explicitly state exclusions or direct comparison to alternatives like cct_list_pools. The presence of the sibling tool in the list provides context but the description could be more explicit.

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, description correctly identifies this as a read-only list operation. It adds valuable context about the canonical mainnet registry and included networks, fully transparent for a simple list 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?

Single sentence with zero redundancy; all words are informative and front-loaded.

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

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

Given no parameters, no annotations, and presence of output schema, the description fully specifies the tool's purpose and scope (exact resource, registry, networks).

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 in schema, so baseline is 4. Description adds meaning by specifying the type of pools (TNZO CCT) and the registry scope beyond the empty 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?

Description uses specific verb 'List' and resource 'TNZO CCT pools' with explicit network suffixes, clearly distinguishing it from sibling tool 'cct_get_pool' (which retrieves a single pool).

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

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

No explicit guidance on when to use this tool vs alternatives; the use case is implied (listing all pools), but no exclusions or conditions 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?

No annotations are provided, and the description does not disclose any behavioral traits such as mutability (e.g., token consumption), authorization requirements, or side effects, leaving a significant gap.

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 purpose, and contains no redundant information.

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

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

Given the simple tool with 4 parameters fully described in the schema and the presence of an output schema, the description is minimally complete but lacks behavioral context.

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 description does not add parameter-level 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 the action ('Send a chat completion request') and the resource ('a served AI model on the Tenzro network'), distinguishing it from sibling tools by referencing model discovery 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 explicitly instructs to use list_models or list_model_endpoints before calling this tool, providing clear context and alternatives for model discovery.

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 burden. It explicitly states the tool is non-executing (read-only) and returns compliance status with violation details. This is good transparency, though it could mention prerequisites like registered compliance rules or failure modes.

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, and zero waste. Every word earns its place. Ideal conciseness.

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 presence of an output schema, the description need not detail return values. It covers key points: compliance check, ERC-3643, no execution. Could mention that the token must have compliance rules registered, but overall adequate for a check tool with good schema support.

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%, meaning all parameters are already described in the schema. The description adds no additional meaning beyond what's in 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 the verb (check), the resource (token transfer compliance with ERC-3643 rules), and explicitly distinguishes from executing the transfer. It is specific and differentiates from sibling tools like crosschain_burn or transfer_nft.

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 before executing a transfer by stating 'Does not execute the transfer.' However, it does not explicitly say 'use this to validate before a transfer' or mention alternatives when actual transfer is needed. The context is clear but lacks explicit guidance on when not to 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?

No annotations provided. The description states 'Clear', implying a destructive mutation, but does not disclose any side effects, permissions needed, or reversibility. The agent gets minimal behavioral insight.

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?

Extremely concise at one sentence of six words. While it wastes no words, it could pack more informative content into the same space without sacrificing brevity.

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

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

No explanation of what the Secure-Mint policy is, what clearing does, or any output expectations. An output schema exists but is not used in the description. The agent lacks sufficient context to use the tool 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?

Only one parameter 'asset_id' exists with 0% schema coverage. The description adds no meaning to this parameter—does not explain what it represents or how to obtain 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 uses a specific verb 'Clear' and resource 'Secure-Mint policy', clearly distinguishing from sibling tools like 'set_secure_mint_policy' and 'get_secure_mint_policy'. However, it lacks detail on what 'clear' entails exactly (e.g., reset to default vs. remove policy).

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

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or exclusion conditions despite the presence of related 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?

Discloses key behavioral traits: closing a channel, settling on-chain, returning unused deposit. Without annotations, the description carries the full burden and covers the main effects. Could mention irreversibility or failure 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?

Two focused sentences with no wasted words. First sentence states purpose and condition, second adds effect. Information is front-loaded.

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 output schema exists, the description explains the on-chain effect and deposit return. It covers prerequisites and overall behavior. Could mention if the channel must be open or if it's a final action.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond what is already in the schema for the 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?

Clearly states the action 'close a micropayment channel' with the specific resource and key operation (final balance settlement, return of unused deposit). Distinguishes from siblings like 'open_payment_channel' which is an opposite action.

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

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

Explicitly states a prerequisite: 'Requires sender signature on the final state.' However, does not provide guidance on when to use this tool versus alternatives like 'settle_payment' or when not to use it.

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

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

With no annotations, the description carries full burden. It discloses the settlement payment trigger and return of receipt but omits details like required permissions, idempotency, or failure modes.

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 front-loaded sentences with no redundancy. Every sentence adds essential 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?

Adequately describes the core functionality and output, but lacks context on idempotency, error states, or behavior when task is already completed. Given the schema and output schema, it is mostly 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?

Schema coverage is 100% and the description adds minimal value beyond the schema, only mentioning the optional proof parameter. 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 the action (mark as completed), resource (task), and additional effects (triggers payment, returns receipt), distinguishing it from siblings like cancel_task or assign_task.

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

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

No guidance on when to use this tool versus alternatives such as assign_task, cancel_task, or delegate_task. Missing context about prerequisites or 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?

Discloses key behaviors: truncation to last for remainder, non-settlement nature. With no annotations, description carries full burden and adequately covers the tool's boundaries.

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 'Pure preview', no redundant words. Each sentence serves distinct purpose: purpose and behavioral clarification.

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?

Output schema exists, so return details are covered. Description provides purpose, behavior, and usage context. Minor gap: does not mention if fee_route_id must exist.

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

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

Schema covers 100% of parameters with descriptions. Description only rephrases 'gross_wei' without adding new meaning beyond schema.

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

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

Clear verb+object: 'compute fee route payouts' with 'preview' specifying it's a simulation. Distinguishes from settlement tools like 'settle_payment' by explicitly stating 'does not settle'.

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

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

Explicitly states 'Pure preview' and 'Does not settle — settlement is consensus-mediated.', which guides when to use (preview) and when not (actual settlement). Lacks explicit alternative naming but context is clear.

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

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

Without annotations, the description carries the full burden of behavioral disclosure. It explicitly mentions TNZO charging, the return of a signed CortexReceipt with specific commitments, and tier/loop budget selection. No destructive actions are implied, and the description aligns with the computational nature of the tool.

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

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

The description is a single paragraph of four sentences, front-loading the core purpose and then providing essential behavioral details. No redundant or filler sentences; every sentence serves a purpose.

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

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

Given the tool's complexity (8 params, 2 required) and the presence of an output schema, the description covers purpose, pricing, receipt details, and tier options. It mentions model registration prerequisite but omits error scenarios or network requirements. Overall, it is sufficiently complete for an agent to understand core functionality.

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 8 parameters. The description adds minimal value beyond the schema, only reiterating tier and loop override concepts. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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 executes 'Tenzro Cortex recurrent-depth reasoning' using a registered Cortex worker. It specifies the action (invoke), the resource (Cortex worker), and the context (recurrent-depth transformer), distinguishing it from many sibling tools like chat_completion or list_models.

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 implicit guidance on tier selection but does not explicitly state when to use this tool versus alternatives like chat_completion. No when-not or alternative tool references are provided, leaving the agent to infer context based on purpose 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?

With no annotations, description fully discloses mutative nature, authentication requirement, revocability implications, auto-inject interlock for protected keys, and single-use plaintext return with persistence advice. No hidden behaviors.

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?

Single dense paragraph with all key information. Front-loaded with critical 'Operator-only' note. Could benefit from structuring into bullet points for readability, but 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?

Covers prerequisites, authentication, parameter options, behavioral interlock, and return handling. Given output schema presence, description completes the missing behavioral and security context effectively.

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

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

Schema coverage is 100%, baseline 3. Description adds detailed semantics for 'class' parameter beyond schema. Other parameters are adequately described in schema, but no extra detail for label, scopes, or subject.

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

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

Clearly states it creates an API key on the node with 'Mint a new API key on this node'. Distinguishes from sibling tools like list_api_keys and revoke_api_key by focusing on creation and administrative control.

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?

Specifies operator-only usage and required admin token header. Explains class options for revocability. Does not explicitly contrast with alternatives like list_api_keys, but the context is sufficient for correct 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?

No annotations are provided, so the description carries the full burden. It discloses that funds are locked at a deterministic vault address and only the payer can release/refund. However, it does not explain what happens if the escrow_id already exists, revert conditions, gas costs, or failure modes. This is acceptable but not thorough.

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

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

Two sentences: first sentence describes the action, second adds an important constraint. No extraneous words. Highly concise and front-loaded.

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?

Although an output schema exists, the description does not mention the return value or success indicators. For a creation tool, it would be helpful to note what the response includes (e.g., transaction hash, escrow_id). However, given the output schema likely covers this, the description is minimally adequate.

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% (all 5 parameters have descriptions). The description adds context about the vault address and payer control, but does not elaborate on the parameters themselves beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool creates an on-chain escrow via a signed transaction, and distinguishes from siblings like release_escrow and refund_escrow by noting that only the payer can later release or refund. The verb 'create' and resource 'escrow' are specific.

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 this tool should be used to lock funds for a conditional release, and that subsequent actions (release/refund) are handled by other tools. It could be more explicit about prerequisites (e.g., the signer must be the payer) and when to use alternatives like get_escrow, but it provides clear 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?

No annotations are provided, so the description carries full burden. It states creation and return values but lacks side effects, permissions, idempotency, or whether the wallet is on-chain. The default threshold is useful, but overall behavioral context is insufficient.

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 with front-loaded action and return information. Every sentence is valuable, no fluff.

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?

Covers basic purpose and return, but lacks guidance on alternative wallet creation tools and behavioral details like cost or failure modes. With no annotations, more context is needed for a complete picture.

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%, providing full parameter details. The description adds only the default 2-of-3, which is already implied by schema defaults. No additional meaning beyond schema.

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

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

The description uses a specific verb ('Create') and resource ('MPC threshold wallet'), clearly distinguishes from sibling tools like 'create_wallet' and 'create_user_wallet' by mentioning configurable threshold and default 2-of-3.

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 creating MPC wallets but gives no explicit guidance on when to use this over alternatives like 'create_wallet' or 'create_user_wallet'. No when-not-to-use or prerequisites are mentioned.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It indicates a write operation ('Create') and mentions return values, but does not describe side effects, permissions, reversibility, or potential conflicts (e.g., duplicate names). This is adequate but not thorough.

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

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

The description is extremely concise: two sentences, 30 words, front-loaded with the action verb. No redundant or 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?

For a creation tool with moderate complexity (6 params, 4 required), the description covers purpose, supported standards, and return values. It omits prerequisites (e.g., wallet registration) and potential constraints, but given the existence of an output schema (context signal), the description provides sufficient contextual 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% with each parameter having a description. The tool description reinforces the standard parameter by linking it to ERC-721/1155, but adds limited new meaning beyond what the schema already provides. 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 the action ('Create a new NFT collection'), specifies supported token standards (ERC-721 and ERC-1155), and explicitly mentions return values (collection ID and deployed address). This effectively distinguishes it from sibling tools like mint_nft or list_nft_collections.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., mint_nft). It implicitly suggests its purpose but lacks context about prerequisites or sequencing, leaving the agent to infer usage from the tool name 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?

No annotations are provided, so the description carries full responsibility. It only describes the protocols and purpose but omits behavioral details such as required permissions, side effects, or return values. The schema contradiction reduces trust in accuracy.

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 relatively concise but the protocol list is bulky and could be structured as a table or bulleted with additional context. No front-loading of critical info.

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 annotations and an existing output schema, the description should clarify what the challenge response contains. It does not mention return format, idempotency, or auth requirements, leaving the agent underinformed.

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 100% of parameters with descriptions, so baseline is 3. However, the description lists five protocols while the schema only enumerates three (mpp, x402, native), creating contradiction. This harms rather than adds value.

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 creates a payment challenge for a protected resource. Even among sibling payment tools like open_payment_channel, the verb 'create' and noun 'challenge' distinguish it, though no explicit differentiation is provided.

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

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

The description provides no guidance on when to use this tool versus alternatives like open_payment_channel or settle_payment. No when-not or context hints 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?

With no annotations provided, the description carries full burden. It discloses the stake requirement (behavioral constraint) and states the return value (proposal ID and initial status). However, it does not describe side effects, error conditions, or the implications of creating a proposal. More detail would improve 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 extremely concise with two clear sentences. It front-loads the primary purpose and follows with a key constraint and output summary. No filler or redundant information.

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

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

Given the lack of annotations and the presence of an output schema (though not shown), the description covers purpose and a key constraint but lacks details on error handling, prerequisites beyond stake, or the format of the output. It is adequate but not comprehensive for a 5-parameter 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 has 100% description coverage for all 5 parameters. The description does not add additional meaning beyond the schema's own descriptions. Per guidelines, baseline 3 is appropriate when schema coverage is high.

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 verb 'Create' and the resource 'governance proposal' on the Tenzro Network. It clearly distinguishes from siblings like 'vote_on_proposal' (voting) and 'list_proposals' (listing), as the action is specifically proposal creation.

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 mentions a precondition: 'Requires a minimum staked balance to propose.' This provides context for when the tool can be used, but it does not explicitly state alternatives or when not to use it. An agent would benefit from guidance on when to choose this over other governance tools like 'vote_on_proposal'.

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, description carries full burden. It explains basic behavior (parallel/sequential tasks, member specs) but lacks detail on side effects, permissions, idempotency, or error conditions. Adequate but not rich.

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 key info, no unnecessary words.

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

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

Given output schema exists and schema covers all params, description is fairly complete. It explains core concepts (member specs, parallel/sequential). Could mention return value or asynchronous nature, but overall good.

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

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

Schema coverage is 100% with clear descriptions. Description adds some context for 'members' and 'parallel' param but no extra meaning for other params. 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?

Description clearly states verb 'Create' and resource 'swarm of coordinated agents' on Tenzro Network. It distinguishes from sibling tools like 'spawn_agent' by specifying coordination and member specs.

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

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

No guidance on when to use vs alternatives, such as spawn_agent. Does not mention prerequisites, when not to use, or context for sequential vs parallel dispatch.

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