Tenzro Ledger MCP

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

No annotations provided, so description carries full burden. Description indicates a read-only operation and lists returned fields, but lacks details on authentication, performance, or side effects. Adequate for a simple query 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, front-loaded with verb 'Return', no extraneous words. Every word 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 (no parameters, no output schema), the description fully informs the agent of what the tool returns. No missing 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?

Tool has zero parameters; input schema coverage is 100%. Description correctly adds no parameter details as none exist. Baseline 4 per rules for 0 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 tool returns AP2 protocol metadata, listing specific fields (version, mandate types, VC formats, issuer DID methods). Distinguishes from sibling list tools which list resources or entities.

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. Usage is implied from description (get protocol metadata), but no exclusions or alternative tool mentions 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, the description effectively conveys key behavioral traits: signing produces a verified VDC, requires specific auth and key type, and enforces DID matching. It does not mention side effects or failure modes, but the constraints are 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 extremely concise with two sentences plus a terse constraint list. Every sentence is essential and front-loaded. No wasted words.

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

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

Given the tool's complexity (multiple params, no output schema, no annotations), the description covers the main behavioral aspects, auth, and constraints. It could briefly explain what a VDC is or how it is verified, but overall it is sufficient for an agent in context with sibling tools.

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 good parameter descriptions. The tool description adds extra context like VDC output and auth requirements, but these are not parameter-specific. It does not significantly improve parameter understanding 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 action ('Sign'), the resource ('AP2 mandate'), the key type ('Ed25519'), and the output ('verified VDC'). It distinguishes itself from sibling tools like ap2_validate_mandate_pair and ap2_verify_mandate by focusing on 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 explicit prerequisites: DPoP+JWT auth required, wallet must be Ed25519, and signer_did must match controller DID. However, it does not explicitly state when NOT to use this tool compared to alternatives, leaving slight ambiguity for the agent.

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 bears the full burden. It explains the validation steps and optional delegation cross-check, but it omits whether the tool is read-only or has side effects. It also does not disclose authentication needs or rate limits. The description is decent but could be more explicit about non-modification and other 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?

The description is two sentences, front-loaded with the main purpose and action, then adding the optional behavior. Every sentence earns its place with no redundancy. Very concise and well-structured.

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

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

The description covers the protocol roles (TDIP, AP2, Tenzro) and the validation logic, but it lacks any mention of the output format (e.g., returns boolean, error details). Without an output schema, this omission leaves the agent uncertain about the result. Also, behavioral details like whether it modifies state are missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the purpose of the mandate pair (ensuring cart references intent, amounts match constraints) and the behavior of enforce_delegation in detail. This enriches the parameter meaning.

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 Intent+Cart mandate pair for consistency, specifying what it checks (cart references intent, amounts/items match, VDC verification) and the optional delegation enforcement. It distinguishes from sibling 'ap2_verify_mandate' by focusing on pair validation rather than 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 provides clear context on when to use the tool (for validating a mandate pair) and explains the optional enforce_delegation parameter. However, it does not explicitly state when not to use it or mention alternatives like 'ap2_verify_mandate' for single mandates.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It states the verification checks (proof, issuer, schema) and references the AP2 spec, but does not explicitly confirm it is read-only, describe potential side effects, or outline error conditions. The term 'Verify' reasonably implies a read-only operation, but more explicit clarity would improve this score.

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 of 25 words with no redundant information. Every word contributes to conveying the tool's purpose effectively.

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

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

For a simple tool with one parameter and no output schema, the description adequately explains what it verifies and the standard followed. Missing details like return type or prerequisite validation are minor gaps, but overall it is sufficiently complete for an AI agent to understand and invoke correctly.

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

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

