Robyn — Gasless Cross-Chain for AI Agents

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

No annotations are provided, so the description must disclose behavior. It states 'Free, read-only, moves nothing,' which confirms no side effects. However, it does not mention error handling, rate limits, or auth requirements, leaving some gaps.

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

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

The description is two sentences long, directly stating purpose and read-only nature. Every word is necessary and no extraneous information exists. It is optimally concise.

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

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

Given the tool's complexity (2 params, nested object), no output schema, and no annotations, the description covers verification behavior and read-only safety. It lacks details about return values or failure modes, but is largely complete for an agent to understand its function.

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 parameters. The description adds minimal extra meaning (e.g., 'recovers the expected account' hints at output), but does not significantly enhance understanding beyond what the 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 tool's purpose: verifying a signed EIP-7702 authorization tuple by recovering the expected account and checking nonce. This is specific to a well-defined task and distinguishes it from sibling tools like robyn_7702_delegate or robyn_sponsor_7702.

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

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

The description implies usage for verifying authorizations and notes it is free and read-only, but does not explicitly state when not to use it or mention alternatives. Without exclusions, guidance is adequate but not thorough.

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 only declares 'Read-only,' missing other behavioral traits like idempotency, response format, or data freshness. Minimal extra value beyond the read-only hint.

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

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

Two sentences with zero waste. Information is front-loaded and directly addresses the tool's purpose without extraneous text.

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

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

For a zero-parameter info tool with no output schema, the description fully explains the return values (address per chain, ABI, EIP-712 scheme) and notes the read-only nature. Complete given the tool's simplicity.

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

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

No parameters, so baseline is 4. The description adds context about what the tool returns (address, ABI, schema), compensating for absence of output schema. No param-related confusion.

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 provides the canonical delegate address, ABI, and EIP-712 scheme for EIP-7702. It specifies the scope (22 EVM chains) and distinguishes from siblings by focusing on static delegate info.

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

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

The description implies usage for delegation and sponsored transactions ('Delegate to this and the relayer can sponsor your transactions'), but lacks explicit when-to-use or alternatives compared to siblings like robyn_sponsor_7702.

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

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

With no annotations, the description fully discloses behavioral traits: the output is a 'RECORD, not a guarantee', may be stale ('does not promise the same capability a minute later'), and the signature does not imply an SLA. It also clarifies the meaning of `notServiceable`. This is substantial transparency beyond any possible annotation.

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

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

The description is front-loaded with the core purpose, then layered with usage instructions, field clarification, and limitation caveats. Each sentence earns its place: the field emphasis, the fallback explanation, and the non-SLA disclaimer are all necessary for correct use. No fluff.

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

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

Despite having no output schema and no annotations, the description provides a comprehensive picture: what the tool returns (capability categories), how to use the key field (`serviceableNow`), what `notServiceable` contains, and critical caveats (not a guarantee, may change). This is sufficient for an agent to decide when to call it and how to interpret results.

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

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

The tool has zero parameters, so the schema offers no parameter details. The description compensates by explaining output fields like `serviceableNow`, `policyEligible`, and `notServiceable`, adding semantic meaning even though these are not parameters. A 4 is appropriate given the baseline for zero parameters.

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

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

The description clearly states the tool produces 'a signed, timestamped record of current capability' and enumerates exactly what it covers (chains payable now, policy-eligible chains, execute-ready rails, delivery estimation). This goes beyond a simple verb+resource and clearly distinguishes it from sibling tools like robyn_quote or robyn_preflight by focusing on current operational capability.

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?

Explicit guidance is given: 'USE serviceableNow, NOT policyEligible, when deciding where to send funds' with a concrete explanation of why (policy eligibility may not reflect inventory). It also instructs to 'Fetch this BEFORE committing to a multi-step plan' and explains the evidence value. This is direct, actionable usage context.

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

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

With no annotations, the description bears full responsibility. It explains the behavior: returns a payload to sign, the server does not hold the key, and the relayer broadcasts on submission. It lacks details on error handling or rate limits but is transparent about the core workflow and security.

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 deliver essential information efficiently. The most critical action ('Plan a gasless cross-chain move') is front-loaded, and every sentence adds value without redundancy.

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

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

Given the tool has 6 parameters, no output schema, and no annotations, the description covers the overall purpose and workflow adequately. It lacks detail on the returned payload structure and error scenarios, but the presence of sibling tools like 'robyn_route_status' may cover status tracking.

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

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

Schema coverage is 50% with only three parameters described in the schema. The description adds no additional meaning or context for any parameters, missing an opportunity to clarify formats (e.g., chain IDs as numbers or strings) or the optional 'toAddress' field.

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 plans a gasless cross-chain move and returns a payload to sign. It distinguishes itself from siblings by referencing 'robyn_submit' for submission, making the purpose specific and unambiguous.

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

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

The description provides a sequential workflow: call this, sign the returned payload, then call 'robyn_submit'. It also notes the server never holds the key, which is a key usage caveat. However, it does not explicitly exclude other sibling tools or state when not to use this tool.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral caveat: below a sample threshold, the figure is a static estimate marked 'insufficient-data', not a measurement. It also instructs users to say which one they are quoting. This is strong, but it does not fully describe the return format or other edge cases, so a 4 is appropriate.

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

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

The description is two sentences, each well-chosen. The first states the primary function, and the second delivers a critical caveat and user guidance. There is no fluff or redundancy, and all content earns its place.

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

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

