AI Agent Tokenized Stock OS

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

With no annotations, the description carries full burden and discloses a key behavioral trait: the API key is shown only once. This is critical for agent decision-making. However, it does not mention failure handling, authentication requirements, 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 a single, well-structured sentence that packs essential information with no wasted words. It is front-loaded and 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 has 3 parameters and no output schema, the description is too minimal. It does not explain the return value, the verification process, or how the API key is delivered. An agent would need additional context to use it 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% and the description does not explain any of the three parameters (tier, owner, txHash). This leaves the agent without guidance on how to populate them, forcing reliance on schema names alone.

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

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

The description clearly states the action 'verify and issue API key' and specifies the precondition 'after ETH payment to treasury is confirmed'. It effectively distinguishes itself from sibling access tools like checkout and pricing.

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 after payment confirmation but does not explicitly state when to use or avoid this tool versus alternatives. No sibling comparisons or exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool builds an on-chain payment plan, implying a transaction, but it doesn't mention side effects, permissions, or error conditions. The description is moderately transparent but lacks depth.

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 with no fluff. The first sentence states the purpose, and the second provides the next step. Every word serves a useful function.

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

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

Given the lack of annotations, output schema, and parameter descriptions, the tool definition is incomplete. The description covers high-level purpose and a post-condition but fails to explain inputs, output, or behavior, leaving significant ambiguity.

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 2 parameters (tier and owner) with 0% schema description coverage. The description does not mention or explain any parameters, leaving the agent without guidance on how to populate them. This is a critical 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's function: it builds an on-chain ETH payment plan for Pro/Team tiers. The verb 'build' and resource 'on-chain ETH payment plan' are specific, and the scope (Pro/Team) differentiates it from sibling tools like pricing, status, or activation.

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 clear sequential guideline: after the user pays, call stocktoken_access_activate. This helps the agent understand the workflow. However, it does not explicitly state when not to use this tool or offer alternatives, so some guidance is missing.

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 implies a read-only list operation by stating it lists pricing, but does not explicitly declare it as non-destructive, nor does it disclose authentication needs, rate limits, or side effects. Adequate but not thorough.

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

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

One concise sentence covering key points (free/pro/team pricing, payment method, agent payment). No fluff, but could be improved by adding structure or bullet points for clarity.

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 parameters, the description is reasonably complete. It explains the what and a notable detail (ETH on-chain, no Stripe). However, it lacks details on output format or any constraints, which are not critical but would enhance 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?

No parameters exist, and schema coverage is 100%, so the description adds no parameter info. Baseline is 4 per rubric; description appropriately omits param details.

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

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

The description clearly states the tool lists Free/Pro/Team pricing and how agents pay for write tools. It uses specific verb 'List' and specifies the resource 'pricing', distinguishing it from siblings like stocktoken_subscription_tiers by mentioning payment details (ETH on-chain, no Stripe).

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

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

No guidance on when to use this tool vs alternatives such as stocktoken_subscription_tiers or stocktoken_fees. The description does not mention prerequisites, context, or when not to use it, leaving the agent to infer usage without explicit direction.

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

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

No annotations provided, so the description must fully convey behavior. It implies a read-only check but does not explicitly state idempotency, side effects, authentication needs, or return format.

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

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

Single sentence, no filler, efficient communication of purpose and parameter behavior.

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

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

With one simple parameter and no output schema, the description covers the two modes of operation adequately but omits behavioral details like safety profile (read-only) and return structure.

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

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

Schema coverage is 0%, but the description adds meaning: the 'owner' parameter is optional and defaults to the current API key context. This clarifies the parameter's role, though the format (e.g., address) is not specified.

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 purpose: 'Check paid access for current API key context or a wallet owner.' It uses a specific verb ('Check') and resource ('paid access'), and distinguishes itself from sibling tools like stocktoken_access_activate and stocktoken_access_pricing by focusing on status checking.

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

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

No guidance on when to use this tool versus alternatives (e.g., stocktoken_subscription_status). No explicit when-not or context for use.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'preview' and 'live prices' but does not disclose read-only nature, authorization needs, or any side effects. The behavioral insight is minimal.

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, front-loaded with the core action, and contains no redundant words. Every word adds value.

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

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

Given no parameters, output schema, or annotations, the description provides adequate context for a simple preview tool. It tells the agent what data it returns. However, for a complex domain, slight elaboration on the basket identity could 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 zero parameters (100% coverage by default). The description adds meaning by specifying what is previewed (constituents and prices), which compensates for the lack of parameter details. Baseline 4 for 0 parameters.

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

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

The description uses specific verbs and resources: 'Preview AI mega-cap basket constituents and live Chainlink prices'. It clearly states what the tool does and distinguishes it from siblings like stocktoken_get or stocktoken_list.

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

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

The description implies usage (preview before actions) but does not explicitly state when to use this tool versus siblings like stocktoken_get or execute_plan. No exclusions or alternatives 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?