Schema coverage is 100% with a single parameter 'vdc' described as 'the full JSON-LD VC envelope with proof'. The tool description adds no additional explanation or constraints 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 verb 'Verify', the resource 'single AP2 mandate (Verifiable Digital Credential)', and specifies what is checked (proof, issuer, schema). It also mentions the scope (Intent, Cart, or Payment mandates per Google's AP2 spec) and implicitly distinguishes from sibling tools like ap2_validate_mandate_pair by indicating it handles a single 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 use for single mandate verification via the word 'single', which contrasts with the sibling ap2_validate_mandate_pair likely used for pairs. However, it lacks explicit 'when to use' or 'when not to use' guidance, and does not mention alternatives or prerequisites.

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

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

With no annotations, the description must disclose side effects and behavior. It states state change (open to assigned) and notification, which is adequate but minimal. Missing details on required permissions, idempotency, error conditions, or whether the task must be in the open state.

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

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

Three sentences with no fluff. First sentence states the action and purpose, second explains the state change and side effect, third describes the return value. 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 mutation with two parameters and no output schema, the description covers the core purpose, effect, and return. Lacks preconditions or error handling, but overall sufficient 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% with clear parameter descriptions. The description does not add meaningful extra meaning beyond the schema; it only repeats 'task' and 'agent'. The mention of 'notifies the agent' weakly ties to agent_did.

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 (assign), the resource (task), the target (specific agent), the marketplace context, the state change (open to assigned), and the side effect (notifies the agent). This distinguishes it from sibling tools like post_task, complete_task, or 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 implies usage context by mentioning the state transition from open to assigned, but it does not explicitly state when to use this tool versus alternatives (e.g., delegate_task) or provide any prerequisites or exclusions.

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

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

With no annotations, the description discloses key behavioral aspects: it sets daily limits for rate limiting and emphasizes only authorized bridges can mint/burn. However, it does not mention reversibility or permission requirements.

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

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

Two sentences, front-loaded with purpose and clear explanation of significance. 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 no output schema, the description lacks return value information but sufficiently explains the tool's impact. It could mention that this is a one-time setup or that limits are updateable.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minor value by giving an example for daily_mint_limit, but otherwise repeats 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 clearly states the tool authorizes a bridge address for ERC-7802 crosschain mint and burn operations, which is specific and distinguishes it from sibling bridge tools that perform transfers or quotes.

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?

It implies that authorization must occur before using crosschain_mint or crosschain_burn, but does not explicitly state when to use or provide exclusions or alternative tools. No mention of prerequisites like admin privileges.

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

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

No annotations provided, so description carries full burden. It discloses creation of a session (a state change) but lacks details on side effects (e.g., invalidating previous sessions), authentication requirements, or idempotency. Return format of session ID/expiry is vague.

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

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

Description is concise: two sentences. First sentence states purpose and scope, second sentence states return value. No fluff or redundancy.

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

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

Given no output schema, description mentions session ID and expiry but lacks details on formats or usage. No prerequisites or limits stated. Sibling revoke_session is complementary but not referenced. Adequate but incomplete for a security-sensitive 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 descriptions for each parameter. The tool description adds minimal extra value (e.g., 'specific allowed operations' and 'time limit'), but since schema already documents parameters well, 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 'Authorize', resource 'temporary session for a wallet', and specifics: allowed operations and time limit. It also mentions return value (session ID and expiry), distinguishing it from sibling revoke_session.

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

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

Usage is implied by the description (create session with restricted ops), but there is no explicit guidance on when to use versus alternatives like revoke_session or create_mpc_wallet. No when-not-to-use conditions provided.

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

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

With no annotations, the description must carry full burden. It states the tool returns estimates and does not execute, but lacks explicit mention of read-only nature, auth requirements, or any side effects. Partially transparent but could be more 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?

Two sentences, front-loaded with the verb 'Get', and no wasted 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?

For a moderate-complexity tool with no output schema, the description covers purpose, return values, and usage guidance. Missing some edge cases but adequate for an AI agent.

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

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

Input schema has 100% coverage with descriptions for all parameters. The tool description adds no extra meaning beyond what schema provides, so baseline of 3 is appropriate.

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

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

Clearly states it gets a bridge quote without executing transfer, and lists return fields. Differentiates from sibling tools like bridge_tokens by emphasizing 'without executing', but does not explicitly name the sibling tool for contrast.

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 says 'useful for previewing costs before committing to a bridge transfer', providing clear when-to-use context. Though it does not list when not to use, the phrase 'without executing' implies it is not for actual transfer.

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

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

No annotations provided, so description must convey behavioral traits. Mentions adapters but lacks disclosure on fees, slippage, finality, failure modes, or destructive potential. Agent cannot assess risks or side effects.

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

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

Two concise sentences: first states core action, second lists supported chains and protocols. No fluff, every word 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?

Missing output schema and no description of return value (transaction hash, status, error). Complex bridging operation with no guidance on expected response or failure handling.

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 descriptions cover all 6 parameters (100% coverage). Description does not add extra meaning beyond what schema already provides, so baseline of 3 is appropriate.

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

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

Clearly states verb 'Bridge', resource 'tokens', and specifies supported chains (Tenzro, Ethereum, Solana, Base) and adapters (LayerZero, Chainlink CCIP, deBridge). Distinguishes from sibling bridge tools like bridge_quote and bridge_with_hook.

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?

Implied usage for cross-chain token transfers, but no explicit guidance on when to use this tool over siblings like wormhole_bridge, bridge_with_hook, or debridge_create_tx. Does not provide when-not or prerequisites.

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

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

With no annotations, the description bears the burden of behavioral disclosure. It explains the hook execution sequence (after arrival, hook_target called with hook_calldata) and notes composability. No contradictions, but missing details on potential failures or prerequisites.

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 succinct sentences, each adding value: first states the core action, second explains the hook mechanism and purpose. No wasted words, 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?

The description covers the tool's purpose and hook behavior well but lacks details on return values, error handling, or preconditions. Given the 7 parameters and no output schema, it is reasonably complete but could be richer.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context about the workflow but does not significantly enhance parameter understanding beyond the 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 clearly states the verb 'Execute a bridge transfer' and the resource 'deBridge post-fulfillment hook', distinguishing it from sibling tools like bridge_tokens by emphasizing the hook mechanism and composability.

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 when a post-fulfillment hook is needed, with examples of composable operations. However, it does not explicitly state when not to use this tool or suggest alternatives like simple bridging 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, so description carries full burden. It discloses cancellation scope, refund, and confirmation but omits details on idempotency, error states, or side effects. 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?

Three concise sentences, front-loaded with action and resource, no extraneous information. Each sentence earns its place.

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

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

For a simple cancellation with 2 parameters and no output schema, the description covers core aspects. Could improve by mentioning error conditions or state transitions, but overall sufficient.

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

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

Schema covers both parameters with clear descriptions. The description adds value by explaining requester_address is for authorization, reinforcing the 'original requester' constraint.

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 cancels a pending/active task on a specific marketplace, with details on who can cancel (original requester) and what happens (refund, confirmation). This distinguishes it from siblings like complete_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?

Specifies that only the original requester can cancel, providing a key usage condition. However, it does not explicitly mention alternatives or when not to use it, missing some guidance relative to sibling 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?

Straightforward read operation; no annotations but description discloses return fields. No side effects or prerequisites needed.

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 essential information and return fields. 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?

Simple get tool; description lists all output fields, sufficient for usage without output schema.

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

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

Schema coverage 100% with parameter description; tool description does not add extra 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?

Clear verb 'Get' and resource 'single TNZO CCT pool by chain name'. Distinguishes from 'cct_list_pools' sibling by specifying 'single'.

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 when/when-not/alternatives. Implied by sibling name but not 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 provided, so description carries full burden. It indicates a read-only operation but does not disclose response format, pagination, or rate limits. Basic purpose is transparent but lacks 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?

Single, front-loaded sentence with zero waste. Every word adds meaning.

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

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

Given no output schema and 0 parameters, description is adequate for a simple list tool. Specifying the chains is helpful. Could mention return format, but not 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?

No parameters, so baseline is 4. Description adds value by specifying the chains and registry context, which is not in the schema. Schema coverage is 100% but irrelevant.

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

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

Description clearly states it lists all TNZO CCT pools, specifying verb 'List' and resource 'pools' with scope (canonical mainnet registry, specific chains). It distinguishes from sibling tool 'cct_get_pool' which lists 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?

Implies use when needing a full list of pools. Although it doesn't explicitly exclude alternatives, the sibling name 'cct_get_pool' suggests differentiation. No explicit when-not 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 provided, so the description carries full burden. The description is minimal, lacking details on behavioral traits such as idempotency, response handling, error cases, rate limits, or authentication requirements. Essential context for an API call is missing.

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 plus a suggestion) and front-loaded with the core action. Every word serves a purpose, though it sacrifices completeness. It's efficient but slightly underspecified.

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 4 parameters and no output schema, the description does not explain return values, synchronous vs streaming behavior, or error scenarios. For an AI completion tool, key operational context is missing, making it 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 100%, with each parameter already well-documented in the schema. The description adds no additional parameter information beyond 'model' and 'message' context. Baseline 3 is appropriate as schema does the heavy lifting.

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 ('served AI model on the Tenzro network'). It also points to sibling tools (list_models, list_model_endpoints) for discovery, distinguishing it from other tools.

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

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

The description explicitly advises using list_models or list_model_endpoints to discover available models, providing clear guidance on prerequisite steps. However, it does not mention when to avoid this tool or compare with alternatives like cortex_reason.

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

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

No annotations provided, so description carries full burden. It states the tool is read-only (does not execute) and what it returns. Could be enhanced by mentioning prerequisites (e.g., registered compliance rules).

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

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

Three concise sentences, front-loaded with purpose. No unnecessary words. Efficiently conveys 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 output schema, description covers purpose, behavior, and return type. Lacks error conditions or prerequisites, but sufficient for a straightforward compliance check tool.

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

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

Input schema has 100% coverage with clear descriptions. Description adds context about ERC-3643 compliance, which ties parameters to that domain. Slightly above 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?

Description clearly states the action (check compliance), the specific context (ERC-3643 token transfer), and the return value (status with violation details). It distinguishes from related tools like register_compliance and send_transaction.

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 says 'does not execute the transfer', clarifying it is a pre-check tool. Provides clear context for when to use, but does not explicitly state when not to use or list alternative tools.

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

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