Given no output schema or annotations, the description covers the core purpose and the crucial reliability caveat (insufficient-data vs. estimate). It could be slightly more explicit about the successful output shape (e.g., fields and units), but for a simple read-only stats tool, it is reasonably complete. A 4 reflects this minor gap.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. The mention of 'basis' and 'status' likely refers to fields in the output rather than inputs. With 0 parameters, a baseline score of 4 applies, and the description does not need to explain parameter details.

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

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

The description clearly states what the tool does: it provides actual measured settlement delivery times per rail and per corridor, contrasting with a single advertised constant. This distinguishes it from sibling tools and specifies the resource and scope. The implicit verb (e.g., 'returns'/'provides') is clear from context.

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

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

The description gives clear context: use this when you need real measured times rather than advertised constants. It also tells users to check basis/status and to distinguish between measurements and estimates. However, it does not explicitly name alternative tools or provide exclusion criteria, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns error codes, retryability, and recovery actions. There is no contradiction with annotations. It provides clear behavioral context for a read-only reference 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 extremely concise: two sentences that convey all necessary information without any wasted words. It is front-loaded with the key purpose and includes actionable advice.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description fully covers its purpose and behavior. It tells the agent exactly what data to expect and how to use it (branch on errorCode). This is complete for a reference tool.

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

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

The tool has zero parameters (schema coverage 100%). The description adds meaning by explaining what the tool returns (error taxonomy), which is valuable beyond the empty schema. Baseline for 0 parameters is 4, but the description is exceptionally clear about the output content.

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 that the tool provides 'the full error taxonomy: every errorCode, whether it is retryable, and the suggested recovery action.' This is a specific verb-resource pair and distinguishes it from sibling tools which perform actions like check, delegate, submit, etc.

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 includes explicit guidance: 'Read this once and branch on errorCode instead of parsing messages.' This tells the agent exactly when and how to use the tool. However, it does not explicitly state when not to use this tool or provide alternatives, but given it's a reference tool, the guidance is sufficient.

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

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

With no annotations provided, the description carries the full burden, and it excels: it discloses the signature integrity (swapping components invalidates), the verdict being the weakest of its parts, the meaning of 'undetermined' (not verified), and the presence of 'unavailable' components with reasons and the 'incomplete' check. These behaviors are critical for correct use and go far beyond what a schema could convey.

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

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

The description is information-dense but every sentence earns its place: the component list, the signing property, the verdict warning, and the unavailable/incomplete note. It is front-loaded with the most important content and flows logically from what the tool produces to how to interpret it, without redundancy.

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

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

Given no output schema, the description effectively explains the return semantics: what components the bundle contains, how to interpret the verdict (including the dangerous 'undetermined' case), and how missing components are signaled. It also covers the signature invalidation constraint, making the description complete enough for an agent to safely invoke and present the tool's output.

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

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

The input schema has 100% parameter coverage, so the baseline is 3. The description does not add parameter-specific meaning, but it doesn't need to because the schema already describes 'id', 'minAmount', and 'recipient' adequately. The description focuses on the tool's output and interpretation, not on parameter details.

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

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

The description opens with 'Assembles EVERYTHING about a settled transfer in one call' and explicitly enumerates the components (on-chain verification, fee breakdown, alternative route cost, delivery time), making the tool's purpose unmistakable. It also distinguishes itself as 'the artefact to hand to a principal who was not there', differentiating it from simple verification or query 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?

It clearly states when to use it: to present evidence to a principal who was not present. It adds a strong procedural instruction ('READ verdict BEFORE PRESENTING IT') and explains what to do if verdict is undetermined. However, it does not explicitly name alternative tools or state when not to use it, so it lacks the explicit exclusion/alternatives of a 5.

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 burden of behavioral disclosure. It explicitly states that unattributable amounts are returned as `unattributed` rather than being folded into other lines, and instructs the user to report this field instead of treating the breakdown as complete. This is meaningful behavioral context beyond a generic description, though it does not detail auth requirements or error handling.

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 and front-loaded with the primary action ('Reconstruct a settled transfer unit by unit'). The second sentence provides valuable guidance about the `unattributed` field without unnecessary fluff. 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 single-parameter tool with no output schema, the description provides sufficient context: it explains the purpose, the types of breakdown lines, and the special handling of unattributeable amounts. It does not discuss error cases or return format details, but these are less critical for this simple forensic tool. The description is complete enough for an agent to know what to expect and how to handle edge cases.

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

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

The input schema covers the single parameter `id` with the description 'settled transfer id', and the tool description echoes 'settled transfer' but adds no new detail about the id's format, source, or validation. Given 100% schema coverage, the baseline is 3; the description adds no meaningful parameter-level semantic value beyond what the schema already provides.

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

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

The description clearly states the tool's purpose with a specific verb ('Reconstruct') and resource ('a settled transfer unit by unit'), and enumerates the output categories (destination payout gas, Robyn margin, subsidy). This makes it distinct from sibling tools like robyn_netting_statement, which focus on statements rather than forensic breakdowns.

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

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

The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives. It does not mention when not to use, what prerequisites exist, or how it compares to sibling tools. The only implicit cue is that it applies to settled transfers, but no clear decision framework is given.

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

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

Without annotations, the description carries the full burden. It clearly states what the tool lists and that it requires no credentials, implying a safe, read-only operation. It does not disclose rate limits or output format, but for a simple list tool this is adequate.

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

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

Two short sentences convey the full purpose and a key usage detail. No filler or repetition. The critical information is front-loaded.

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

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

Given the tool has no parameters and no output schema, the description sufficiently covers its function. It would benefit from briefly noting the return format (e.g., JSON array), but this is a minor gap.

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

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

The tool has zero parameters, so the description cannot add parameter-level detail. The lack of parameters is correctly reflected in the schema, and the description confirms no credentials are needed.

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

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

