Gitbank

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

Annotations provide readOnlyHint=true, so the description does not need to reiterate safety. The description adds the list of possible statuses but does not mention error handling or behavior for invalid confirm_codes. With annotations covering the safety profile, the description adds modest 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 a single sentence that immediately states the action and key details. It is front-loaded and contains no superfluous information.

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

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

For a simple status check with one parameter, the description covers the core functionality and expected outputs. The read-only nature is indicated by annotations. Minor omission: no mention of idempotency or safe repetition, but overall complete enough.

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

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

The single parameter 'confirm_code' is described in the schema with adequate clarity. The tool description repeats this without adding new semantic details such as format or constraints. Since schema coverage is 100%, 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 verb 'check' and the resource 'status of a pending Gitbank command', with specific identification via 'confirm_code'. It also lists the possible return values, making the purpose distinct from sibling tools that are either request actions or other status checks.

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

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

The description does not explicitly state when to use this tool versus alternatives like get_project_status or request_* tools. It implies usage after a request that returns a confirm_code, but lacks explicit guidance on prerequisites or disclaimers.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by detailing the exact output contents (budget, spent, remaining, tasks), which goes beyond what annotations provide.

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, immediate focus on the tool's action and output. No unnecessary words, highly efficient.

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

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

Given the tool's simplicity (2 params, no output schema), the description provides sufficient context about what is returned. It lists key data fields (budget, spent, remaining, tasks) adequately fulfilling the agent's need to understand the tool's purpose.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add new semantic meaning beyond what is already in the schema, so baseline score is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('budget and task status for a Gitbank project'), clearly distinguishing it from sibling tools that deal with stocks, vaults, or other unrelated entities.

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

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

No explicit guidance on when to use this tool versus alternatives. While sibling differentiation is implicit due to different resource types, the description lacks direct context or exclusion statements.

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

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

Annotations mark readOnlyHint=true. Description adds detail on returned fields (amount, value, cost basis, P&L), which goes beyond annotations. No contradictions.

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

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

Two sentences: first states action, second lists outputs. No wasted words, front-loaded with purpose.

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

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

Adequate for a simple read tool with no output schema. Explains key outputs and purpose. Could mention that output is not paginated, but not necessary given 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?

Schema covers 100% of parameter ('GitHub username') with description matching. Description does not add further semantics beyond stating it's for a user's portfolio, so baseline 3 is appropriate.

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

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

Description clearly states 'Get a GitHub user's gitStock holdings (RWA positions)' with specific outputs (amount held, value, cost basis, P&L). Clearly distinct from siblings like get_stock_price or list_stocks.

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

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

Implies usage for retrieving a specific user's portfolio holdings. No explicit when-not or alternatives, but sibling tools provide sufficient context for differentiation (e.g., get_stock_price for price, list_stocks for available stocks).

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

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

The description is consistent with the readOnlyHint annotation, confirming it is a read operation. It adds the detail of using the Pyth oracle but does not disclose other behaviors like rate limits, authentication needs, or potential failure modes.

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

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

The description is a single, concise sentence that front-loads the action and resource. Every word is necessary, with no wasted 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?

For a simple tool with one parameter and no output schema, the description provides the core functionality and return value. However, it does not clarify whether all tickers are supported or specify the exact output format beyond 'current price and timestamp'.

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

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

Schema coverage is 100% with the parameter description listing examples. The tool description adds no additional meaning beyond the schema, so the score is at the baseline for high 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 retrieves the live USD price of an Ondo tokenized stock from the Pyth oracle, specifying the resource and action distinctly from sibling tools such as list_stocks or get_transactions.

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 getting live prices but provides no explicit guidance on when to use this tool over alternatives or when not to use it. No exclusion criteria 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?

