AI Agent Tokenized Stock OS

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

No annotations provided, so description carries burden. It discloses payment method and lack of Stripe but does not mention side effects, auth needs, or rate limits. For a read-only listing, this is adequate but not detailed.

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

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

Single sentence, clear and front-loaded with key information. 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 no output schema and simple nature, description covers the listing of tiers and payment info. Missing detail on filtering or currency as of time, but sufficient.

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

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

No parameters (0 params, 100% schema coverage). Description adds no param info but baseline is 4 for zero-param tools.

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

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

Description clearly states it lists Free/Pro/Team pricing and specifies payment method (ETH on-chain, no Stripe), distinguishing it from siblings like _fees and _price. Verb 'List'+resource 'pricing' is specific.

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

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

Describes when to use (view pricing and payment info), but does not explicitly mention when not to use or alternatives. Sibling context is provided but no 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 the full burden. It does not explicitly state that the tool is read-only, nor does it disclose any side effects or data freshness guarantees. 'Vault scaffold preview' hints at a test mode but is vague.

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

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

The description is a single 13-word sentence that front-loads the core action and resource, with zero wasted words.

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

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

Given no output schema and no annotations, the description provides minimal context. It states the tool's purpose but doesn't describe the structure of returned data or how to interpret the preview. More detail on what 'constituents and live prices' includes would improve completeness.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information, and none is missed.

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 previews AI mega-cap basket constituents and live Chainlink prices. It uses a specific verb 'Preview' and identifies the resource, distinguishing it from sibling tools like stocktoken_list 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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or context for using this preview over other basket-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?

Discloses key behavioral traits: does not sign or broadcast, specifies chain 4663, and indicates non-custodial nature. With no annotations, the description provides useful transparency beyond the bare minimum.

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

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

Two sentences, front-loaded with purpose and constraints. Every sentence is essential and concise.

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

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

Given 9 parameters, no output schema, and no annotations, the description lacks explanation of return values, parameter usage, and how the plan is consumed. Incomplete for effective tool use.

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

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

Schema coverage is 0% with no descriptions for 9 parameters. Description adds no parameter details; fails to compensate for schema gap.

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

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

Clearly states it builds a non-custodial tx plan for approve+swap via best venue, and specifies it does not sign or broadcast. Distinguishes from siblings that might sign or 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?

Implies usage when needing to build an approve+swap plan, but lacks explicit guidance on when not to use or when to prefer siblings. No alternatives mentioned.

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

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

No annotations provided, so the description must disclose behavioral traits. It correctly indicates the tool is informational (explain), but it does not mention that it is read-only, non-destructive, or any rate limits. The simplicity of the tool partially excuses this, but more explicit transparency about its safe nature would improve clarity.

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 perfectly captures the tool's purpose with no redundant words. The structure directly states what the tool does, earning its place without filler.

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

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

Given the tool's simplicity and lack of output schema, the description is adequate for understanding the core function. However, it fails to explain the input parameter or expected output, leaving gaps for effective invocation. A more complete description would include parameter guidance.

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

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

The schema has one parameter 'userIntent' with 0% description coverage. The description does not mention or explain this parameter, leaving the agent to guess its purpose. The parameter is optional, but its meaning and expected values are entirely undocumented in both schema and description.

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

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

Description clearly states the tool's purpose: explaining when to use three specific systems (Tokenized Stock OS, Robinhood MCP, Uniswap/0x). The verb 'explain' and resource 'routing' are specific and distinguish it from sibling tools that perform actions like activation, execution, or listing.

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

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

Description implies the tool is for decision-making among the mentioned systems. While it does not explicitly state when not to use it or compare to siblings, the context is clear that this tool provides guidance on routing. The lack of explicit exclusions or alternatives prevents a perfect 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?

The description indicates a read-only summarize action, but with no annotations, it fails to disclose behavioral traits like potential delays, access restrictions, or error conditions. A more detailed description of the summary's scope or limitations would improve transparency.

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

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