The description explicitly states the tool lists specific resources: Robyn gasless chains, cross-chain route graph (22 EVM nodes + Stellar), and relayer/Permit2 addresses. This clearly differentiates it from sibling tools like robyn_cross_chain or robyn_quote.

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

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

The description includes the important usage note that no credentials are needed. However, it does not specify when to use this tool versus alternatives like robyn_cross_chain, nor does it mention any prerequisites or limitations.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only and explains the edge case for addresses that never enrolled (reported as not custodied). It does not detail error behavior or output format, but for a simple query this is reasonably transparent.

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

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

The description is two sentences, front-loads key information, and includes the critical MUST-use note about nextNonce. Every sentence earns its place with no wasted words.

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

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

Given the tool has one parameter and no output schema, the description adequately covers the main output concepts (enrolment, balance, history, nextNonce) and an important edge case. It could be more explicit about the return format, but it is sufficient for selecting and invoking the tool 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?

The input schema has full coverage (100%) for the single 'address' parameter, with a description 'EVM address (0x…)'. The tool description does not add extra parameter-level semantics beyond reusing the term 'address', so the baseline 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?

The description clearly states that the tool reports enrolment state, internal balance, recent history, and nextNonce for an address. It is specific about the resource (netting account) and the operation (query/report), though it lacks an explicit verb and does not directly distinguish itself from sibling tools like robyn_netting_info.

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

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

The description gives clear context: the tool is for checking whether an address is enrolled and for obtaining the nextNonce that MUST be used when signing transfers or withdrawals. It does not explicitly state when not to use it or name alternatives, but the usage context is strong.

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 responsibility for behavioral disclosure. It reveals that the tool does not actually enroll anyone, does not hold keys, and that the resulting balance is custodial, uninsured, and 'could be lost.' This goes far beyond the name/schema and is essential context for the agent.

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 compact yet information-dense, starting with the primary purpose and then adding essential workflow and risk warnings without redundancy. Every sentence earns its place, and the structure front-loads the most important information.

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

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

For a one-parameter tool with no output schema, the description is self-sufficient: it explains what the tool returns, how to use it, and the critical custodial risks. It also provides the follow-up endpoint, making the entire flow clear.

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

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

The schema description already fully documents the single parameter 'address' as 'the address that will own the netting account.' The description adds no additional parameter-specific semantics beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool 'Returns the EXACT message the account must sign with its OWN key to open a custodial balance.' It distinguishes itself from sibling tools by explicitly noting it 'holds no key and enrols nobody,' making it unambiguous that this is a payload-generation tool rather than an enrollment 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?

The description provides a complete usage workflow: get the text, user signs it, then POST {address, signature} to /api/netting/enroll. It also gives critical guidance on when to use this tool (before enrolling) and contrasts it with other tools by highlighting that 'every other tool here moves funds without Robyn ever holding them.'

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

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

With no annotations, the description fully discloses behavioral traits: read-only, custodial (holds balance), and specific return values. The custodial warning is critical and clearly stated, providing complete transparency for a zero-annotation 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?

Four sentences packed with essential information: first explains the netting mechanism, then custodial risk, then read-only behavior and outputs. Every sentence earns its place with no redundancy.

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

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

The description thoroughly covers the concept, security implications, and return values, making it self-sufficient for an informational tool. It gives enough context for an agent to know when to call and 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?

Input schema has zero parameters, so the description adds no parameter-specific meaning. Baseline for 0-param tools is 4, and the description does not need to elaborate on parameters.

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

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

Description clearly states the tool's purpose with verbs 'Explains' and 'Returns,' identifying it as an informational resource about the netting ledger. It distinguishes itself from sibling action tools by focusing on explanation of caps, limits, and fee 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?

Provides clear usage context by instructing to 'Tell the user that plainly before they enrol,' indicating use before enrollment. It contrasts with other tools that move funds, implying this is for education rather than execution, though it lacks explicit alternative names.

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. It discloses that the tool is free and read-only, explains the significant cost differences (over 1000x), and clarifies that internal transfers are unaffected. This goes beyond basic safety and gives useful behavioral context, though it does not describe the exact output format or error handling.

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 (~80 words), front-loaded with 'Free and read-only,' and every sentence serves a purpose: explaining the ranking, cost disparity, single-chain option, and internal transfer exception. It is well-structured and avoids redundancy.

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

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

For a simple two-parameter preview tool, the description adequately covers purpose, behavior, and edge cases (internal transfers). It mentions that toChain can indicate success, and the ranking implies a return list. It does not specify the exact response structure, but no output schema exists and the tool is straightforward, so this is acceptable.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds some contextual framing (e.g., amount is for the withdrawal, toChain limits to a single chain) but does not provide substantive new meaning beyond what the schema already states. Hence the 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's function: given an amount, it ranks every exit chain by what actually arrives after destination payout costs. This is a specific verb+resource+scope combination that distinguishes it from sibling tools like robyn_netting_transfer_payload or robyn_cross_chain, which handle actual movements rather than previews.

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 provides clear context: use to preview netting withdrawals, and pass toChain to price a single chain. It also gives an explicit when-not-to-use: internal transfers between netting accounts are free and not subject to these costs. However, it does not explicitly name alternative tools for those cases, so it falls short of a 5.

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 explicitly states 'Read-only' and describes the safety mechanism of refusing deposits that would push liabilities above a safe share. It also notes that solvency is checkable, adding behavioral insight beyond the bare function.

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

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

The description is three sentences, each with a distinct value: what it publishes, the solvency guarantee, and the read-only usage scenario. Every sentence earns its place with no wasted words.

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

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