Annotations declare readOnlyHint=true, so the description aligns with read-only behavior. It adds context about transaction types and vault association but no further behavioral details (e.g., pagination, latency, or auth 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?

Single sentence, front-loaded with action and resource, no unnecessary words. Every part is informative.

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 tool with two parameters, the description covers the return type (transaction types). No output schema exists, so the description adequately conveys what is returned, though ordering or pagination details are omitted.

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

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

Schema coverage is 100% with clear parameter descriptions. The description does not add meaning beyond the schema; it implicitly ties github_username to vault owner but doesn't mention the limit parameter.

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

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

The description clearly states the tool retrieves recent on-chain transactions (deposits, withdrawals, swaps, bounty payouts) for a Gitbank vault. The verb 'Get' and resource 'transactions' are specific, and it distinguishes from siblings like get_vault_balance or list_repos.

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 viewing transaction history but lacks explicit guidance on when to use vs alternatives or when not to use. No exclusions or cross-references to sibling tools are provided.

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

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

Annotations already declare readOnlyHint=true, and the description confirms read-only behavior by stating it 'Get' balances. The description adds network and token context, but does not disclose other traits like rate limits or authentication needs. With annotations covering the safety profile, the description provides marginal additional transparency.

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

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

The description consists of two sentences with no wasted words. It front-loads the key action and resource, making it easy to parse.

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

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

Given the tool's simplicity (one parameter, no output schema, readOnly annotation), the description provides all necessary context: what it does, what it returns, and the network. No gaps are evident.

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 describes the single parameter 'github_username' with a description. The tool description does not add extra meaning beyond what the schema already provides. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description specifies the verb 'Get', the resource 'WETH and USDC locked balance of a Gitbank vault', the network 'Base mainnet', and the output 'vault address and per-token balances'. This clearly distinguishes it from sibling tools like get_stock_price or request_deposit.

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

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

The description does not explicitly state when to use this tool versus alternatives like check_pending or get_project_status. While the purpose is clear, no guidance on exclusion or context is provided, which is adequate but leaves room for improvement.

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

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

The annotations already declare readOnlyHint=true, and the description's verb 'List' is consistent with a read-only operation. No contradiction. However, the description does not disclose additional behavioral traits such as rate limits, authentication requirements, or whether the returned list is paginated. It provides minimal extra context beyond the 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 a single sentence of 10 words, which is concise and front-loaded with the action. However, it could be structured with bullet points or additional details without becoming verbose. It earns its place but is slightly too minimal.

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 is read-only, the description is adequate but not complete. It does not describe the output format (what is returned) even though no output schema is provided. It also does not mention any prerequisite (e.g., the user must have the bot installed). For a simple tool, this is acceptable but has clear gaps.

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

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

The input schema has 100% coverage with a clear description for the only parameter ('GitHub username to look up'). The tool description adds nothing beyond this; it repeats that it lists 'for a user'. Since the schema already documents the parameter adequately, the description does not enhance understanding. Baseline score of 3 is appropriate.

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

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

The description clearly states the action (list) and resource (GitHub accounts where the bot is installed). However, there is a slight inconsistency: the tool name is 'list_repos' but the description says 'GitHub accounts' rather than repositories. The annotation title 'List Connected Repos' clarifies, but the description itself could be more precise. It distinguishes from sibling tools as no other tool lists repos or accounts.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where other tools (e.g., check_pending, get_project_status) might be more appropriate. The description only states what it does, not when it should be invoked.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful context about the backing and representation of the stocks, going beyond what annotations provide. However, it does not detail any other behavioral traits like ordering or pagination.

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 at two sentences, with the first sentence stating the primary purpose and the second adding relevant context. No superfluous information.

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

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

Given no parameters and no output schema, the description explains the tool's purpose and the nature of the data (backing and representation). However, it does not specify the exact output fields or format, which would improve completeness.

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

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

Input schema has no parameters, and schema description coverage is 100%, so baseline is 3. Description adds no parameter information because none exist.

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

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

The description clearly states the tool lists all available Ondo tokenized stocks, with a specific verb 'List' and resource. It distinguishes its purpose from sibling tools like 'get_stock_price' by mentioning they can be bought, but does not explicitly differentiate from all 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 description implies usage before buying stocks ('can be bought via Gitbank') but provides no explicit guidance on when to use versus alternatives like 'get_stock_price' or 'request_buy_stock'. No when-not-to-use or context exclusions are given.

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

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

The description discloses that the tool returns a confirm_code that must be posted on GitHub to authorize execution, indicating a multi-step process. Annotations lack readOnlyHint/destructiveHint, so the description carries the burden; it is fairly transparent but could mention side effects or permissions.

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

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

Two sentences, no wasted words, front-loaded with purpose. Every sentence adds value.

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

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

Given 6 parameters and no output schema, the description explains the confirm_code requirement effectively. It is mostly complete, though the post-authorization flow could be clarified.

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

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

Schema coverage is 100% with descriptive parameter descriptions. The tool description adds no extra parameter information beyond what the schema provides, so baseline of 3 is appropriate.

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

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

The description states a specific verb ('Request') and resource ('bounty assignment to a contributor for a GitHub issue'), and mentions the return of a confirm_code. This clearly distinguishes the tool from siblings, none of which deal with bounties.

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 assigning bounties but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Siblings include other request tools, but no comparison is made.

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 carrying behavioral hints, the description details the multi-step process (bridge, swap, mint), the return of a confirm_code, and the required user action (post on GitHub). This fully discloses the tool's behavior beyond annotations.

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

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

Two sentences efficiently convey the core operation, process, and expected output. No extraneous information; front-loaded with the primary action.

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

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

Even without an output schema, the description explains the return value (confirm_code) and the user's follow-up action. It covers the entire request workflow adequately for an agent to use correctly.

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

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

Schema already provides 100% description coverage for all three parameters. The description adds contextual value by linking the usdc_amount to the vault and outlining the overall process, which aids 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 buys Ondo tokenized stocks using USDC from the vault, detailing the bridging, swapping, and minting steps. It distinguishes itself from sibling tools like request_sell_stock and request_swap by focusing on a specific buy operation.

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

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

The description implies usage for buying stocks, and sibling tool names naturally differentiate when to use this vs alternatives. However, it lacks explicit guidance on prerequisites or non-use scenarios.

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

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

Annotations are minimal (only a title). The description adds behavioral details: the tool returns a confirm_code that requires GitHub posting for execution, and it specifies supported tokens. No contradiction with annotations.

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

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

The description is two sentences, front-loaded with purpose and return value, followed by token support. Every sentence is necessary and no waste.

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

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

No output schema is present, but the description explains the return value (confirm_code). It does not cover error conditions or confirm_code format, but for a simple 3-parameter tool, this is mostly complete.

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

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

All three parameters have descriptions in the schema (100% coverage). The tool description adds value by explaining the return value (confirm_code) beyond the schema. Baseline 3 is elevated to 4 due to this added 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 states 'Request a deposit into a Gitbank vault', clearly indicating the action (request a deposit) and the resource (Gitbank vault). This distinguishes it from sibling tools like 'request_withdraw'.

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 the intended use (depositing into a vault), lists supported tokens (USDC, WETH), and notes the need to post a confirm_code on GitHub for authorization. It does not explicitly mention when not to use or alternatives, but the context is clear.

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

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

With no annotations beyond title, the description partially explains behavior: it requests a launch, requires ETH, and returns confirm_code. It doesn't disclose auth needs, rate limits, or whether the action is destructive. The side effect of ETH purchase and distribution is mentioned, but overall transparency is average.

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 (55 words), front-loading the core action and then detailing the key requirement and output. Every sentence adds value with no redundancy.

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

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

Despite 9 parameters and no output schema, the description covers the main purpose and return type but lacks detail on how to use the confirm_code or the full process. For a complex tool, more guidance on follow-up steps would improve completeness.

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

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

The input schema has 100% description coverage, and the description adds no parameter-specific semantics beyond the overall function. Since the schema already documents each parameter well, the description does not need to compensate, leading to a baseline score of 3.

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

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

The description clearly states it requests a token launch on Base Mainnet via Clanker, a specific resource. It mentions unique aspects like the creator buy-in and return of confirm_code, making it unmistakable among sibling tools.

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

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

The description explicitly states the requirement of a 0.01 ETH creator buy-in and the distribution to GITBANK holders, providing clear prerequisites. However, it does not explicitly state when to use or not use this tool compared to siblings, though no sibling launches tokens, so usage is implicit.

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

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

The description fully discloses the tool's behavior beyond the minimal annotations: it burns soul-bound tokens on Base, sells on Jupiter, bridges USDC via CCTP, and returns a confirm_code that requires user action. This covers all key behavioral traits including destructiveness and user authorization steps.

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 at three sentences, front-loading the core action in the first sentence. Every sentence adds necessary information without redundancy, making it efficient for an agent to parse.

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

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

Given the complexity of the tool (multi-step cross-chain operation), the description covers all essential aspects: what happens to tokens, where operations occur, the output, and required user action. No output schema exists, so the description adequately explains the return value.

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

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

The input schema has 100% description coverage for all three parameters, so the schema already provides clear meaning. The tool description adds context about the overall process but does not enhance parameter semantics beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's main purpose: selling Ondo tokenized stock back to USDC. It specifies the action, resource, and target currency, and it distinguishes itself from sibling tools like request_buy_stock and request_swap through its detailed multi-step process.

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 indication of when to use this tool is implied by the name and description, but there is no explicit guidance on when not to use it or how it compares to alternatives like request_swap or request_buy_stock. The description does not provide exclusion criteria or usage context relative to siblings.

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

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

The description discloses that the tool returns a confirm_code and requires the user to post on GitHub for authorization, which is critical behavioral information beyond the minimal annotations. No contradictions.

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

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

Two sentences: first states the action and example, second explains the return and required follow-up. No extraneous information, front-loaded with key 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 no output schema, the description explains the return value adequately. Missing details like error handling or prerequisites, but for a simple request tool with 4 parameters, it is sufficiently complete.

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

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

Schema coverage is 100% with clear parameter descriptions, but the tool description adds valuable context (e.g., 'inside a Gitbank vault') and explains the return value, which helps the agent understand the purpose of parameters beyond their individual schema.

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

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

The description clearly states the action (request a token swap), the resource (Gitbank vault), and provides an example (USDC to WETH). It also mentions the return value, distinguishing it from other request_* tools like request_deposit or request_withdraw.

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

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

The description provides clear context for when to use the tool (token swaps in vaults) but does not explicitly state when not to use it or list alternatives. However, the context is sufficient for an agent to infer usage.

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

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

Description discloses key behaviors: queuing the transfer, returning a confirm_code for GitHub posting, and on-chain verification at confirmation time. With no annotations beyond title, it provides substantial transparency, though it omits details like reversibility or fees.

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

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

Description is four sentences, with the core action in the first sentence. Every sentence adds information without redundancy, and the structure is clear and efficient.

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

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

Given no output schema and minimal annotations, the description covers the essential aspects: purpose, prerequisites, return value, and supported tokens. It lacks full detail on the post-confirm_code flow, but is largely complete for a transfer tool.

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

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

Schema covers all 4 parameters with descriptions (100% coverage). The description adds value by explaining the overall process and the role of the confirm_code, but the schema adequately defines each parameter.

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

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

Description clearly states the verb 'Queue a vault-to-vault token transfer' and specifies the resource (another GitHub user on Base Mainnet). It distinguishes from sibling tools by being a transfer-specific action with a unique two-step authorization process.

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 when to use (to transfer tokens between vaults) and prerequisites (both must have a Gitbank vault). It does not explicitly exclude alternatives, but the context of sibling tools makes the purpose 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?

The description reveals the two-step authorization process (returns confirm_code, must post on GitHub). This is valuable beyond the minimal annotations (only title). However, it omits potential fees, limits, or error states, leaving some behavioral gaps.

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

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

The description is extremely concise with two sentences, front-loading the core action and return value. Every word contributes to understanding, with no filler or redundancy.

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

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

Given no output schema, the description adequately mentions the confirm_code return. It covers the essential flow (request then authorize via GitHub). It could mention error handling or what happens after posting, but for a request tool this is sufficient.

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

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

The input schema has 100% description coverage for all four parameters, so the baseline is 3. The tool description does not add any additional parameter meaning beyond what the schema provides, nor does it explain parameter relationships or constraints.

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 requests a withdrawal from a Gitbank vault to an external address. It specifies the action and resource, and mentions the return of a confirm_code. However, it does not differentiate from sibling tools like request_deposit or request_transfer, relying on the verb 'withdraw' to imply uniqueness.

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

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

No guidance is given on when to use this tool versus alternatives. The description does not specify prerequisites, conditions for use, or when to prefer other request_* tools. An explicit comparison or usage context is missing.

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