No annotations are provided, so the description carries full burden. It discloses key behaviors: it closes a channel, settles balance on-chain, and returns unused deposit. However, it misses potential side effects like irreversibility or what happens if the channel is already closed.

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—two sentences that convey all essential information without any fluff. It is front-loaded with the primary action.

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

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

Given 3 parameters and no output schema, the description covers the action but lacks return value details (e.g., what exactly 'returns any unused deposit' means) and does not mention preconditions like the channel must be open. Could be more complete for a mutation tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the parameter descriptions; it mentions 'final balance' and 'sender signature' but these are already clear from the schema. No additional semantics are provided.

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

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

The description clearly states the tool's action (closing a micropayment channel), the resource, and key details like requiring sender signature and settling on-chain. However, it does not explicitly differentiate from sibling tools like 'open_payment_channel' or 'settle_payment', which would enhance clarity.

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

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

The description provides a prerequisite (requires sender signature) but lacks guidance on when to use this tool versus alternatives. No explicit when-to-use or when-not-to-use conditions 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?

No annotations provided; description carries full burden. Discloses side effect (triggers settlement payment), optional proof, return of receipt. Doesn't cover error conditions or security implications but is adequate for basic usage.

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

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

Three concise sentences with no fluff. Each sentence adds distinct value: purpose, optional parameter, side effect with return. Efficiently communicates core functionality.

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

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

No output schema, but description mentions 'completion receipt'. Lacks error scenarios, authentication requirements, or idempotency. Good coverage of essential aspects for a mutation tool.

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

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

Schema coverage is 100% with parameter descriptions. Description adds minimal semantic value beyond schema (e.g., 'JSON result payload', 'hex-encoded'). No deeper explanation of result structure or proof format.

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 'mark as completed' and resource 'task', includes result payload, optional proof, payment trigger, and receipt. Distinguishes from sibling task tools like assign_task, cancel_task, 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?

Description implies usage context (completing a task) but lacks explicit when-to-use vs alternatives, prerequisites, or when not to use. No guidance on required state of task.

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 explains execution behavior: it charges TNZO based on token counts and loops, returns a signed receipt with commitments and hashes. However, it does not disclose whether the operation is read-only or destructive, nor any authorization or rate limit details. The cost and return format are 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 concise (4 sentences plus a positioning line) and front-loaded with the primary action. The positioning line is somewhat meta but non-essential. Every sentence adds value, though the structure could be slightly improved.

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

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

Given the complexity (8 parameters, no output schema), the description explains the return value (CortexReceipt) but not its full structure. It lacks mention of prerequisites like model registration (only in schema), error conditions, or lifecycle details. This leaves some gaps 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?

Input schema has 100% coverage with descriptions for all 8 parameters. The tool description adds extra context beyond schema: it defines the tier options with loop estimates and states that max_loops/min_loops override tier. This enriches the semantic understanding of 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?

Description clearly states the verb 'Invoke' and resource 'Tenzro Cortex recurrent-depth reasoning', specifying it executes a recurrent-depth transformer through a registered worker. It differentiates from siblings by emphasizing the unique positioning of Cortex versus Praecise and Tenzro, and notes the charging mechanism and receipt return.

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 guidance on tier selection ('Use tier=\'fast|standard|deep|institutional\' to select the reasoning depth budget') but does not explicitly state when to use this tool versus alternatives like chat_completion or other reasoning tools. No when-not-to-use or exclusion criteria 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, the description carries full burden. It discloses that funds are locked and only the payer can release/refund, but omits important details like signing requirements, blockchain fees, or irreversibility. The mention of a signed transaction implies external signing but doesn't explain the process.

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

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

The description is two sentences long with no superfluous words. It front-loads the main action and adds key behavioral details in the second sentence.

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 output schema and annotations, the description should explain return values (e.g., transaction hash), side effects, and prerequisites. It only mentions a signed transaction but does not clarify what the tool returns or how signing is handled, leaving significant 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 input schema has 100% coverage, and the description adds minimal extra meaning beyond the schema. It references 'escrow_id' which is not in the schema, potentially causing confusion. 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 uses the verb 'create' and specifies the resource 'on-chain escrow' with clear details about the deterministic vault address and payer control. This distinguishes it from sibling tools like refund_escrow and release_escrow.

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 given on when to use this tool versus alternatives (e.g., when to use release_escrow or refund_escrow). The description lacks 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?

No annotations are provided, so the description must bear the full burden. It states it creates a wallet and returns metadata, but does not disclose side effects (e.g., whether it overwrites existing wallets), required permissions, or error conditions. This is a notable gap for a creation 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 two sentences with no extraneous words. Essential information (purpose, default, return values) is front-loaded, achieving high information density.

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

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

The description mentions return values (wallet ID, address, key share metadata) but lacks details on error handling, idempotency, or prerequisites. For a creation tool with 3 optional parameters and no output schema, additional context would improve completeness.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds context by mentioning the default 2-of-3 configuration, which relates to 'threshold' and 'total_shares'. However, it does not elaborate on 'key_type' or any constraints 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 creates an MPC threshold wallet with configurable threshold and share count, defaulting to 2-of-3, and lists return values (wallet ID, address, key share metadata). This differentiates it from sibling tools like 'create_wallet' (likely single-key) and other creation 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?

While the description implies this tool is for creating an MPC wallet, it does not explicitly state when to use it versus alternatives ('create_wallet', 'create_user_wallet'). No when-not-to-use or prerequisite conditions are mentioned, leaving the agent to infer usage from 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 must disclose behavioral traits. It confirms a write operation and return values, but lacks details on irreversibility, required permissions, failure modes, or effects on the ledger. Minimal behavioral context beyond the obvious.

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

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

Two sentences, no filler, all essential information (action, standards, return values) included efficiently. 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?

For a 6-parameter write tool with no output schema, the description mentions the return values but lacks information on error handling, validation rules (e.g., unique name), or how the standard affects behavior. Adequate but could be more 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 description coverage is 100%, so the schema already documents all 6 parameters well. The description only adds 'Supports ERC-721 and ERC-1155', which is implicit in the 'standard' parameter. Baseline 3 is appropriate as the description adds little 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 clearly states the action (create NFT collection), the platform (Tenzro ledger), supported standards (ERC-721/1155), and return value (collection ID and deployed address). This distinguishes it from sibling tools like list_nft_collections or mint_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 for creating collections but does not provide explicit guidance on when to use vs alternatives, prerequisites (e.g., need a creator address), or constraints like duplicate names. No exclusions or contrasts with similar tools.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. The description only names the action and protocols; it does not mention side effects (e.g., whether funds are committed, what a challenge entails), authentication requirements, idempotency, or error conditions. A creation tool should disclose more behavioral context.

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

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

Description is a single, focused paragraph with a front-loaded purpose statement and a bullet-like list of protocols. Every sentence provides essential information without waste. It is appropriately sized for the tool's complexity.

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

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