The description is a single sentence that efficiently conveys the tool's purpose without extraneous 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 no output schema, the description should explain what the summary returns. It mentions 'disclosed AATOS execution fee events' and 'on-chain monetization status', but lacks specifics on structure or examples, leaving the agent with incomplete understanding of 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. It correctly implies no user input is required beyond invoking the tool.

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, which is a specific verb-resource combination. However, it does not explicitly differentiate from sibling tools like stocktoken_price or stocktoken_metrics, leaving some ambiguity about its unique role.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as stocktoken_price for pricing or stocktoken_metrics for general metrics. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description bears full burden for behavioral disclosure. The description only states the action and context; it does not disclose side effects, authorization requirements, rate limits, or what happens on failure. For a scanning tool, it is likely read-only but unconfirmed.

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 first sentence delivers the core action, and the second adds contextual value. It is front-loaded and efficient.

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

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

The description lacks important details: output format, pagination, error handling, or how the returned pools are structured. Given no output schema, these details would help an agent use the tool correctly. The description is too brief for a tool that interacts with a blockchain 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 no descriptions for tokenA or tokenB, and coverage is 0%. The description implies they are tokens (e.g., addresses or symbols) but does not specify format or constraints. This adds minimal meaning beyond the schema's empty string type.

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 a specific chain (4663). The verb 'scan' and resource 'pools' are explicit, and the mention of stock tokens provides context. However, it does not explicitly differentiate from sibling tools like stocktoken_liquidity_matrix or others that might also relate to pools.

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

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

The description includes a use-case scenario ('Useful when APIs block Stock Tokens'), which gives some guidance. But it lacks explicit instructions on when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned.

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

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

No annotations provided, so description must carry burden. It implies read-only metadata retrieval and specifies the blockchain (Robinhood Chain 4663). However, it doesn't disclose response shape, error behavior, or whether tokens are cached.

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

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

Two sentences, no fluff. Front-loaded with action and purpose. 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, so description should compensate by hinting at return fields. It says 'metadata' but doesn't list examples (e.g., name, symbol, decimals). A more complete description would mention typical fields or link to documentation.

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 one parameter. Description adds value by explaining that 'symbolOrAddress' accepts ticker (e.g., NVDA) or 0x contract address, and specifies the chain, going beyond the schema's terse description.

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

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

Description clearly states the action ('Get metadata'), resource ('one canonical Stock Token or core asset'), and query methods (symbol or contract address). It distinguishes from sibling tools like stocktoken_list (multiple tokens) and stocktoken_price (price-specific).

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

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

Provides explicit use case: 'verify a token is official before trading.' While it doesn't exclude other use cases or mention alternatives, the context is clear and actionable.

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

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

No annotations exist, so the description carries full burden. It mentions offchain authorization and later onchain verification, but fails to disclose authorization requirements, idempotency, or whether the tool actually submits anything onchain. More context on side effects or lack thereof would improve transparency.

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

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

Two sentences, front-loaded with verb ('Build') and noun ('EIP-712 typed data'). No filler words. Every sentence is essential.

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 no annotations, the description is insufficient. It does not explain how to set parameters like nonce, deadlineSec, or how the typed data is returned. For a tool involved in a complex workflow, more context is needed.

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

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

Schema description coverage is only 13% (only tokenIn has a description). The description adds no parameter-specific meaning beyond the schema, leaving 7 of 8 parameters unexplained. With low coverage, the description should compensate 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 the tool builds EIP-712 typed data for an agent trade intent, an offchain authorization standard. It specifies the process (user signs, onchain verifier later) and distinguishes from siblings by focusing on intent authorization.

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

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

The description implies usage for offchain authorization before an onchain trade, but does not explicitly state when to use or avoid it, nor does it mention alternative tools among the many siblings (e.g., execute_plan, simulate).

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 mentions 'Liquidity / V3-executable route matrix' implying a read-only query, but lacks details on side effects, rate limits, or output characteristics.

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

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