For a zero-parameter tool, it covers the key aspects: purpose, scope, read-only safety, and a concrete user scenario. It does not detail the exact return format, but the description gives enough context for expected data (liabilities vs float per chain), making it reasonably 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?

With zero parameters, schema coverage is trivially 100%. The description adds scope context ('all netting accounts', 'per chain') that enriches the empty schema. The baseline of 4 for no parameters is appropriate and the added context justifies it.

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

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

The description uses the specific verb 'publishes' and clearly identifies the resource: what Robyn owes against the real relayer float per chain. It distinguishes itself from sibling netting tools by focusing on solvency/proof rather than account info or transfers.

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

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

It provides a clear usage context: 'a user considering a custodial balance should be shown this.' It also emphasizes read-only nature, implying it's for verification rather than action. No explicit alternatives are named, but the context gives sufficient 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 provided, the description carries the full burden and does so excellently. It discloses that internal transfers have no transaction hash, that the journal is append-only and never truncated, and that paging uses a `before` sequence number. These are critical behavioral traits beyond what the schema reveals.

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

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

The description is three dense sentences, front-loaded with the most important fact (no transaction hash), and every sentence earns its place. It efficiently covers purpose, behavioral traits, and usage context without fluff.

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

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

Given the tool's simplicity (a history list), lack of output schema, and absence of annotations, the description provides all necessary context for an agent to select and invoke it correctly. It covers the 'why' (verify/dispute internal payments), the 'what' (full untruncated history), and the 'how' (paging with `before`).

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 meaningful semantics for the `before` parameter by explaining it is a seq number for paging and emphasizing that the tool never truncates results, which enriches the schema's bare 'return entries with seq below this'.

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 provides the full, untruncated netting history for an address, and explains that it records internal transfers with no transaction hash. This clearly distinguishes it from sibling netting tools by emphasizing it is the only record for such transfers.

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

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

The description gives a clear when-to-use directive: 'Use this when a user asks to verify or dispute an internal payment, since there is no chain to check.' It also provides paging guidance with `before`, making the invocation context explicit.

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

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

With no annotations, the description bears full responsibility for disclosing behavior. It notably states 'Signs nothing and moves nothing' and emphasizes that Robyn will not hold a balance for a recipient who never consented, which are critical behavioral traits. It does not mention possible errors when nonce retrieval fails or when accounts are not enrolled, but the explicit safety and consent constraints are well covered, justifying a strong 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 extremely concise yet information-dense: three sentences cover the exact return value, the workflow (sign and POST), the enrollment prerequisite, and an alternative for unenrolled recipients. There is zero fluff, and the most critical detail (what it returns) is front-loaded. 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?

Given the tool's complexity (simple payload builder with 3 parameters, no output schema) and the rich sibling context, the description is remarkably complete. It explains the return value, the subsequent action required, the enrollment condition, and the alternative route. It effectively differentiates from robyn_netting_enroll_payload and other robyn_* tools without needing to enumerate all siblings.

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 the parameters. The tool description adds meaningful context beyond this: it clarifies that the 'to' and 'from' must be enrolled accounts, and reveals that the nonce is automatically handled ('with the correct next nonce') and that the final POST includes a 'signature' field, none of which are in the input schema. This enriches the agent's understanding of how the parameters relate in the workflow.

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 function with a specific verb and resource: 'Returns the exact string to sign, with the correct next nonce, for a free instant transfer between two ENROLLED accounts.' It distinguishes itself from siblings by explicitly noting it 'Signs nothing and moves nothing' and by referencing the exact endpoint and POST payload. This makes it unambiguous which action the tool performs.

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 usage context and alternatives: it explains that the sender must sign the returned message and POST it to /api/netting/transfer, and it clearly states the prerequisite that both parties must already be enrolled. It also gives a direct alternative: 'to pay an unenrolled address use the ordinary non-custodial route instead.' This goes beyond merely implying when to use the tool.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It clearly states that Robyn does not sign, holds no payee keys, and returns a digest for the payee to sign, which is a critical counterintuitive behavior. It also explains the rationale. However, it does not mention whether the request is stored, expiration handling, or error scenarios, so it's not fully exhaustive.

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 action ('Build a canonical payment request') and immediately states the key output and signing requirement. It includes a useful rationale without any fluff. 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?

Given no output schema and no annotations, the description does well to explain the process, the signer, and the return value (digest). It also situates the tool within the payment request workflow. However, it could be more complete by mentioning what happens after signing or how the digest is used, though that is likely covered by 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 50%, meaning memo, token, and expiresInSec lack schema descriptions. The tool description lists all parameters (payee, chain, token, amount, memo, expiry) but adds little beyond their names. It doesn't clarify formats, defaults, or relationships (e.g., what 'expiry' maps to, token representation). This is adequate but not compensatory for the undocumented fields.

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 builds a canonical payment request and returns a digest for the payee to sign. It distinguishes itself from siblings like robyn_payment_request_settlement and robyn_payment_request_verify by focusing on the prepare step, and explicitly clarifies that Robyn does not sign these requests.

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 when-to-use guidance: 'Use this when an agent needs to ASK another agent for money in a way the payer can actually check.' It also implicitly explains when not to use it (when Robyn should sign) by stating Robyn doesn't sign and holds no payee keys, effectively differentiating from signing/verification 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?