The tool has 5 required parameters and no output schema. The description adequately explains the protocols and their use cases, which is critical given the variety. However, it lacks information about return values (the challenge), error conditions, prerequisites (e.g., must the recipient be registered?), and any side effects. For a creation tool, more completeness is needed.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by elaborating on the 'protocol' parameter, explaining the meaning and ideal use for each of the five protocols, which helps the agent select the correct value. This extra context justifies a 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?

First sentence states specific verb+resource ('Create a payment challenge for a protected resource'), and the list of five protocols with use cases clearly distinguishes the tool from siblings like open_payment_channel or verify_payment.

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

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

The description provides context for each protocol's ideal use (e.g., 'ideal for per-token AI inference billing', 'ideal for API calls and data downloads'), which implies when to use each variant. However, it does not explicitly state when to use this tool versus other payment-related tools (e.g., open_payment_channel, verify_payment), nor does it include 'when not to use' guidance.

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

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

With no annotations, the description must disclose behavioral traits. It mentions the pre-stake requirement and return value, but lacks details on side effects, permissions, error handling, or transaction costs. This is adequate but not comprehensive for a mutation 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 brief (two sentences) and front-loaded with the primary purpose and key condition. Every word adds value without unnecessary elaboration.

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

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

Given no output schema, the description appropriately mentions the return value (proposal ID and status). It also notes the staked balance requirement. However, it could be more complete by describing error conditions or how to meet the stake requirement.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds no additional semantic detail about individual parameters, meeting the baseline expectation.

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) and the resource (governance proposal on Tenzro Network), and implies a specific outcome (returns ID and status). It distinguishes from sibling tools like list_proposals and vote_on_proposal by specifying 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 notes a key prerequisite (minimum staked balance), guiding the agent when to use the tool. However, it does not explicitly state when not to use it or name alternatives, leaving some ambiguity.

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

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

With no annotations, the description carries full burden. It discloses parallelism/sequentiality and member-spec spawning, but omits behavioral details like permissions, idempotency, side effects on existing agents, or resource implications. Provides some transparency but insufficient for a full understanding.

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 redundancy. Directly states purpose, key behavior (spawning, parallelism), and network context. Efficient 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?

Despite 5 parameters and no output schema, the description is brief. It omits details on return value, error handling, auth requirements, lifecycle management, and integration with siblings like 'terminate_swarm' or 'get_swarm_status'. Agent lacks key 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?

All parameters have schema descriptions (100% coverage), so the description adds marginal value. The 'members' param is clarified by the phrase 'Each member spec spawns one child agent', and 'parallel' is already described in schema. No additional semantics beyond what schema provides.

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

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

The description clearly states the action ('Create a swarm of coordinated agents') and identifies the resource ('under an orchestrator on the Tenzro Network'). It distinguishes from sibling tools like 'spawn_agent' by emphasizing coordination and orchestration, but does not explicitly contrast with alternatives such as 'spawn_agent_from_template'.

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 'spawn_agent' or 'terminate_swarm'. The description implies usage for creating a multi-agent swarm but offers no when-not or context cues.

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: it returns deployed address and ID, and the token is registered. However, it does not mention mutability, permission requirements, or side effects beyond registration. The destructive nature is implied but not explicit.

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 wasted words. It is front-loaded with the primary action and efficiently covers the outcome.

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

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

The description covers the core action and returns, but lacks detail on return format (no output schema) and behavioral constraints like signatures or VM-specific behavior. Given the tool has 9 parameters and no annotations, the description is adequate but not fully 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?

All 9 parameters have schema descriptions (100% coverage). The tool description does not add extra parameter-level context beyond what the schema provides. Therefore, it meets the baseline.

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

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

The description clearly states the verb 'create' and the resource 'ERC-20 token' via the Tenzro token factory. It also specifies key outcomes (returns address and ID, registration). This differentiates it from sibling tools like 'create_nft_collection' and 'mint_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?

There is no explicit guidance on when to use this tool vs alternatives. No comparisons to other token creation methods or prerequisites are provided.

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

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

No annotations are provided, so the description carries full burden. It mentions optional funding from the app's master wallet, which is a useful behavioral detail. However, it omits side effects (e.g., on-chain impact, permissions required, or whether the wallet is immediately active).

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 redundancy. It efficiently conveys the core purpose and option. However, it lacks structured sections (e.g., parameter details, examples) that could aid comprehension.

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

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

With no output schema and three parameters, the description is too minimal. It does not explain the return value, error conditions, or prerequisites (e.g., app existence). The optional funding behavior is mentioned but not elaborated.

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 covers all three parameters with descriptions (100% coverage). The tool description adds no additional meaning beyond the schema. 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 a user wallet under an application, with optional initial funding. It distinguishes itself from siblings like 'create_wallet' and 'fund_user_wallet' by specifying the app context and funding source.

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 explicit guidance on when to use this tool versus alternatives (e.g., 'create_wallet' or 'fund_user_wallet'). It implies usage for new user wallets under an app but lacks exclusion criteria or alternative suggestions.

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 bear the full burden. It states the keypair creation but does not disclose whether the keypair is returned, stored, or if additional steps are needed. Missing side-effect information.

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, no fluff. Could be improved by front-loading key actions, but acceptable 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?

No output schema exists, so description should clarify return value (e.g., keypair data). It does not mention result or prerequisites like authentication or storage.

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 repeats the same information about key_type options. No new semantic value added 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 creates a cryptographic keypair for a Tenzro wallet and specifies supported algorithms. However, it does not differentiate from sibling tools like generate_keypair or import_keystore, though the wallet context provides some distinction.

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 import_keystore or create_mpc_wallet. The description lacks explicit when/when-not context.

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

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

With no annotations, the description bears full responsibility. It discloses the output format (hex-encoded bincode-serialized Proof and public inputs with specific encoding) and the field type (KoalaBear), providing useful behavioral context beyond the input schema. However, it does not mention potential computational cost, latency, or side effects.

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

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

The description is two sentences: the first states the core action and scope, the second specifies the output format. It is front-loaded, concise, and contains no redundant information. Every sentence earns its place.

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

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

For a 2-parameter tool with no output schema, the description covers the input details and output format well. However, it could be more complete by mentioning whether the proof generation is synchronous or asynchronous, any performance expectations, or prerequisites like circuit existence. Overall, it is fairly complete but leaves some gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by enumerating the exact witness fields per circuit (e.g., inference requires model_checksum, input_checksum, computed_output), which is more detailed than the schema's generic description. This helps distinguish parameter usage across circuits.

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

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

The description explicitly states the tool's action ('Create a Plonky3 STARK proof') and specifies the resource ('one of three Tenzro AIRs'). It clearly distinguishes itself from sibling tools like 'verify_zk_proof' by focusing on creation, and provides distinct allowed circuit values ('inference', 'settlement', 'identity').

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 proving but does not explicitly state when to use this tool versus alternatives (e.g., verify_zk_proof for verification). It also does not mention prerequisites, such as circuit registration or field configuration. While the circuit options are listed, no guidance on selecting between them 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?

Discloses authorization requirement and return (burn event and nonce). No annotations provided, so description carries full burden; could mention idempotency, failure modes, or gas costs.

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

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