Two sentences, zero waste, front-loaded with key information. Every word serves a purpose.

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

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

Given no output schema and no annotations, the description is brief but covers the basic purpose. However, it does not explain the format of the 'matrix' or how the data is structured, leaving some ambiguity for 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?

There are no parameters (schema coverage 100% with zero params). The description adds value by specifying the scope ('major USDG pairs on chain 4663'), which is helpful context beyond the empty schema.

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

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

Description clearly states the tool provides a liquidity/route matrix for USDG pairs on chain 4663, and its purpose is to know which Stock Tokens have live AMM fills. This is specific and distinguishes it from sibling tools like pricing or quotes.

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

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

Explicitly says 'Use to know which Stock Tokens have live AMM fills,' providing clear context for usage. However, it does not mention when not to use it or contrast with similar tools like stocktoken_find_pools or stocktoken_quote.

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

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

No annotations provided, so the description carries full burden. It discloses that the tool lists 'canonical' tokens and that only registry addresses are real, implying a read-only, safe operation. However, it does not discuss authentication, rate limits, or whether results are cached.

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

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

Three sentences, front-loaded with purpose, no redundant text. Every sentence adds value or clarification.

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

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

No output schema is present, and the description does not explain what the list returns (e.g., addresses, symbols, or names). Given the complexity (multiple token kinds) and no output details, the description leaves some gaps for 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 100% with a single 'kind' parameter fully described in the schema (enum and description). The description does not add extra meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'list' and the resource 'canonical tokenized stocks (Robinhood Stock Tokens), ETFs, USDG, and WETH' on a specific chain. It distinguishes the tool from US brokerage equities by specifying a separate MCP, and the sibling tools indicate a focused listing function.

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

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

Explicitly states when to use ('AI agents trading tokenized equities/RWAs') and when not to use ('Do NOT use for US brokerage equities') with a direct alternative ('use Robinhood Trading MCP'). Also clarifies that only registry addresses are real tokenized stocks.

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

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

No annotations are provided, so the description carries full burden. It discloses the returned data (vault address, TVL, share price) but does not specify whether the operation is read-only, real-time, or has any behavioral traits like rate limits or caching.

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 sentence that is concise and front-loaded, containing no wasted words. Every word earns its place.

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

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

Despite having no output schema, the description fully enumerates what the tool returns: vault address, live TVL, share price. For a simple status tool with no parameters, this is adequately complete.

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

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

Tool has no parameters. With 0 parameters, the baseline score is 4 per rubric. No additional parameter semantics 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 tool provides status (vault address, TVL, share price) for a specific vault on chain 4663. It distinguishes itself from sibling tools like stocktoken_morpho_position or stocktoken_morpho_deposit_plan by focusing on status metrics.

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

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

The description implies usage for checking current status but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions 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?

No annotations are provided, so the description carries full burden. It mentions what the policy includes but does not explicitly state it is read-only or require authentication. 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?

Single sentence, 15 words, front-loaded with action, no wasted words. Efficient and clear.

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

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

Given the tool's simplicity (no params, no output schema), the description fully covers its purpose and return contents. Complete 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?

Input schema is empty with 0 parameters. Schema coverage is 100% (vacuously), baseline is 3, but no parameters need description. The description adds value by listing return value components.

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 retrieves the current agent policy and lists specific components (max notional, slippage, simulate-first, kill switch). Distinguishes itself from sibling tool stocktoken_policy_set.

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

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

While the name and sibling setter imply its purpose, the description does not explicitly state when to use this tool over alternatives or provide usage 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?

Discloses the multi-venue fallback order (Uniswap then 0x RFQ then Chainlink) and that it's on chain 4663. With no annotations, it partially covers behavioral traits but omits side effects, permissions, or whether the quote is indicative vs firm (though a parameter hints at firm).

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 single-sentence description is concise and front-loaded with the core purpose, containing 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?