With no annotations provided, the description fully carries the behavioral burden. It discloses the verification logic, the meaning of paid=true (verified on-chain result) and paid=null (undetermined, not evidence), which is crucial for correct interpretation.

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 'After paying, prove it', and every sentence adds necessary behavioral insight. No redundant or filler content.

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 adequately covers the core purpose and primary return semantics (paid=true/null), but with no output schema it does not fully explain the complete response shape or the role of request/signature parameters. It is usable but has gaps for a 3-parameter tool with nested objects.

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 only 33% (only transferId has a description). The description adds no explicit meaning for the 'request' object or 'signature' string, and only indirectly relates to the transfer via the transferId. It does not compensate for the schema gaps.

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

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

The description clearly states a specific verb and resource: 'prove it' by re-checking the transfer against the DESTINATION CHAIN and confirming the payee was paid. It differentiates from siblings by emphasizing on-chain verification and the payee amount requirement.

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

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

Provides clear context: 'After paying, prove it' indicates when the tool should be used. However, it does not explicitly mention alternatives or when not to use it, which would fully distinguish it from sibling tools like robyn_payment_request_verify.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool's security checks, the meaning of a valid signature, and the critical risk of altered payee addresses. It also clarifies what a signature does NOT prove, which is valuable behavioral context.

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

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

The description is compact yet information-dense, front-loaded with the imperative 'ALWAYS run this before paying'. Every sentence adds value, covering purpose, use, and critical warnings without redundancy.

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

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

The description thoroughly explains the tool's role and the key decision outcome (signedByPayee false → do not pay). However, since there is no output schema, it does not explicitly describe the return format or error behavior. While not fully complete in this respect, the essential behavioral outcomes are covered.

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 meaning by explaining that the signature parameter proves authenticity and that the request is checked for specific fields (payee, chain, token, amount, expiration). This enriches the reader's understanding of how the parameters are used.

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' and the resource 'payment request', and specifies exactly what it confirms (payee address, chain, token, amount, signature, expiration). It differentiates from siblings by mandating this step before paying and explicitly distinguishing between authenticity and whether payment is owed.

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

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

The description gives explicit when-to-use ('ALWAYS run this before paying a request you received') and a strong when-not-to-pay condition ('If signedByPayee is false, DO NOT PAY'). It also warns about address substitution, providing actionable safety 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 provided, the description fully discloses important behavioral traits: it is READ-ONLY, stops at the first unroutable step, reports cumulative fees/durations, and returns binding-constraint feedback. This goes well beyond a minimal safety annotation.

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

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

The description is front-loaded with the primary purpose, then covers termination behavior, output feedback, read-only safety, and usage guidance—all in five targeted sentences. No sentence is redundant or filler.

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

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

Given the tool's complexity, nested parameters, and lack of an output schema, the description covers the essential behavior, safety, and response structure. It does not enumerate all constraint fields or explicitly compare with sibling tools, but it is still strongly complete.

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

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

The schema provides basic descriptions for 'steps' but not 'constraints'. The description adds meaning by explaining that fees and durations accumulate across steps and that error responses include 'bindingConstraint' and 'whatWouldMakeThisWork', which helps the agent understand constraint evaluation and output semantics.

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 entire multi-step workflow up front, using a specific verb ('Validate') and resource ('a WHOLE multi-step workflow'). This directly distinguishes it from per-hop validation tools like robyn_preflight or robyn_quote.

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

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

The description explicitly says to 'Use this before spending on step one' and positions it as an alternative to validating 'one hop at a time.' It provides clear contextual guidance, though it does not explicitly name sibling tools 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 provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'Read-only — signs nothing, moves nothing,' clearly setting safety expectations. It also lists the exact failure modes it detects (fee consumption, address family, settle capability, lane capacity), providing a detailed behavioral model beyond what annotations would offer.

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

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

The description is three sentences, starts with actionable direction, then explains the return type and key failure modes, and ends with a critical safety trait. Every sentence earns its place with no redundancy or filler.

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

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

Despite lacking an output schema and annotations, the description is complete: it covers purpose, workflow position, output shape (GO/NO_GO with blockers and warnings), specific failure modes, and safety behavior. This is sufficient for an agent to invoke the tool correctly across its seven 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?

Schema description coverage is 86%, so the schema already documents most parameter meanings. The description adds a usage note about fromAddress for 'free micro-transfers,' but this overlaps with the schema's existing 'membership and fee tier' description. Overall, the description adds only marginal parameter-level value beyond the schema.

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

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

The description clearly identifies the tool as a preflight check that returns GO/NO_GO with blockers and warnings, and explicitly names robyn_prepare/robyn_submit to distinguish its role in the workflow. It enumerates specific failure modes it catches, making the purpose unambiguous and well-differentiated from 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?

The opening sentence 'Run this before robyn_prepare/robyn_submit' gives explicit sequencing guidance. The description further explains the value (catches costly failures for free) and offers a parameter-specific tip about fromAddress for membership recognition, which helps the agent decide when and how to use it.

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

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

No annotations are provided, so the description carries the burden. It discloses the tool is non-destructive and does not require keys, but lacks details on rate limits, auth requirements, or error handling. The return statuses are partially explained.

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, no wasted words. The core purpose is front-loaded, followed by behavioral note and return info. 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?

With 7 parameters, no required, and no output schema, the description gives a high-level view but lacks detail on parameter interactions or full return structure. It is moderately complete for a first glance but insufficient for complex 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 coverage is 57% (4 of 7 params described). The description adds context that input can be plain language or structured, aligning with the 'intent' param, but does not elaborate on other params like toChain or fromChain. Baseline 3 is appropriate given moderate 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?

The description clearly states the tool converts an intent into a concrete plan and the exact payload to sign. It mentions return statuses ('sign' or 'quoted'), distinguishing it from sibling tools like robyn_quote or robyn_submit.

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 safe usage with 'Costs nothing, moves nothing, needs no key' but does not explicitly state when to use this tool versus siblings like robyn_quote for quotes or robyn_submit for submission. No direct alternatives 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?