The description explicitly states that the tool does NOT sign or broadcast, which is crucial behavioral info. However, it does not disclose potential side effects, authentication needs, or rate limits. With no annotations, this is adequate but incomplete.

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

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

Two sentences with no fluff. Key actions (build plan, approve+swap) and constraints (non-custodial, no sign/broadcast, chain) are front-loaded. 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 9 parameters and no output schema, the description is insufficient. It explains the core action but omits output format, parameter details, and edge cases. A more complete description would cover these aspects.

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 0% schema description coverage, the description should explain parameters, but it only mentions approve+swap and best venue. No parameter details (e.g., owner, tokenIn, tokenOut, amountIn, slippageBps) are explained, leaving the schema's undocumented fields ambiguous.

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 builds a non-custodial transaction plan for approve+swap via a best venue (Uniswap/0x), and distinguishes itself from siblings by specifying it does not sign or broadcast and operates on chain 4663.

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 like stocktoken_quote or stocktoken_subscribe_plan. The description does not mention prerequisites, typical use cases, or exclusions.

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

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

No annotations are provided, and the description does not disclose any behavioral traits such as whether it requires authentication, has side effects, or is read-only. The 'explain' verb implies a safe query, but this is not explicit.

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

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

The description is a single sentence, which is short, but it is under-specified—it lacks details about what the explanation includes or how to use the parameter. Conciseness is not helpful when critical information is missing.

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 large number of sibling tools and the lack of output schema, the description is incomplete. It does not clarify what the explanation will look like (e.g., text, structured data) or how it relates to other 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?

The input schema has a single optional parameter 'userIntent' with no description or enum, and the tool description does not mention this parameter. With 0% schema description coverage, the description adds no meaning.

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

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

The description clearly states the tool explains when to use different trading platforms (AI Agent Tokenized Stock OS, Robinhood MCP, raw Uniswap/0x). It uses a specific verb 'explain' and resource 'routing', which distinguishes it from other stocktoken tools that perform actions like access, execute, or list.

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

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

No guidance is provided on when to call this tool versus sibling tools. The description explains the tool's purpose but does not specify contexts where the explanation is needed or prerequisites.

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

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

With no annotations, the description carries the burden. It correctly indicates read-only behavior by stating 'summarize' and 'status', which implies no destructive actions. However, it lacks details on authentication or rate limits, but for a simple summarization 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?

The description is a single, efficient sentence that starts with the verb 'Summarize' and contains no extraneous words. It is front-loaded and to the point.

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

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

For a no-parameter, no-output-schema tool, the description sufficiently explains the purpose. It could mention return format or data freshness, but the context is clear 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?

There are no parameters (schema coverage 100%), so baseline is 4. The description adds meaning by specifying what the summary includes (fee events, treasury/ETH fees), going beyond the empty schema.

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

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

The description clearly states the tool summarizes AATOS execution fee events and on-chain monetization status, using specific verbs and resource context. It distinguishes itself from sibling tools that cover pricing, metrics, or other aspects.

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 is given. It implies a read-only fee summary role but does not mention alternatives or scenarios where other tools are more appropriate.

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

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

No annotations provided, so description must disclose behaviors. It only mentions scanning pools on a specific chain, omitting whether it's read-only, rate limits, or side effects. Minimal 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?

Two concise sentences with no wasted words. The first sentence defines the primary action, and the second provides a use case.

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, no parameter details, and minimal behavioral info. For a tool with required parameters and no annotations, the description is far too sparse to ensure correct invocation.

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

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

Schema has 0% description coverage for parameters. Description does not explain tokenA and tokenB (e.g., address format, chain details) beyond their names, leaving the agent to guess.

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

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

Clearly states it scans for Uniswap V3 pools between two tokens on chain 4663. The verb 'scan' and resource 'Uniswap V3 pools' are specific, and the scope is well-defined.

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?

Suggests use when APIs block stock tokens, implying a fallback scenario. However, no explicit guidance on when not to use or comparison to sibling tools, leaving the agent to infer.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It indicates the tool is a read-only lookup ('Get metadata') but does not specify what fields are returned, authorization requirements, rate limits, or any potential side effects. While the intent is clear, the lack of return structure details leaves some ambiguity.

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

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

The description is two concise sentences that front-load the action and purpose. Every word is necessary, with no redundancy or filler. It efficiently communicates the tool's function and typical use case.

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 lookup tool with one parameter and no output schema, the description covers the primary use case and identifier types. Adding a note about the metadata returned (e.g., 'name, symbol, decimals') would make it fully complete, but the current level is sufficient for correct invocation.

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

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

The input schema has 100% description coverage for the single parameter 'symbolOrAddress', explaining it accepts tickers or contract addresses. The description adds context about the blockchain ('Robinhood Chain 4663') and the purpose, which is helpful but does not significantly extend schema semantics. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Get metadata'), identifies the resource ('canonical Stock Token or core asset'), and specifies identifiers ('symbol or contract address'). It also states the use case ('verify a token is official before trading'), clearly distinguishing it from sibling tools like 'stocktoken_list' which would return multiple tokens.

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

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