Three sentences, front-loaded with action. Each sentence adds critical info: purpose, restriction, process, and return. 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?

Describes core behavior and return, but lacks error conditions, prerequisites beyond authorization, or post-conditions. Adequate for a simple mutation, but could be more thorough.

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 description adds no new details beyond what the schema already provides for each parameter. Baseline 3 applies.

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

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

Clearly states it burns tokens for crosschain transfer (ERC-7802 crosschainBurn). References the return value, distinguishing it from siblings like crosschain_mint and 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?

Specifies that only pre-authorized bridges can call, and describes the burn-mint process. Does not explicitly list when to use vs alternatives, but context is sufficient.

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

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

No annotations are provided, so the description carries the full burden. It discloses the authorization requirement, the mint-after-burn process, and that it returns a mint event and nonce. It does not detail error cases or gas costs, but the core behavioral traits are clearly stated.

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-loaded with the main action. Every sentence adds essential information (what, restrictions, flow, output). No wasted words.

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

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

Given no output schema, the description mentions the return type (mint event and nonce). It does not explain event structure or error handling (e.g., what happens if bridge is unauthorized). Minor gaps, but overall sufficient for a mint function with clear parameters.

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?

With 100% schema description coverage, the baseline is 3. The description adds no new parameter details beyond what the schema already provides (e.g., 'Hex-encoded', 'base units'). The additional context about authorization is general, not parameter-specific.

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 'mint', the resource 'tokens via an authorized crosschain bridge', and references the ERC-7802 standard. It distinguishes from sibling tools like crosschain_burn and bridge_tokens by specifying the crosschain mint flow.

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 notes that only pre-authorized bridges can call this, and describes the flow (burn on source, mint on local). However, it could be improved by mentioning prerequisites like authorization via authorize_crosschain_bridge or when not to use this tool versus 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 alone must disclose behavior. It mentions atomic transfers via a precompile, indicating reliability. However, it omits details like gas costs, error handling, address format requirements (hex implied by schema), and whether the transfer is synchronous. Provides minimal but essential 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?

Two succinct sentences: purpose first, then technical detail and constraint. No redundant words. Front-loaded with the core action, making it easy for the agent to parse quickly.

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

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

Given the tool's complexity (6 params, no output schema, many siblings), the description covers purpose, mechanism, and token limitation. However, it lacks details on return value, error cases, and address format, which are important for execution. Adequate but not thorough.

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, so baseline is 3. The description adds that only TNZO is supported, which clarifies the 'token' parameter beyond the schema's 'Token symbol or 'TNZO''. This adds marginal value, but overall the schema already sufficiently describes parameters.

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

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

The description clearly states it transfers tokens between VMs (specific verb and resource), with an example (EVM to SVM). It distinguishes from sibling bridge tools by specifying cross-VM and using the cross-VM bridge precompile. The token limitation (only TNZO) adds precision, making the purpose unambiguous and differentiated.

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 like bridge_tokens or wormhole_bridge. It does not state prerequisites, when-not-to-use, or success/failure scenarios. The constraint 'Only TNZO is currently supported' hints at a limitation but does not guide the agent in tool selection.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states 'Returns transaction data ready for signing and submission,' but does not explain auth needs, rate limits, side effects, or whether the tool is idempotent.

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 the core purpose. No wasted words, though an additional sentence on usage would improve it.

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

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

Given the tool's complexity (7 parameters, 6 required) and lack of output schema or annotations, the description is minimal. It does not explain return format, error handling, or prerequisites like token approval.

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 with descriptions for all 7 parameters. The description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Create', resource 'cross-chain transaction', and context 'via deBridge DLN', distinguishing it from sibling tools like debridge_get_chains or debridge_same_chain_swap.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The context is implied but not 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 provided; description carries full burden. It implicitly indicates a read-only operation ('Get') but does not explicitly declare idempotency or safety. For a simple data retrieval tool, this is acceptable.

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 that front-loads the verb and resource. 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?

Tool has no parameters and no output schema; the description sufficiently explains what it does (list supported chains). No missing information for this simple 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 has zero parameters with 100% coverage; description adds no further parameter info. Baseline of 3 is appropriate as the schema already conveys all relevant details.

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

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

Description uses specific verb 'Get' and identifies resource 'blockchain networks supported by deBridge DLN'. Clearly distinguishes from sibling tools like `debridge_get_instructions` or `debridge_create_tx`.

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. While the purpose is clear, it does not mention exclusions or compare to other debridge tools, leaving the agent to infer 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 provided, and the description only indicates a read-like operation. It does not disclose side effects, permissions, rate limits, or what constitutes 'instructions'.

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, concise and front-loaded. Could benefit from slightly more structure (e.g., bullet points for guidance types), but remains 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?

Adeguate for a simple, parameterless tool. However, it lacks detail on what the instructions contain, limiting comprehensiveness 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?

Input schema has zero parameters, so schema coverage is 100%. Baseline of 3 is appropriate as the description adds no parameter context, but none is needed.

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

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

Description clearly states it retrieves deBridge operational instructions and guidance for cross-chain transfers, distinguishing it from sibling tools like debridge_create_tx or debridge_get_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 versus alternatives. The description implies its utility for getting instructions but does not specify prerequisites or exclusions.

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

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

No annotations provided, so description carries full burden. It lacks details on swap side effects, slippage, fees, or prerequisites like approvals. Only states basic 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?

Two sentences, zero waste, front-loaded. 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?

Tool is a financial swap with no output schema or annotations. Description fails to mention return values, error conditions, or safety measures like slippage, making it incomplete for safe usage.

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% parameters with descriptions, so baseline is 3. Description adds no extra meaning beyond what schema already provides.

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

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

Description clearly states 'Execute a same-chain token swap via deBridge' with specific verb and resource. It distinguishes from cross-chain bridging tools like bridge_tokens by highlighting 'same blockchain without cross-chain bridging'.

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?

Description implies usage for same-chain swaps but does not explicitly state when to use or avoid this tool compared to siblings. No alternatives or exclusions 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?

Annotations are absent, so the description must cover behavioral traits. It does not mention idempotency, rate limits, authentication requirements, or whether it's a read-only operation. The only behavior disclosed is 'returns' data, which is already obvious from the purpose.

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

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

The description is a single sentence of 12 words, yet conveys the core purpose and return information. No fluff or redundancy. It is front-loaded with the verb and resource.

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

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

For a simple search tool with two parameters, the description covers the basics. However, it lacks details about pagination, maximum results, search fuzziness, error scenarios, or full return structure. Given no output schema, more completeness would be beneficial for an agent to know exactly what to expect.

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?

Both parameters have descriptions in the schema (100% coverage). The description adds value by stating the tool returns 'token addresses, symbols, and supported chains', which clarifies the output schema and helps the agent understand the return format, even though no output schema is provided.

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

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