No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('moves nothing') and reveals a critical behavioral nuance: the quoteOnly field indicates whether the route is executable, with detailed instructions on how to interpret and present it. This is exemplary transparency beyond typical tool descriptions.

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 five sentences, front-loaded with the primary purpose, then the essential behavioral caveat. It uses bold and uppercase for the critical part, making it scannable. 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 a quote tool with no output schema, the description covers everything needed: return fields, read-only behavior, the quoteOnly exception, its reason, and the default executable status. This fully equips the agent to correctly interpret and present the tool's response in all cases.

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 provides complete descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema, which is acceptable given the schema's thoroughness.

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 function: 'Best gasless route to move a token from one Robyn chain to another' and lists the returned fields (estimated output, bridge, duration, Robyn fee). It explicitly says 'Read-only — moves nothing,' distinguishing it from execution tools like robyn_cross_chain or robyn_submit.

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

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

Provides strong contextual guidance: it says to use the tool for quoting and explicitly warns about quoteOnly=true cases, instructing the agent to present such quotes as price comparison only and not as sendable. It references that 'execute will refuse it' but does not name the specific alternative tools (e.g., robyn_cross_chain) explicitly, so it falls just short of a 5.

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 transparency burden. It discloses a required header ('x-anygas-receipt: 1'), the conditional trigger (IF Robyn refuses), and a critical limitation: 'It proves the refusal HAPPENED; it does not claim the refusal was correct.' This is meaningful behavioral context, though it omits return format and authentication 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 front-loaded with the core action and remains focused. The extended rationale about blame and proving external blockage is helpful but slightly verbose; still, each sentence contributes to understanding the tool's value and proper use.

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 a single parameter, no output schema, and no annotations, so the description must cover the full context. It explains the setup, when it applies, and a key semantic limit, but it does not describe the verification result format, failure behavior, or how to interpret the outcome, leaving notable gaps for a no-output-schema tool.

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

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

The schema covers 100% of the single required parameter 'receipt,' described as 'the full refusalReceipt object as returned.' The description adds context about the receipt's contents (what was asked, when, and why) and its purpose, but the schema already provides the essential semantics, so the value added is marginal.

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 starts with 'Check a signed refusal receipt,' which clearly identifies the tool's primary action and target resource. It distinguishes this tool from siblings by focusing specifically on refusal receipts and explaining their evidentiary role, making its purpose unmistakable.

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 this tool is relevant: when Robyn refuses a request and the provider denies, and it emphasizes that the receipt proves external blockage versus agent failure. It provides clear context for use, though it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations, the description provides transparency about state transition (BRIDGING → DONE) and output (destination tx when delivered). It does not mention error conditions or rate limits, but for a status check this is reasonable.

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

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

The description is a single focused sentence with no wasted words. It front-loads the purpose and provides key details efficiently.

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

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

Given the low complexity (1 param, no output schema), the description covers input, behavior, and output hint. It lacks explicit return structure but is sufficient for the tool's simplicity.

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

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

The single 'id' parameter has 0% schema coverage. The description adds meaning by stating 'by id' and implying it identifies a route, but does not specify format or example. This partially compensates for the schema gap.

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

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

The description clearly states the tool returns status of an in-flight route by ID, with state transition (BRIDGING → DONE) and delivery of destination tx. It distinguishes from sibling tools like robyn_cross_chain (initiation) and robyn_quote (quoting).

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 says to use for status of an in-flight route by ID. While it doesn't mention when not to use or alternatives, the context of sibling tools implies this is for checking after route creation.

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 key behavioral traits: no key required, no funds moved, no broadcast (simulated). This adequately informs an agent that the tool is safe and non-destructive, though it could mention absence of 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 with no unnecessary words. Front-loaded with the action, then the constraints. Each sentence adds value and the structure is clean.

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 7 parameters, no annotations, and no output schema, the description is minimal. It provides the tool's purpose but lacks parameter details, usage examples, or output explanation, making it incomplete for an agent to use effectively.

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

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

Schema description coverage is 0% across 7 parameters. Description adds no meaning beyond property names (e.g., 'amountHuman' is not explained). An agent cannot infer parameter details from the description alone, which fails to compensate for the missing schema documentation.

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

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

Description clearly states it runs a dry-run of the whole flow in sandbox mode ('no key, no funds, no broadcast'). While it distinguishes from siblings by indicating sandbox usage, it does not explicitly name alternative tools for comparison.

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 'Use this to prove an integration works before touching real money,' providing clear guidance on when to use. Does not include explicit exclusions or when not to use, but the intent 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 disclose behavior. It does so by explaining the statement is signed via EIP-191, verifiable against a published address, and explicitly states the coverage limitations: only the Robyn float lane, excluding other rails and netting book. This is strong behavioral context beyond a simple read-only hint, though it does not mention auth or rate limits.

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

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

The description is two sentences but rich with information. It front-loads the core function, then gives usage context and limitations. It's not overly long, though the 'Read limitations and repeat them' phrasing adds a minor imperative tone.

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 no annotations, the description covers purpose, signed nature, and limitations. It doesn't describe the exact return payload or verification steps, but the EIP-191 mention and 'verifiable against a published address' provide enough for an agent to infer usage. It's fairly complete for this tool.

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

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

Both parameters are fully described in the input schema (100% coverage), so the description adds no extra parameter-level detail beyond what the schema already covers. The description mentions 'window' and 'record names this sender' but these mirror 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 tool produces a signed statement of every transfer in a window with fee breakdowns, and explicitly distinguishes it from an 'own summary' claim. This is specific and differentiates from sibling statement tools by highlighting the signed/provable nature.

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

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