The description explicitly states when to use this tool: 'Use to verify a token is official before trading.' It does not explicitly state when not to use it, but the context of sibling tools (e.g., 'stocktoken_list' for listing all tokens) provides implicit guidance. A clearer exclusion for alternative tools would improve the score.

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 present, so the description carries full burden. It discloses that user signs and onchain verifies later, but does not detail any side effects, permissions, or data flow beyond building typed data. Adequate but minimal.

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 clearly convey the tool's purpose and high-level workflow. No unnecessary words, front-loaded with key information.

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

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

Given the complexity (8 parameters, no output schema), the description is too brief. It lacks details on parameter roles, constraints like nonce or deadline, and return value expectations. The agent would need to infer too much from parameter names alone.

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 only 13% schema description coverage (only tokenIn has a description), the description adds no parameter-level meaning. For 8 parameters, including 5 required ones, this is insufficient to help an agent understand how to populate them correctly.

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 builds EIP-712 typed data for agent trade intents, specifying the offchain authorization nature and the user signing flow. This is unique among siblings, as no other tool explicitly handles typed data construction.

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

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

The description implies the tool is for offchain authorization but does not explicitly state when to use it versus alternatives like stocktoken_permit2_prepare. No exclusions or contextual guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. The description is simple and implies a read-only lookup, but it does not disclose potential behaviors like caching, latency, or side effects.

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

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

Two sentences with no wasted words. The key 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?

With no output schema, the description should explain what the matrix contains. It only says 'Liquidity / V3-executable route matrix,' which is somewhat vague. The tool's simplicity partially compensates, but a bit more detail 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?

There are no parameters, and schema coverage is 100%. The description doesn't need to add parameter information. Baseline 4 is appropriate.

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

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

The description clearly states it provides a liquidity/route matrix for major USDG pairs on chain 4663, with a specific use case: to know which Stock Tokens have live AMM fills. It distinguishes from sibling tools like stocktoken_find_pools or stocktoken_price.

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 explicitly says 'Use to know which Stock Tokens have live AMM fills,' which gives clear context. However, it does not mention when not to use it or suggest 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 provided, so description carries full burden. It implies a read-only listing behavior and adds the note 'Only registry addresses are real tokenized stocks,' which hints at potential data quality. While mostly straightforward, it could explicitly state it is a read operation.

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

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

Three sentences with no wasted words. Front-loaded with purpose, then usage guidance, then a clarifying note. All sentences earn their 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 listing tool with one parameter and no output schema, the description covers scope, platform, and exclusions. It does not describe return format or pagination, but given simplicity, 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?

Schema coverage is 100% with the 'kind' parameter having an enum and description. The description adds contextual meaning by mapping enum values (e.g., 'stable' to USDG, 'wrapped_native' to WETH), which goes beyond the schema's technical labels.

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 'canonical tokenized stocks (Robinhood Stock Tokens), ETFs, USDG, and WETH on Robinhood Chain ID 4663' with specific verb 'list' and resource. It distinguishes from US brokerage equities, ensuring the agent knows exactly what it does.

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 when to use (for tokenized equities/RWAs on Robinhood Chain) and when not ('Do NOT use for US brokerage equities'), directing to an alternative (Robinhood Trading MCP). This provides clear selection 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 full burden for behavioral disclosure. However, it only says 'operational metrics' without revealing side effects, permissions, rate limits, or expected output, leaving the tool's behavior largely opaque.

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 short sentence, which is concise but not sufficiently informative. It earns its place but could be improved with more detail without becoming verbose.

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

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

Given the lack of output schema and annotations, the description should provide enough context about what the tool returns or requires. 'Operational metrics' is too vague, and no information about expected output or usage context is given, making it incomplete for an agent to use confidently.

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

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

The tool has no parameters, and the schema coverage is trivially 100%. The description does not add parameter semantics, but none are needed. Baseline 3 is appropriate.

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

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

The description states it provides 'operational metrics' but does not specify what kind of metrics or what 'process' it refers to. It gives a general sense but lacks specificity to fully distinguish it from other informational tools like stocktoken_get or stocktoken_list.

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

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

No guidance is given on when to use this tool versus its many siblings. There is no mention of appropriate contexts, prerequisites, or alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It correctly indicates non-custodial operation, the bundled approve and deposit steps, and that no broadcast occurs. This gives the agent critical awareness that the tool only constructs a plan and does not execute it. Missing details include whether the approve action requires prior token approval or if it generates permit signatures, but overall it provides good transparency.

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

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

The description is a single, front-loaded sentence that conveys the core purpose efficiently. It avoids fluff and every phrase adds value. However, the parenthetical '(approve USDG + deposit)' could be slightly clearer (e.g., 'approving USDG and depositing') but remains effective. It strikes a good balance between brevity and 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?

The tool lacks an output schema, so the description should explain the return value (e.g., plan data, transaction request). It does not specify what the plan looks like or how it should be used (e.g., signing and executing). For a plan-building tool requiring subsequent steps, this is a notable gap. Additionally, it doesn't clarify the role of the owner parameter or the approve step's prerequisites, leaving the agent without a complete picture of the workflow.

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

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