With 8 parameters and no output schema, the description is too brief. It does not explain what the tool returns (e.g., price, liquidity) or cover required parameters, error handling, or any contextual details needed for effective use.

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

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

Only 13% of parameters have schema descriptions (just 'firm'). The description does not explain key parameters like 'tokenIn', 'tokenOut', 'amountIn', etc., leaving the AI to infer from names. Given low schema coverage, the description fails to compensate.

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

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

The description mentions 'multi-venue quote' and lists specific sources (Uniswap, 0x RFQ, Chainlink) and the chain ID, making it clear the tool retrieves quotes for token pairs. However, it lacks an explicit verb (e.g., 'get' or 'fetch') and does not differentiate from sibling tools like '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?

No guidance on when to use this tool versus alternatives such as 'stocktoken_price' or 'stocktoken_execute_plan'. There is no mention of prerequisites, 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 provided; description only hints at persistence and non-custodiality but omits behavioral details such as authentication, rate limits, idempotency, or error states.

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

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

Single sentence is concise but lacks essential structure and detail; front-loads purpose but fails to convey necessary parameter or behavioral 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?

Tool has 7 parameters and no output schema, yet description covers none of these; missing rationale for parameters and return value, leaving agent underinformed.

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

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

Schema description coverage is 0% and description provides no parameter-specific information; terms like 'scoped permissions' are vague and do not explain any of the seven parameters.

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

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

Description explicitly states 'create a durable agent session with scoped permissions' and distinguishes from sibling session tools by mentioning persistence and non-custodial nature.

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

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

No guidance on when to use this tool vs alternatives like session_kill or session_list; lacks context for choosing session creation over other session management 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 behavioral traits. It states 'kill' (destructive) but omits details like whether sessions can be recovered, effects on associated resources, or required permissions.

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

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

Single 7-word sentence that is extremely concise and front-loaded. No wasted words.

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

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

For a simple tool with one parameter, the description offers a basic functional statement. However, no return value, side effects, or error conditions are mentioned, which is a gap for a destructive action.

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

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

Schema documentation coverage is 0%; the input schema has no description for the required sessionId parameter. The tool description does not explain the parameter's meaning or expected format, relying solely on the parameter name 'sessionId'.

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

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

Description clearly states the action (kill) and the resource (agent session) with a parenthetical 'kill switch' for emphasis. It is specific and distinguishes from siblings like session_create, session_list, session_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. The description implies immediate termination but does not mention prerequisites, side effects, or context for safe 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. The description does not disclose behavioral traits such as idempotency, merge vs. overwrite behavior, or prerequisites like session activity status.

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, concise and front-loaded. However, it sacrifices essential detail for brevity.

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

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

Given 5 parameters, no output schema, no annotations, and 0% schema coverage, the description is severely incomplete. It fails to provide sufficient context for proper tool 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%. The description only mentions 'limits/permissions' but does not explain any of the five parameters (sessionId, permissions, maxNotionalUsd, allowlistSymbols, maxDailyNotionalUsd) despite the schema providing names and types.

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 ('Update') and the resource ('limits/permissions on an existing session'). It distinguishes from sibling tools 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?

The description implies usage when needing to modify an existing session's settings, but does not provide explicit when-to-use or when-not-to-use guidance, nor mentions 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 discloses what checks are performed (allowlist, policy, quote integrity) but does not clarify if the operation is read-only, has side effects, or requires authentication. The term 'simulate' suggests no state change but 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 with no filler, efficiently stating purpose and scope. However, it could benefit from structured bullet points or separation of concerns 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 7 parameters, no output schema, no annotations, and many sibling tools, the description is insufficient. It does not explain what the simulation returns, how to interpret results, or prerequisites. Users are left to guess parameter formats or tool behavior.

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 adds no meaning to any of the 7 parameters. The names 'tokenIn', 'tokenOut', 'notionalUsd', etc. are self-explanatory, but the description does not explain their role or constraints beyond the schema.

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

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