Provides explicit when-to-use guidance: 'Use this when you must PROVE to a principal what you spent', and contrasts with the less trustworthy own summary. It also warns about limitations, though it doesn't name alternative sibling tools directly, the contrast with own summary implies the alternative.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the endpoint performs a dry price-check (returns estGas, priceUsd, envelope) and that broadcasting requires a separate call with an X-PAYMENT header. It mentions that Robyn pays gas, so no native token is needed. It does not cover failure modes, rate limits, or authentication details beyond the header, which is a gap.

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

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

The description consists of two well-structured sentences. The first sentence clearly states the primary purpose, and the second sentence explains the dual-mode operation. No extraneous information. It is front-loaded with key details about who pays gas and the two call paths.

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 (EIP-7702, nested authorization, two modes) and no output schema, the description covers the essential flow but lacks details on error handling, prerequisites (signed authorization), and the exact structure of the return values (estGas, priceUsd, envelope). It provides a good overview but falls short of being fully actionable without additional context.

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

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

Schema coverage is 50%, meaning half of the parameters lack schema descriptions. The description does not elaborate on parameter semantics; it only mentions the overall function. For example, the 'authorization' object and 'chainId' are not explained beyond the schema. The description adds marginal value to parameter understanding.

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

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

The description clearly states the tool's purpose: 'Price or request an EIP-7702 sponsored transaction'. It specifies the resource (EIP-7702 transaction) and the action (sponsor, relayer pays gas). It distinguishes between a dry price-check and actual broadcast, and the context signals show siblings like robyn_7702_check and robyn_7702_delegate, which are clearly different.

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 guidance on when to use the tool: for sponsored transactions where the relayer pays gas. It explains the two modes (dry price-check vs. broadcast with X-PAYMENT header). However, it does not explicitly state when not to use this tool or compare it to sibling tools, though the unique function is evident.

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 behavioral burden. It discloses that the relayer fronts gas, the signed spender must match the relayer, and the critical caveat that omitting a live flag may still broadcast on the EVM-to-EVM path. It also explains dryRun return values and idempotencyKey semantics, providing rich behavioral context.

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

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

The description is dense but well-organized, with the main action up front, then permit2 construction, safety warnings, and a critical corridor-specific caveat. Every sentence serves a purpose, though the all-caps warnings and repeated emphasis make it slightly longer than strictly necessary. It earns a 4 for effectiveness despite minor verbosity.

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 core workflow, permit2 construction, gas sponsorship, dryRun behavior, and idempotency. Given the complexity (nested permit2 object, dryRun variations) and absent output schema, this is quite complete. However, the normal (non-dryRun) return value is never described, which is a notable gap for a submission 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 description coverage is only 33%, so the description must compensate. It adds crucial meaning for permit2 (explicitly stating it is an object, not a bare signature, and how to build it) and idempotencyKey (prevents double-spend on retry). However, basic params like fromChain/toChain and amount receive no additional explanation beyond their names, leaving some ambiguity.

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 opens with a specific verb and resource: 'Relay an intent you already signed.' It clearly distinguishes this as the submission step after robyn_prepare, distinct from related tools like robyn_quote or robyn_preflight. The scope (broadcast signed intent, relayer pays gas) is explicit.

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 usage context: build permit2 from robyn_prepare, sign the eip712 payload, and pass the object. It also warns about dryRun behavior and idempotency. However, it does not explicitly mention when not to use this tool vs. alternatives, so it stops short of a 5.

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 fully discloses behavior: it decodes ERC-20 Transfer logs, cross-checks Robyn's receipt, and defines a three-valued verdict including the meaning of 'undetermined'. It also warns about non-re-derivable rails, offering deep insight beyond the schema.

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

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

While detailed, every sentence provides necessary information: purpose, optional parameters, decoding behavior, verdict semantics, and usage warnings. Information is front-loaded with clear formatting and the verdict is highlighted, making it easy to scan. 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?

Despite no output schema or annotations, the description covers core functionality, parameter usage, and result interpretation thoroughly. It explicitly addresses edge cases like unreachable chains and non-re-derivable rails, making the description complete for an agent to select 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?

The schema covers all parameters with descriptions, but the description adds functional meaning: explains that 'recipient' asserts who should be paid and 'minAmount' asserts the minimum arrival, and that 'id' can be a transfer id or tx hash. This enriches the schema's raw definitions and clarifies how parameters are used in verification.

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 a specific verb ('Check what ACTUALLY happened') and clearly identifies the resource ('a settled transfer against the destination chain'). It distinguishes this tool from Robyn's own database and covers the optional assertions of recipient and minAmount, making the purpose unambiguous and differentiating it from siblings like robyn_route_status.

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 explains when to use this tool: to verify settled transfers against the chain rather than Robyn's database. It also provides a clear exclusion rule: 'undetermined' must never be treated as success, with specific examples of when undetermined occurs. This gives strong guidance on interpretation and limits.

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. It explicitly states 'Read-only' and outlines the membership benefits, giving the agent a clear understanding of what the tool does without side effects. It could mention edge cases like invalid address handling, but the core behavior is transparent.

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

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

The description is two sentences long and front-loaded with the action. The second sentence provides dense, useful context about benefits and usage, without redundant fluff. It's slightly long but each clause earns its place, so 4 is appropriate.

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 read-only check with one parameter, the description covers purpose, usage, and behavior. No output schema exists, so the description reasonably indicates the output involves membership status and benefits, though it doesn't specify exact return format or error handling. This is a minor gap, so 4.

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 for the single 'address' parameter with a clear EVM address description. The tool description adds no extra semantics beyond the schema, so the baseline 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?