Schema description coverage is 50% (assets and assetsHuman have descriptions, owner and approveMax do not). The description adds no extra parameter meaning beyond the schema. It mentions 'approve USDG + deposit' which relates to assets but fails to explain the role of owner or approveMax (e.g., whether approveMax sets unlimited approval). Given the coverage gap, the description should compensate with parameter clarifications but does not.

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 builds a non-custodial ERC-4626 deposit plan involving approve and deposit steps into a specific vault (Morpho Steakhouse Earn). This distinguishes it from sibling tools like stocktoken_morpho_withdraw_plan (opposite direction) and stocktoken_execute_plan (which broadcasts). The verb 'Build' and resource 'deposit plan' are 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 explicitly notes 'Does NOT broadcast', informing the agent that this is a plan-building step requiring subsequent execution (likely via stocktoken_execute_plan). It also names the specific vault and operations (approve USDG + deposit), providing clear context for when to use this tool vs. withdraw or subscribe plans. However, it does not explicitly state when not to use it or list alternative approaches, leaving minor ambiguity.

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

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

No annotations provided, so description carries full burden. It correctly identifies the operation as a read (non-destructive) and specifies the chain and balance types. However, it does not disclose error behavior, permissions needed, or rate limits. Adequate but minimal.

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

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

Single sentence, no filler. Front-loaded with key action and resource. Every word earns its place.

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

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

No output schema exists, so description should hint at return format. It mentions 'share balance and underlying USDG' but does not structure the response (e.g., object with two fields). For a simple read, this is acceptable but incomplete.

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 param description '0x wallet address'. Tool description adds 'a wallet's' which provides context but no new semantics beyond what schema already conveys. Baseline 3 is appropriate.

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

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

Description clearly states verb 'Read' and specific resources: wallet's Morpho Earn (steakUSDG) share balance and underlying USDG on chain 4663. This distinguishes it from sibling tools like stocktoken_morpho_deposit_plan or stocktoken_morpho_status, which are write or status operations.

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

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

No guidance on when to use this tool versus alternatives. It lacks context about when a read is appropriate or how it relates to other Morpho tools. Agent must infer usage from the purpose alone.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns status information (read-only), but does not disclose any behavioral traits like rate limits, authentication requirements, or response size. Adequate for a simple query.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word earns its place; there is no unnecessary 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 no-parameter, no-output-schema tool, the description is complete. It specifies the chain, protocol, and exact data points returned (vault address, TVL, share price), leaving no ambiguity about what the tool provides.

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

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

There are zero parameters, so the baseline is 4. The description does not need to add parameter information, and no further detail is required.

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 status for Morpho/Robinhood Earn on chain 4663, listing specific data (vault address, live TVL, share price). This distinguishes it from sibling tools like stocktoken_morpho_position or deposit plans.

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 siblings. However, the description implies it's for checking the vault's current status, which is a common use case. No exclusions or alternatives 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?

With no annotations, the description carries full burden. It discloses the non-broadcast behavior and non-custodial nature, but does not elaborate on permissions, side effects, or return value. The transparency 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?

Single sentence, front-loaded with verb 'Build', no unnecessary words. Highly concise 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 no annotations, the description is adequate but incomplete. It explains the action but does not describe the plan's structure, return format, or next steps. Could be more detailed to fully guide the agent.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the two modes (withdraw by USDG, redeem by shares) which maps to parameters like assets/assetsHuman and shares/sharesHuman, but does not explicitly map each parameter. Adds moderate value.

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

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

The description clearly states it builds a non-custodial Morpho Earn withdraw or redeem plan, specifying the actions (withdraw/redeem) and resource (Morpho Earn). It distinguishes from siblings like stocktoken_execute_plan by noting it does not broadcast.

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 it is a preparation step by stating 'Does NOT broadcast', but it does not explicitly provide when to use or alternatives. It hints at the workflow but lacks clear guidance on when to choose this tool over 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?

No annotations exist, so description bears full burden. It only states what the tool prepares ('approve + typed data') but does not disclose whether it mutates on-chain state, requires signing, or what the output is. Essential behavioral details are missing for a tool that likely involves off-chain preparation.

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 of 15 words with clear verb-first structure. No extraneous words, front-loads 'Prepare Permit2 approve', and immediately scopes to chain 4663 and Uniswap-style flows.

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 2 parameters and no output schema, the description adequately states purpose and parameters but omits output format, prerequisites, side effects, and chain-specific considerations. Adequate for simple preparation, but gaps exist for full agent understanding.

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

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

Schema coverage is 100% and both parameters are described. The description adds minor context ('to approve via Permit2' for token, 'to normalize for signing' for permitData) but does not significantly exceed the schema's own descriptions. 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 uses specific verb 'prepare' and clearly identifies the resource 'Permit2 approve + optional typed data' for 'Uniswap-style flows on chain 4663'. It stands out among siblings by focusing on a distinct action (Permit2 preparation) not covered by other tools.

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

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