The description clearly states the tool searches for tokens on deBridge DLN and what it returns (addresses, symbols, chains). The verb 'search' and specific platform 'deBridge DLN' differentiate it from sibling tools like 'bridge_tokens' or 'debridge_create_tx'.

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. With over 100 sibling tools, including other token-related tools like 'list_tokens' or 'get_token_balance', the description does not specify when searching on deBridge is appropriate or when to use other 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, so description must carry burden. It discloses that it decodes and returns values, but does not mention side effects, error handling, or limitations (e.g., only EVM-based). Adequate but not detailed.

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 redundant 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?

No output schema, so description should explain return format. Only says 'returns decoded values' without structure. For a simple tool, this may suffice but lacks detail on return type, especially given no output schema.

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

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

Schema coverage is 100% with clear descriptions. Description essentially restates schema: 'hex-encoded return data and output type signatures'. Adds minimal extra value beyond schema.

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

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

Description clearly states verb (ABI-decode), resource (contract call return data), and useful for interpreting EVM responses. Distinguishes from siblings like encode_function or decrypt_data.

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

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

Says 'useful for interpreting EVM contract responses' but does not explicitly state when to use vs. alternatives or when not to use. No mention of prerequisites or edge cases.

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 must bear the burden. It discloses the algorithm and output format but omits error conditions, security implications, or whether the operation is idempotent.

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

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

A single, concise sentence (16 words) that front-loads the main action 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?

The description explains the return format (hex plaintext) but lacks depth on error handling, authentication tag verification, or relationships to sibling tools like encrypt_data.

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 parameter descriptions have 100% coverage, specifying hex encoding and byte sizes. The description adds minimal value beyond the schema, only mentioning 'key and nonce' generically.

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 'Decrypt', specifies the algorithm 'AES-256-GCM', lists required inputs (key, nonce), and defines the output format 'plaintext in hex'. This is specific and distinguishes it from sibling tools like 'encrypt_data' or 'seal_data'.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools involving cryptography, explicit usage context is lacking.

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 of behavioral disclosure. It mentions the return value ('delegation record and task ID') but fails to disclose authentication needs, side effects (e.g., task reassignment), or whether the delegation is reversible. 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 concise sentences front-load the core action and options, with no redundant information. 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?

Despite high schema coverage, the description omits behavioral context (e.g., required permissions, effect on original task) and does not address the complexity of delegation. The return format is vague ('delegation record'). With no output schema, more detail is needed.

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

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

The input schema already describes all 4 parameters (100% coverage), so the description adds limited value. It notes the budget parameter is optional and that the return includes a record and task ID, but the schema already covers types and descriptions.

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

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

The description clearly states the action ('Delegate a task'), the resource ('from one agent to another'), and the context ('on the Tenzro Network'). It also mentions the optional budget cap and return value, making the purpose specific and distinguishable from siblings like 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?

The description provides no explicit guidance on when to use this tool versus alternatives like assign_task or post_task. It does not specify prerequisites, scenarios, or exclusions, leaving the agent 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?

No annotations are provided, so the description must carry the full burden. It mentions the effect on TNZO stake and return of delegation record, but does not disclose whether delegation replaces existing delegations or what permissions are required. Gaps remain.

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

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

The description is only two sentences, front-loaded with the primary action, and contains 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 no output schema, the description states the return value. It explains the basic operation but lacks edge cases (e.g., if delegation is additive or replacement) and prerequisites. Still, it is largely complete for a straightforward delegation tool.

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

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

Schema coverage is 100% and parameter descriptions in the schema are already clear. The tool description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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

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

The description clearly states the verb 'delegate' and the resource 'governance voting power', and distinguishes from siblings like 'set_delegation_scope' and 'get_voting_power' by specifying the action of transferring power between addresses.

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 indicates when to use (to delegate voting power) but does not explicitly mention when not to use or provide alternatives. It provides clear context for the tool's purpose.

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

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

No annotations provided, so description carries the burden. It discloses that the operation frees disk space and returns confirmation, but does not detail error conditions (e.g., model not found) 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?

Three concise sentences front-loaded with the core action. No wasted 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?

For a simple 1-parameter tool with no output schema, the description covers the action, precondition, side effect, and return value. Missing only potential error handling or confirmation details.

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 parameter description is self-explanatory. The tool description reinforces the meaning of model_id but adds no additional nuance 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?

Description clearly identifies the action (delete), resource (model from local storage), and constraints (must not be serving). It distinguishes from sibling tools like list_models, download_model, serve_model_mcp, and stop_model.

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 the prerequisite that the model must not be currently serving, guiding the agent on when it is appropriate to call. Does not mention alternatives but the context is clear.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only mentions that it returns the deployed address, but omits critical details like gas costs, state mutability, authorization requirements, or potential failure modes for a write 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 sentences, 20 words, front-loaded with the verb 'Deploy'. Every word adds value with no filler. Excellent 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?

The description minimally covers purpose, supported VMs, and return value. Given the complexity of multi-VM contract deployment and no output schema, it lacks details on prerequisites, bytecode format expectations, or deployment results beyond the address. Adequate but not thorough.

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% with each parameter well-documented. The tool description does not add additional meaning beyond the schema, merely restating VM support. Baseline of 3 is appropriate.

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

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

Description uses specific verb 'Deploy' and names the resource 'smart contract to the Tenzro ledger'. It explicitly lists supported VMs (EVM, SVM, DAML), clearly distinguishing it from sibling tools like send_transaction or submit_daml_command.

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

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

The description states what the tool does but provides no guidance on when to use it versus alternatives or when not to use it. There are no exclusions or comparison to similar tools, leaving the agent to infer 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?

With no annotations, the description carries the burden. It states the algorithm and output format but omits details like salt usage, memory/time parameters, or deterministic behavior. It does however accurately reflect the core 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?

The description is two concise sentences (total 18 words) that instantly communicate the tool's action and result. No extraneous 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 cryptographic tool, the description lacks important context about salt handling, parameter defaults, and return format specifics (e.g., length of hex string). However, with a single parameter and clear output statement, it 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% and the schema description already explains the password parameter. The description adds no further parameter insights, so baseline 3 is appropriate.

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

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

The description clearly states the tool derives a 256-bit encryption key from a password using Argon2id KDF and returns it in hex. It distinguishes itself from sibling tools like hash_sha256 by specifying the algorithm and output purpose.

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 (e.g., hash functions). It does not mention security considerations or that Argon2id is suitable for key derivation, not password hashing.

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 adds key behavioral info: it returns detections with specific fields, and specifies that it is NMS-free for DETR-family models (sigmoid + score threshold). This goes beyond the input schema and helps the agent understand behavior, though it omits potential side effects or error conditions.

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

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

The description is two sentences with the main action front-loaded. Every sentence adds value—purpose, output format, and a key algorithmic detail. No redundant or extraneous words.

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

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