The description specifies the action ('simulate/pre-trade check'), the resource ('tokenized stock swap on chain 4663'), and key aspects checked (allowlist, policy, quote integrity). It clearly differentiates 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 usage as a pre-trade step but does not explicitly state when to use vs alternatives or provide conditions for use. No 'when not to use' or alternative tool references.

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 must fully disclose behavior. It only states it 'checks' on-chain status, implying a read-only operation, but does not explain what the status entails, output format, or any 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 superfluous words. Front-loaded with the key action and resource. Perfectly 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?

For a simple one-parameter read tool, the description covers basic purpose and a deployment constraint. However, it omits details about the returned status and any response structure, leaving the tool somewhat 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 description coverage is 0% (owner parameter undocumented). The description adds 'for a wallet', hinting owner is a wallet address, but does not explicitly define the parameter or its expected format. Partially compensates but could be clearer.

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

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

The description clearly states the verb 'Check' and the resource 'on-chain subscription status for a wallet'. It is specific and distinct from sibling tools like stocktoken_access_status or stocktoken_morpho_status.

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

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

No explicit guidance on when to use this tool versus alternatives. It mentions a prerequisite (SUBSCRIPTION_REGISTRY_ADDRESS when deployed) but does not provide context for selection among multiple status tools.

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

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

No annotations provided, so the description carries full burden. It mentions confirmation and avoidance of coercion, but does not disclose side effects, permissions, idempotency, or what happens upon invocation (e.g., creates a draft plan). Lacks key behavioral details.

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

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

Extremely concise: two sentences containing all essential information. Front-loaded with the primary purpose. No wasted words.

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

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

Missing output schema, and the description does not explain return values or follow-up steps. Required parameter 'owner' is not mentioned. With 6 parameters and sibling tools for assets/presets, the description lacks completeness for full autonomous use.

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

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

Schema coverage is 83% with descriptions for most parameters. The description adds value by clarifying asset defaults (ETH), valid formats (registry symbol, 0x address), and the 'amount or ETH preset' relationship. This enhances understanding beyond the schema.

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

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

The description clearly states 'Build OPTIONAL tip plan' with specific verb and resource. It lists asset types and mentions confirmation, distinguishing it from sibling tools like stocktoken_tip_assets (list assets) and stocktoken_tip_presets (list presets). However, it does not explicitly differentiate from all siblings.

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

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

No explicit guidance on when to use this tool vs alternatives (e.g., stocktoken_execute_plan). The description only says 'User must confirm. Never coerce,' which is behavioral, not usage. Sibling tools exist but are not referenced.

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 indicates a read operation ('value') with no side effects, but it does not disclose potential failure modes (e.g., wallet not found, unsupported tokens), authentication needs, or rate limits. The behavior is straightforward but minimally documented beyond the core purpose.

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

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

The description is two concise sentences with no redundancy. It front-loads the core action and resource, then adds context. Every word serves a purpose.

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

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

Given the tool has 2 parameters (one required), no output schema, and no annotations, the description should explain the symbols parameter and hint at the return format (e.g., total value in USD?). It mentions the use case but leaves gaps: what does the output look like? How are multiple tokens aggregated? This is adequate for a simple tool 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 50% (owner has a brief description, symbols has none). The tool description does not explain the symbols parameter at all, which is important for understanding how to filter or specify which token balances to value. The description adds no value beyond what the schema provides for owner, and does not compensate for the missing schema documentation.

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

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

The description clearly states it values a wallet's Stock Token/ETF/USDG balances on a specific chain (Robinhood Chain 4663). The verb 'value' and resource 'balances' are specific, and the mention of 'portfolio analysis' adds context. However, it does not explicitly distinguish from siblings like stocktoken_price or stocktoken_get, which might also provide valuation but likely for single 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 says 'Use for portfolio analysis of onchain RWA holdings,' which implies the intended context but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools.

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