Implies usage for Uniswap-style flows and Permit2 approvals, but lacks explicit when-to-use guidance, exclusions, or references to alternatives (e.g., compare to stocktoken_access_activate). An agent must infer context from the purpose alone.

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

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

With no annotations, the description should disclose behavioral traits. It only lists the returned fields but does not mention that this is a read-only, safe operation, nor does it address authentication requirements or potential failure modes (e.g., if no policy exists). The description is minimal.

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 is front-loaded with the main action and lists key details. No extraneous words, making it highly efficient.

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

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

For a zero-parameter retrieval tool with no output schema, the description adequately explains what the tool returns. However, it could mention that the policy is per-agent or that it requires an active session, given the sibling tools imply a complex system.

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, placing the baseline at 4. The description adds value by enumerating the specific policy fields returned, which helps the agent understand the output format even though there is no output 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 specifies exactly what the tool retrieves ('current AI Agent Tokenized Stock OS agent policy') and lists the policy elements (max notional, slippage, simulate-first, kill switch). This clearly distinguishes it from sibling tools like stocktoken_policy_set and stocktoken_get.

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

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

The description states what the tool does but provides no explicit guidance on when to use it versus alternatives (e.g., stocktoken_policy_set for modification, other get tools for different data). Usage is implied as a read operation, but no exclusions or context are given.

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

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

With no annotations provided, the description alone fails to disclose key behaviors such as side effects, authorization needs, or persistence. It only states the action without 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 a single concise sentence that front-loads the action ('Update'). It is appropriately sized but lacks structure for complex 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 6 parameters, no output schema, and no annotations, the description is too minimal to provide a complete understanding. It fails to cover key aspects like parameter purposes or return values.

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

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

Schema description coverage is 0%, and the description does not explain any of the 6 parameters (e.g., 'killed', 'allowedSymbols'). The description adds no meaning beyond the schema itself.

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 'Update' and the resource 'session policy guardrails', distinguishing it from the sibling 'stocktoken_policy_get' which is likely a getter. However, it could be more specific about what 'guardrails' entails.

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

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

No guidance on when to use this tool versus alternatives like 'stocktoken_session_update' or 'stocktoken_policy_get'. The description lacks explicit context for 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?

Despite no annotations, description discloses that the feed price includes a corporate-action multiplier when Chainlink is configured, adding valuable behavioral context. It implies read-only operation but does not detail return format or error cases.

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, each adding value: core function, preference recommendation, exclusion of brokerage quotes, and behavioral detail. No unnecessary words.

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

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

Given single parameter and no annotations, description provides sufficient context to use the tool, but could improve by specifying parameter format and output characteristics.

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 0% schema coverage, the description does not explain the format of the required 'symbolOrAddress' parameter beyond inferring it relates to Robinhood Stock Tokens on chain 4663. This leaves ambiguity for the agent.

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 'Read USD price and ERC-8056 uiMultiplier for a Robinhood Stock Token on chain 4663', specifying verb, resource, and chain. It also distinguishes from siblings by saying 'Prefer this over generic price tools for Stock Tokens.'

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

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

Explicitly says when to prefer this tool over generic price tools and states 'Not for brokerage stock quotes', providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It states what is returned but does not disclose any behavioral traits such as side effects, permissions, or rate limits. It implies a read-only operation, which is expected, but no further detail.

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, clear sentence with no redundancy. It front-loads the key action and content, 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?

For a zero-parameter tool with no output schema, the description provides sufficient context by listing the specific metadata items returned. It is complete for its simplicity, though it could mention the output type (e.g., addresses, ABI) for extra clarity.

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 no parameters and schema coverage is trivially 100%. The description adds no parameter info, which is acceptable as there are none to document. The baseline of 4 is appropriate.

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

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

The description clearly states the verb 'Return' and the specific resource: metadata for Uniswap Universal Router, PoolManager, WETH, USDG, and feed source on Robinhood Chain 4663. It is distinct from sibling tools that focus on actions like access, execution, or policy management.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites, context, or when not to use it. It is adequate for a simple query tool but lacks explicit usage context.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions 'quote' (suggesting read-only) but does not confirm safety, state changes, permissions, or destructive actions. The order of venue fallback is noted but lacks depth.

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, front-loading the core purpose. However, it contains jargon ('Chain 4663') that may reduce clarity for some agents. Overall, it is economical but could be slightly clearer.

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

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

Given 8 parameters, no output schema, and a complex multi-venue process, the description is grossly incomplete. It omits how to specify amounts, slippage, recipient, return format, and venue selection logic.

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 13% (one parameter 'firm' documented). The description adds no parameter-level explanations. For a tool with 8 parameters, this is insufficient, failing to compensate for the sparse 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 it provides a 'multi-venue quote' for tokenized stocks, listing three specific venues (Uniswap, 0x RFQ, Chainlink). This distinguishes it from siblings like stocktoken_price, though the exact meaning of 'quote' (vs. execution) is implied rather than 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?