The tool is moderately complex (3 params, no output schema). The description explains the output structure but lacks context on possible errors, image format requirements, or performance implications. Without output schema, the return format description is helpful, but completeness is only 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%, so baseline is 3. The description does not add detail beyond the schema for model_id, image_base64, or score_threshold. It mentions score_threshold indirectly in the NMS context but does not elaborate on parameter usage.

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 runs object detection on an image and describes the output format (array of detections with bounding box, label_id, confidence). This distinguishes it from sibling tools like segment or list_detection_catalog, 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 does not provide guidance on when to use this tool vs alternatives (e.g., segment, transcribe). It lacks context on prerequisites (e.g., model must be available) and does not mention when not to use it. An agent receives no explicit decision support.

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 reveals that the tool returns a TEE type or simulation mode, but does not disclose side effects, permissions, or that it is read-only.

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 action, no fluff. Efficiently conveys purpose and return 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?

Description adequately covers what the tool does and returns for a simple detection tool, though lacks error/edge-case info; no output schema needed.

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

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

Schema has zero parameters (100% coverage), so baseline is 4; description adds no parameter info, which is acceptable.

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 'detect' and resource 'TEE hardware on this node', specifying return values, and distinguishes from siblings like 'get_tee_attestation' by focusing on detection.

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 when-to-use or alternatives guidance; usage is implied by the description but not compared to siblings like 'detect' or 'get_tee_attestation'.

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 the return fields (DIDs, capabilities, endpoints, reputation scores) but does not explicitly disclose behavioral traits like idempotency, safety, or side effects (though it's likely read-only).

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: the first clearly states the core function, the second adds filtering and output details. It is concise, front-loaded, and every sentence contributes.

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?

Though no output schema exists, the description lists what the tool returns (DIDs, capabilities, endpoints, reputation scores). It mentions filtering but omits details on pagination or limit defaults. For a simple discovery tool, 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% with descriptions for all parameters. The description reinforces the filtering purpose but does not add new meaning beyond the schema. Baseline of 3 applies because the description does not compensate for any 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 uses a specific verb 'Discover' and resource 'registered AI agents', clearly stating the tool's function. It also mentions filtering and return fields, distinguishing it from sibling tools like 'discover_models' and 'list_agent_templates'.

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 discovering agents with optional filters, but does not explicitly state when to use or avoid this tool, nor mention alternatives. Given the large sibling set, some guidance would help.

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 lacks detail on read-only nature, side effects, auth needs, or rate limits.

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

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

Two concise sentences, front-loaded with action and resource, 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?

Mentions return fields but omits pagination, sorting, or result limits; adequate for a simple discovery 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?

Adds semantic grouping ('serving status', 'max price') beyond schema descriptions, with 100% schema coverage.

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 discover AI models with filtering. However, does not explicitly differentiate from sibling list_models 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?

Implies use when filtering is needed, but gives no when-not-to-use or alternative comparisons.

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 that it creates a new agent identity and returns DID/wallet, but lacks behavioral details such as idempotency, side effects on the template, permissions required, or error scenarios.

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 convey the core action, outcome, and parameter hint. No unnecessary words. Front-loaded with the primary action.

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

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

The description covers the basic functionality and mentions return values (DID and wallet), which is helpful given no output schema. However, it omits details like error conditions, whether the template must exist locally, or relationship to other agent lifecycle tools. For a tool with no annotations and no output schema, some gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it confirms config_overrides are optional and used to override template config, but the schema already specifies this. No additional meaning is provided.

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

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

The description clearly states it downloads and instantiates an agent template, creating a new agent identity. It specifies the action, resource, and outcome (returns DID and wallet), distinguishing it from siblings like get_agent_template or run_agent_template.

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 agents from templates but does not provide explicit guidance on when to use this tool versus alternatives like spawn_agent_from_template or run_agent_template. No prerequisites or exclusions 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?

Discloses SHA-256 verification and return of status and progress, but lacks details on side effects (e.g., overwriting existing models), authentication requirements, or whether the operation is asynchronous. No annotations provided to compensate.

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 action, no wasted words. Efficiently conveys core functionality.

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

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

No output schema, so description should clarify return format. 'Returns download status and progress' is vague. Misses details on async behavior, error handling, and file locations, which are important for a potentially long-running download operation.

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 description. The description adds minimal value beyond the schema, only providing an example. Baseline score of 3 applies.

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

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

Description clearly states the tool downloads a model from specific registries to local storage with integrity verification. It distinguishes itself from sibling tools like 'list_models' and 'get_download_progress' by its core 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?

Description implies when to use (when a model needs to be local), but lacks explicit guidance on prerequisites or when not to use. No mention of alternatives like 'serve_model_mcp' or 'download_agent_template'.

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

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

No annotations provided, so description carries full burden. It only states the input/output behavior but does not disclose whether the operation is read-only, has side effects, or requires permissions. Minimal 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?

Three concise sentences with no redundancy. Each sentence adds value: purpose, input/output, usage context. Efficiently 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 output schema, description explains that output is hex-encoded calldata, which is helpful. Missing error cases or formatting details, but for a low-complexity tool it is fairly 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%, so baseline is 3. Description adds 'Solidity-style' context and mentions JSON array format, but largely restates schema info. Adequate but not exceptional.

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 ABI-encodes a function call for EVM, with specific verb 'ABI-encode' and description of inputs and outputs. Distinguishes from sibling encode/decode tools by focusing on function call encoding.

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 preparing EVM contract interactions but does not explicitly mention when not to use or provide alternatives. Could be improved by contrasting with other encoding tools.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not mention side effects (e.g., non-determinism due to random nonce), auth requirements, rate limits, or error behavior. It only states the operation and return values.

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. However, it could be slightly more structured (e.g., separate lines for purpose and output) to improve readability.

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

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

Given no output schema, the description mentions the return values, which is necessary. However, it does not explain the nonce role, support for additional authenticated data (AAD), or possible error cases. For a simple encrypt tool, this is minimally adequate but lacks depth.

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% with clear descriptions for both parameters. The tool description adds context about the return format (ciphertext and nonce in hex), which is helpful but does not go beyond what the schema already provides in meaning.

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 'encrypt', the resource 'data', and the algorithm 'AES-256-GCM'. It also specifies the output format (ciphertext and nonce in hex). This distinguishes it from siblings like decrypt_data, seal_data, and hash functions.

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

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

The description provides no guidance on when to use this tool versus alternatives such as seal_data or other encryption tools. There is no mention of prerequisites, when not to use it, or typical use cases.

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 output structure ({ registrationDataURI, owner }) and input format (hex-encoded), though no error conditions mentioned.

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, no wasted words, front-loaded with key action.

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

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

For a simple decode tool with one parameter and no output schema, the description adequately covers purpose and result structure.

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

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

The description adds no new detail beyond the input schema, which already describes the parameter. Schema coverage is 100%.

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 decodes return data from ERC-8004 getAgent() into specific fields, distinguishing it from encoding 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?

No explicit when-to-use or when-not-to-use guidance, but the context implies it's for decoding getAgent() return data.

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

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

With no annotations, the description fully relies on itself. It discloses deterministic behavior, the hashing algorithm, and domain separation, which gives good insight into the computation. However, it does not mention any side effects or response characteristics (e.g., error handling for invalid input).

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

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

The description consists of two concise sentences with no redundancy. It is front-loaded with the main action and efficiently adds the key detail about on-chain matching.

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

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

Given no output schema, the description does not specify the format or type of the derived agent id (e.g., hex string, bytes32). For a complete understanding, an agent would need to infer the output from the tool name and context. Lacks clarity on return value.

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 coverage is 100% with clear descriptions for both parameters (owner address, salt format). The description adds no additional semantic value beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'derive', the resource 'ERC-8004 agent id', and specifies inputs (owner address and salt) along with the hashing algorithm (keccak256 domain-separated). This distinguishes it from sibling encode tools and provides precise purpose.

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 on-chain computation by stating it matches the IdentityRegistry, but it lacks explicit guidance on when to use this tool versus alternatives like erc8004_encode_get_agent or other derive/encode tools. No direct comparison or conditionals provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the function signature and score range but omits the output type (encoded hex string) and any side effects. The description is factual but incomplete for a pure encoding 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, efficient sentence that front-loads the purpose and includes critical detail (score range). No extraneous words 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?

Despite having no output schema and no annotations, the description does not explain what the tool returns (e.g., ABI-encoded hex string). For a 4-parameter encoding tool, this omission significantly reduces completeness.

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

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

Schema coverage is 100%, with each parameter having a description that includes format and constraints (e.g., bytes32 hex, score 0-100). The description adds the function signature but no new meaning beyond the schema. Baseline 3 applies.

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

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

The description explicitly states the tool ABI-encodes an ERC-8004 ReputationRegistry.submitFeedback call with specific parameters, distinguishing it from siblings like erc8004_encode_register. The verb 'encode' and resource 'ERC-8004 call' are clear.

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

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

The description does not specify when to use this tool versus alternatives (e.g., other encoders or submitting feedback directly). Usage context is implied but not explicit; no '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?

With no annotations provided, the description fully carries the burden. It accurately describes the pure encoding operation and the return type, and no side effects or special behaviors are expected for this type of 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 14-word sentence that is front-loaded with the action and resource, containing 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?

For a simple tool with one parameter and no output schema, the description is nearly complete. It could explicitly state the output format (0x-prefixed hex), but the schema and overall context make it clear enough.

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

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

The input schema has 100% coverage and already documents the agent_id parameter as 'Agent ID (bytes32 hex, 0x-prefixed)'. The description adds no additional meaning beyond mentioning the function name, so it meets the baseline but does not exceed it.

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

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

The description clearly states the verb 'encode', the specific resource 'ERC-8004 IdentityRegistry.getAgent(agentId) call', and the output 'hex calldata'. It distinguishes itself from the sibling 'erc8004_decode_get_agent' by specifying encoding.

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

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

The description explains that the output is for 'an eth_call lookup', indicating off-chain use. It does not explicitly state when not to use it or list alternatives, but the purpose is clear enough for a specialized encoding tool.

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

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

No annotations are provided, so the description must supply behavioral context. It reveals the tool is a pure encoding operation (returns calldata, no side effects), but does not mention error handling, prerequisites (e.g., need for contract address), or any constraints. The output format is stated, but depth is limited.

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

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

The description consists of two concise sentences that immediately convey the tool's purpose, parameters, and output. No redundant information; each sentence adds value. Front-loaded with key action and resource.

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

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

Given the lack of output schema, the description explains the return value (hex calldata) adequately. It could be more complete by linking the output to downstream tools (e.g., sign_message or send_transaction) or mentioning that the calldata is ready for broadcast. However, the essence is sufficiently conveyed for an agent familiar with EVM interactions.

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 all three required parameters with descriptions, achieving 100% schema coverage. The description merely lists the same parameter names without adding extra meaning or usage nuances (e.g., format of registrationDataURI). 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 action (ABI-encode), the specific contract function (ERC-8004 IdentityRegistry.register), and the output (hex calldata). It explicitly lists the three parameters, which distinguishes it from sibling encode tools that target different functions.

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

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

The description indicates the output is for signing/broadcasting on any EVM chain, implying use cases like preparing transactions. However, it does not compare against other encode tools (e.g., erc8004_encode_feedback) or provide when-not-to-use guidance, leaving the agent to infer context 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?

The description states it returns hex calldata, which implies a pure computation with no side effects. However, without annotations, it could explicitly mention that it is a read-only, stateless operation to aid agent understanding.

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 short sentences) and immediately states the purpose and output. No unnecessary words or repetition.

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

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