The description clearly states the tool checks whether an address holds a recognised member NFT and what benefits it gets. It uses a specific verb ('Check whether') and resource ('an address'), and the mention of membership benefits distinguishes it from routing/quoting siblings like robyn_quote and robyn_cross_chain.

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

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

The description explicitly instructs to call this before quoting a user, providing a clear context for use. It implies the tool informs accurate cost quotes and savings for non-members, but it does not explicitly name alternative tools or specify when not to use it, so it falls short of a 5.

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 explains key nuances: the meaning of wasCompetitive, that silent rails failed to answer rather than being more expensive, and that the output is signed for archival. This goes well beyond a typical description.

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 composed of four sentences, with each sentence adding critical information: the output contents, the signed nature, the wasCompetitive warning, and the silentRails misrepresentation risk. It is a bit dense but not overly long.

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

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

Given the absence of an output schema, the description covers the essential output components and interpretation caveats, which is helpful. However, it omits any explanation of the required parameters and does not mention potential error conditions or edge cases.

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 has 0% description coverage, and the description does not explain any parameters such as fromChain, toChain, amount, or toAddress. Users are left to infer parameter meaning from the tool's name and routing context.

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

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

The description clearly states the tool returns the full routing decision, including every rail that quoted, what they would deliver, and the winning margin. This specific verb+resource clearly distinguishes it from sibling tools like robyn_quote or robyn_route_status.

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 provides explicit usage guidance, such as checking wasCompetitive before telling a user the price is good and warning that silentRails did not lose but failed to respond. However, it does not explicitly compare against sibling tools or state when 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?

No annotations are provided, so the description carries full burden. It discloses non-custodial trust model and that funds remain in the agent's wallet, but does not explicitly state whether the tool is read-only or has side effects. For a query tool, this is adequate but not comprehensive.

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

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

The description is two sentences, highly efficient, and packs all key information (protocols, allowances, APY, non-custodial) without wasting words. No redundancy or unnecessary 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?

Given the simple single-parameter input and no output schema, the description provides sufficient context about what the tool returns and its purpose. It could be slightly improved by noting the output format, but overall it is complete for an agent to understand utility.

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 one parameter fully described as 'the agent wallet address (0x…)'. The tool description does not add additional semantics beyond the schema, so the 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 provides an agent's own Aave v3/Moonwell position (aUSDC/mUSDC) per chain, including the capped allowance and live APY. It distinguishes from siblings like robyn_yield_quote and robyn_yield_spend by focusing on the account position and non-custodial nature.

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

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

The description explains what the tool does but does not explicitly state when to use it versus alternatives like robyn_yield_quote or robyn_yield_spend. Usage context is implied but lacks explicit guidance on 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, description clearly states 'Read-only' and 'Moves nothing', confirming no side effects. It also outlines the fulfillment flow (draw, withdraw, deliver), providing useful behavioral context beyond just idempotency.

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

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

The description is two sentences, front-loading 'Read-only JIT quote' and avoiding redundancy. Every part 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 and 5 parameters, the description is incomplete. It does not explain return value structure, error conditions (e.g., insufficient allowance), or constraints on parameters like 'toChain' or 'toAddress'.

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 only 20% (amount only). The description does not clarify most parameters (agent, srcChain, toChain, toAddress) beyond what the schema provides. It hints at 'draw <= allowance' and 'Aave/Moonwell' but does not explicitly map to 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 'Quote a spend from yield' and explains it is a read-only JIT quote. The verb 'quote' and resource 'yield venue' are specific. While it distinguishes from sibling 'robyn_yield_spend' (actual spend), it does not explicitly differentiate from generic 'robyn_quote'.

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

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

Description indicates usage for quoting without moving funds ('Read-only', 'Moves nothing'). However, it lacks explicit when-not-to-use or alternative tools, such as comparing to 'robyn_yield_spend' for execution.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only (returns intent), requires a separate execution step, and outlines the one-time setup. It also explains the behavior: 'pulls only up to your on-chain aUSDC/mUSDC allowance, unwinds exactly what is needed, and delivers gaslessly'. It does not detail error conditions or rate limits, but is fairly transparent for a preview 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 about 5 sentences, each adding value. It starts with the core purpose, then outlines the process, next steps, and setup. It is well-structured and front-loaded, though slightly lengthy. It earns its keep without redundancy.

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

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

Given the tool's complexity (no output schema, no annotations, 5 parameters with 0% coverage), the description explains the overall flow and use case but lacks parameter details and response format. It provides enough context for an agent to decide to use the tool, but incomplete parameter information may lead to incorrect 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?

The input schema has 5 parameters with 0% description coverage. The description does not explain the meaning of the parameters (agent, amount, toChain, srcChain, toAddress). It mentions 'agent' in context of Robyn and 'srcChain' and 'amount' in the process description, but lacks explicit semantics. The description does not compensate for the schema's lack of documentation.

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

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

The description clearly states the tool's purpose: 'Spend from your yield (Aave v3 or Moonwell) with ONE EIP-712 signature'. It explains what it does (pulls from aUSDC/mUSDC allowance, unwinds, delivers gaslessly) and distinguishes it from siblings like robyn_yield_account and robyn_yield_quote by focusing on spending from yield.

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 usage guidance: it is a hosted, read-only endpoint that returns an intent to sign, and explains how to execute the spend by signing and posting to another endpoint or running a local command. It also mentions one-time setup. However, it does not explicitly mention when not to use this tool or compare it directly with sibling tools.

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