No explicit guidance on when to use this tool vs alternatives. The description implies it is for multi-venue quotes but does not compare to other tools like stocktoken_price or explain suitable 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?

Discloses persistence to DATA_DIR and non-custodial nature, which are beyond the schema. But with no annotations, it should describe side effects (e.g., overwrite behavior, auth needs) and doesn't. Adequate but not thorough.

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

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

Two sentences, front-loaded with action and object. No redundant or filler text. Highly efficient given the needed 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?

With 7 parameters, no annotations, no output schema, the description covers very little. Missing: return value, parameter relationships, error conditions, and usage examples. Incomplete 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 description coverage is 0%, so description must explain parameters. It mentions 'scoped permissions' but gives no details on any of the 7 parameters (owner, ttlHours, sessionKey, permissions, etc.). Completely insufficient.

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

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

Clearly states it creates a durable agent session with scoped permissions and non-custodial nature. Distinguishes from sibling session tools (kill, list, update) by specifying creation. Lacks full specificity on 'durable'.

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

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context, or excluded scenarios. Only describes what it does, not when 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 must carry full weight. It states 'immediately' and 'kill switch,' hinting at destructive behavior, but does not disclose side effects (e.g., data loss, reversibility, authentication requirements). For a potentially destructive tool, this is insufficient.

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

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

The description is extremely concise (one sentence, 6 words) and front-loaded with the core action. However, it sacrifices necessary detail for brevity, so it earns a 4 rather than 5.

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

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

Given no annotations, no output schema, and a single parameter with no description, the description fails to provide essential context for a destructive action. The agent cannot determine return format, error handling, or side effects. This is critically incomplete.

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

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

The description provides no information about the 'sessionId' parameter beyond its name. With 0% schema description coverage, the agent must infer from context. No hints on format, source, or validation rules.

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 kills an agent session immediately. The verb 'kill' and phrase 'kill switch' strongly convey the action. Sibling tools like session_create and session_list indicate this is distinct as the termination operation.

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

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

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or warn about consequences. The context implies it's for forced termination but lacks explicit direction.

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. Only states optional filter; no disclosure of return format, pagination, permissions, or side effects.

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

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

Single sentence, no unnecessary words. Front-loaded with action and resource. Highly 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?

Simple tool but lacks context about session semantics, response structure, or business logic. No output schema and no annotations necessitate richer description for 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?

One parameter 'owner' with 0% schema description coverage. Description adds that it is an optional filter, which provides some meaning, but does not specify what owner represents (e.g., email, ID).

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

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

Description clearly states action (list) and resource (agent sessions), with optional filter by owner. Distinguishes from sibling tools like stocktoken_session_create, kill, update.

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

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

No guidance on when to use this tool vs alternatives (e.g., stocktoken_session_create or stocktoken_session_update). Does not mention when filtering is needed 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 must bear the full burden. It only states 'Update' implying mutation, but does not disclose authorization needs, side effects, idempotency, or any other behavioral traits.

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

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

The description is a single concise sentence, but it is overly minimal for a tool with 5 parameters. It is front-loaded with the purpose but lacks structure or elaboration.

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

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

Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, error conditions, whether updates are additive or replace, or any important context for successful invocation.

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

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

Schema description coverage is 0%, and the description does not add any meaning to parameters beyond their names and types in the schema. For a tool with 5 parameters, more explanation is needed.

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

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

The description clearly states the verb 'Update' and resource 'limits/permissions on an existing session', distinguishing it from siblings like session_create, session_kill, and session_list.

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

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

No guidance on when to use this tool versus alternatives, prerequisites, or when not to use. The description provides no usage context.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool performs a simulation and checks allowlist, policy, and quote integrity, indicating it is likely read-only. However, it does not mention permissions, rate limits, or whether state changes occur.

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 is front-loaded with the main action and includes key details (chain, checks). No unnecessary words.

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

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

Given the complexity of 7 parameters and no output schema, the description is insufficient. It does not explain return values, parameter formats, or how to interpret results. The agent would lack essential information.

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

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

Schema coverage is 0%, and the description provides no explanation of the seven parameters (e.g., tokenIn, amountIn, tokenOut, sessionId, notionalUsd, slippageBps, amountInHuman). This is a critical gap for an agent to use the tool correctly.

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

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

The description clearly specifies the verb 'Simulate' and the resource 'tokenized stock swap on chain 4663', listing specific checks (allowlist, policy, multi-venue quote integrity). This distinguishes it from siblings like stocktoken_quote or stocktoken_execute_plan.

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 it is a pre-trade check but does not explicitly state when to use it versus alternatives (e.g., stocktoken_quote for quotes, stocktoken_find_pools for discovery). No exclusion criteria or context for 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?

Without annotations, description mentions 'non-custodial' and 'Pays treasury on chain 4663', adding behavioral context. However, it doesn't specify whether the build is a simulation or actual on-chain transaction, required permissions, or side effects like ETH transfer.

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 packs key info: action, resource, non-custodial nature, parameter options, and on-chain behavior. Efficient but slightly dense; could benefit from line breaks for readability.

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

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