For an encoding tool with no output schema and no annotations, the description covers the essential aspects: what function is encoded, parameters, and output format. Could mention that the output is Ethereum-compatible calldata, but the current text is sufficient.

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

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

The schema provides 100% coverage with descriptions for all parameters. The description adds value by linking the parameters to the function signature and clarifying their order, which is not explicit in 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's action: ABI-encode a specific ERC-8004 function call. It names the function (requestValidation) and lists its parameters, distinguishing it from other encode tools in the sibling list.

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 other encoding tools like erc8004_encode_register or erc8004_encode_submit_validation. The context of usage is only implied by the function name.

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 should disclose behavioral traits. It does not mention that this is a pure encoding function (no state mutation), nor any security or prerequisites. The description is insufficient for an agent to understand side effects or requirements.

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

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

The description is concise with two sentences, no redundant information. It is appropriately front-loaded and easy to read, though it could be slightly more 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?

Given no annotations and no output schema, the description is incomplete. It does not explain the return value (ABI-encoded bytes) or any necessary context like contract address invocation. An agent would lack critical information to use the output 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?

With 100% schema description coverage, the baseline is 3. The description adds some context by stating that response is a quality score (0-100), but this partly contradicts the schema's 0-255 range. It does not significantly enhance understanding 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 specifies that the tool ABI-encodes a ValidationRegistry.submitValidation call and lists the parameters. However, the mention 'Response is 0-100 quality score' slightly contradicts the schema which allows 0-255, causing minor confusion. It distinguishes from sibling encode tools by naming the specific function.

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 any guidance on when to use this tool versus other erc8004_encode_* siblings, nor does it mention exclusions or prerequisites. It only states its function without 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, so the description carries full burden. It discloses key behaviors: subset enforcement by AS, rejection of over-scoped requests, act-chain extension, and child token's controller_did. This goes beyond typical descriptions, though it lacks error details and side effects.

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

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

The description is concise (a few sentences) and front-loaded with the RFC reference. Each sentence adds value, though it could be slightly more 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?

No output schema is provided, but the description does not mention the return value (the child JWT). This is a missing piece for an agent to know what to expect. However, the tool's complexity is well covered otherwise.

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

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

Schema coverage is 100%, so the baseline is 3. The description provides context about subset relationships and enforcement, but does not add significant meaning beyond the schema's parameter descriptions.

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

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

The description clearly names 'RFC 8693 OAuth 2.0 Token Exchange' and states the specific action: mint a narrower child JWT from a parent JWT with a different DPoP key and subset of grants. This distinguishes it from sibling tools like introspect_token and others.

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

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

The description explains when to use (to create a child token with subset of permissions) and implies when not (over-scoped requests are rejected). It provides clear context but does not explicitly mention alternative sibling tools.

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