Covers purpose and parameter usage but omits return value, error states, prerequisites (e.g., wallet connection), and relationship to sibling tools. Without output schema, a hint about what the tool returns 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?

Description reinforces schema's parameter hints for tier and ethAmount, but owner (required) lacks any description in schema or text. With schema description coverage at 67%, the description adds marginal value but fails to clarify owner's purpose.

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 states 'Build non-custodial ETH subscription plan', clearly indicating the action and resource. It distinguishes from siblings like stocktoken_subscription_tiers (which lists tiers) and stocktoken_execute_plan (which executes). However, it doesn't explicitly differentiate from other plan-building tools like stocktoken_morpho_deposit_plan or stocktoken_tip_plan, leaving some ambiguity.

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

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

No guidance on when to use this tool vs. alternatives such as stocktoken_tip_plan or stocktoken_morpho_deposit_plan. It implies usage via tier/custom ETH but doesn't specify context or exclusions.

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

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

With no annotations, the description must fully convey behavior. It implies a read-only on-chain query but does not disclose potential side effects (likely none), authentication requirements, rate limits, or failure modes. The deployment note is parametric, not behavioral.

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

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

The description is a single sentence with no redundancy. However, it could convey more information without becoming verbose, such as clarifying the parameter or return value. It earns a high score for conciseness but not perfect due to missing context.

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 one parameter and no output schema, the description should explain what 'subscription status' entails, what the returned data looks like, and how the owner parameter is interpreted. The current text is too brief to be fully actionable for an agent.

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

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

Schema coverage is 0%, and the description adds no meaning to the sole parameter 'owner'. It does not specify what the owner represents (wallet address?), its format, or constraints beyond the schema's type string. This is a critical 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 action ('Check on-chain subscription status') and the resource ('for a wallet'). The name 'subscription_status' aligns with this purpose. However, it does not explicitly differentiate from sibling tools like 'stocktoken_subscription_tiers' or 'stocktoken_subscribe_plan', though the verb 'check' implies a read operation.

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

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

No guidance on when to use this tool versus alternatives, prerequisites, or exclusions. The parenthetical about SUBSCRIPTION_REGISTRY_ADDRESS is a deployment constraint, not usage guidance. A clearer usage context would improve the score.

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 indicates a read-only operation ('List'), but does not disclose authentication needs, return format, or side effects. For a zero-parameter list tool, this is minimally adequate but lacks depth.

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

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

The description is a single sentence with 12 words, front-loading the key action and resource. Every phrase earns its place, with no fluff.

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

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

Given no output schema and no annotations, the description should provide more context about the return structure or prerequisites. It only describes what is listed, not how the listing is presented (e.g., fields, pagination, or data source).

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

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

The input schema has 0 parameters with 100% coverage, so the description need not add param info. However, it adds meaning by specifying the content (on-chain, paid in ETH, no Stripe), which goes beyond the schema. Baseline for 0 params is 4.

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

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

The description clearly states the verb ('List') and resource ('AATOS on-chain subscription tiers'), and adds distinguishing context ('paid in ETH to treasury. No Stripe.'). This differentiates it from sibling tools like stocktoken_subscription_status or stocktoken_subscribe_plan.

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

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

The description provides no explicit guidance on when to use this tool vs alternatives. The sibling list is large and includes many related tools, so a phrase like 'Use to view available tiers before subscribing' would help, but it's missing.

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

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

No annotations provided, so the description bears full burden. It lists output contents but does not disclose any behavioral traits such as whether the operation is read-only, requires authentication, has rate limits, or is expensive. A read-only status is implied but not explicitly stated. Score 2 for insufficient behavioral disclosure beyond a simple list.

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

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

The description is a single, efficient sentence that front-loads the purpose and lists key output components. Every word earns its place with no redundancy. Score 5 for perfect conciseness.

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

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

With no output schema, the description should explain return values more thoroughly. It lists field names (e.g., 'secrets, venues, chain') but not their types or meanings. For a status tool of moderate complexity, this is adequate but not complete. Score 3 as it provides a minimum viable outline.

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

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

There are zero parameters, and schema coverage is 100% (empty). The description does not need to add parameter meaning. Baseline score of 4 applies because there are no parameters to describe. The description adds value by listing output fields, which is unnecessary for params but harmless. Score 4.

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

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

The description clearly states it provides 'full system status' and lists specific components (secrets, venues, chain, etc.). It implies aggregation of multiple status aspects, which distinguishes it from more specific sibling tools like stocktoken_fees or stocktoken_price. However, it could explicitly differentiate from other status tools (e.g., stocktoken_access_status). Score 4 for clear verb+resource but slight ambiguity in differentiation.

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

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

No guidance on when to use this tool versus alternatives. Among siblings, there are several status-specific tools (e.g., stocktoken_morpho_status, stocktoken_subscription_status), but the description does not mention when to prefer this comprehensive status over those. Score 2 for no usage context or exclusions.

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

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

No annotations are provided, so the description carries full burden. It does not disclose read-only nature, authentication needs, side effects, or response format. The description is merely informational about acceptance, not behavioral.

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

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

Single sentence that is informative and front-loaded. However, it could be more active (e.g., 'List accepted assets'). Still concise with no redundant words.

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

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

Given no output schema and zero parameters, the description adequately explains what the tool covers. However, it does not specify what the tool returns (list of assets, a confirmation, etc.), leaving some ambiguity.

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

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

There are zero parameters, so the description does not need to compensate for schema gaps. It adds meaning by explaining the tool's purpose, including the optional BTC address nuance, 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 resource (AATOS tip wallet) and what assets it can accept (native ETH, any ERC-20 on Robinhood Chain 4663, optional BTC). It distinguishes from sibling tools like stocktoken_tip_plan and stocktoken_tip_presets, which deal with tipping plans and presets respectively.

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

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

No guidance on when to use this tool vs alternatives. It does not mention prerequisites, when not to use it, or how it relates to other tipping-related tools.

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

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

No annotations are provided, so the description must disclose all behavioral traits. It only reveals that the tool builds a plan and that user confirmation is needed, but fails to mention side effects (e.g., storage, state changes), permission requirements, or rate limits. For a tool that likely involves financial transactions, this is insufficient.

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

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

The description is very concise, consisting of two short sentences. The first sentence immediately states the action and resource, followed by a compact list of assets. The second sentence covers amount options and a key behavioral note. No redundant words; every part contributes meaning.

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

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

Given the tool's complexity (6 parameters, no output schema, financial context), the description is adequate but incomplete. It explains asset options and the amount/preset interplay, but does not describe the plan's return format, how to execute it, or the role of the required 'owner' parameter. It also omits explanation of 'memo' and 'ethAmount'.

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 83% schema description coverage, the schema already documents most parameters. The description adds extra value by stating that 'asset=ETH (default)' (not in schema) and clarifying the relationship between 'amount' and 'preset' (ETH only). It also reminds that the tool should never coerce, which is behavioral but relevant for the 'amount'/'preset' choice.

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 an 'OPTIONAL tip plan' and enumerates acceptable assets (ETH, BTC, registry symbols, 0x tokens). It provides the action verb 'Build' and resource 'tip plan', but does not explicitly differentiate from sibling tools like 'stocktoken_execute_plan' or 'stocktoken_tip_presets', missing an opportunity to clarify its role in the workflow.

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 offers some usage guidance: it hints that the plan is optional and requires user confirmation ('User must confirm. Never coerce.'). It also shows example asset formats. However, it lacks a clear statement of when to use this tool versus alternatives (e.g., executing a plan or setting presets), and does not specify prerequisites or conditions for use.

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

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

No annotations are provided, so the description must carry full weight. It discloses the main behavior (listing presets and accepted assets) and notes that tips are never required, implying a read-only, non-destructive nature. However, it lacks detail on authorization needs, side effects, or return format.

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 efficiently conveys the tool's purpose and a key detail (tips never required). It is front-loaded with the verb and resource, with no unnecessary 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 or output schema, the description adequately covers the tool's function and a key constraint. It could be slightly improved by clarifying whether presets are user-specific or global, but it is largely complete for a simple list operation.

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

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

There are no parameters (0 params, 100% schema coverage), so the baseline is 4. The description adds value by explaining what the list contains, which is the only relevant information since no parameters 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 tip presets and accepted assets, specifying the verb 'List' and the resources (tip presets, accepted assets). It is specific about asset types (ETH, ERC-20 on 4663, optional BTC), but does not explicitly differentiate from sibling tools like stocktoken_tip_assets.

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 minimal usage guidance, only noting that tips are never required. It does not explain when to use this tool vs alternatives such as stocktoken_tip_assets or stocktoken_tip_plan, nor does it provide context on prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden. It describes a read operation ('Value') but does not explicitly state it is non-destructive, disclose permissions, rate limits, or error behavior. The description adds minimal behavioral context beyond the core 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 two sentences, front-loaded with purpose and context. Every word earns its place; there is no fluff or redundancy.

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

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

For a simple valuation tool with no output schema and two parameters, the description provides the chain and use case but lacks explanation of the return format (e.g., total value in USD, per-asset breakdown). This gap reduces completeness for an agent that needs to interpret the 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?

Schema description coverage is 50% (only 'owner' has a description). The description adds context that balances are of Stock Token/ETF/USDG, implying the 'symbols' parameter filters by these asset types, but it does not explicitly define the parameter's format or allowed values. This partially compensates but not fully.

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

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

The description clearly states the tool's function: 'Value a wallet's Stock Token / ETF / USDG balances on Robinhood Chain 4663.' It specifies the verb ('value'), resource ('balances'), and context ('for portfolio analysis of onchain RWA holdings'), distinguishing it from sibling tools that handle access, pricing, or execution.

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 clear use case ('Use for portfolio analysis of onchain RWA holdings') but does not explicitly state when not to use the tool or mention alternative tools. However, given the sibling list, no other tool performs valuation of holdings, so the guidance is adequate.

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