quantifyme

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already declare safety. The description adds rich behavioral context: no signup required, public data, sorting behavior (best-first), and that it mirrors the community page. This significantly expands on annotations.

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

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

Well-structured with main purpose first, then use case flow, parameter details, and return format. All sentences are informative, though the description is somewhat lengthy; still earns its place.

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

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

For a browse/list tool with 2 simple parameters and a full output schema described, this is highly complete. It covers return structure (scripts, count, metric), script fields (id, username, title, etc.), and metrics. No gaps 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?

Schema coverage is 0%, so description must compensate. It fully explains limit (default 20, max 200) and sort (list of options, defaults, and meaning of each metric like 'composite', 'ret', 'wr'). Provides context about mirroring the community page columns.

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

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

The description explicitly states it browses the public community leaderboard of published strategies ranked by composite score. It distinguishes from sibling tools like find_strategy (search) and one_shot (deploy) by describing the copy-trade flow.

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

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

Clearly indicates when to use: to find a top strategy for deployment via one_shot. Mentions no authentication needed. Lacks explicit when-not-to-use or alternative comparisons, but provides clear integration 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds context about mirroring a landing experience, returning match or null, and a suggestion sentence. It also explains the output structure and how to use community_id. No contradictions.

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

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

Well-structured with sections for purpose, usage, args, and returns. Somewhat long but all content is valuable for correct tool invocation. Could be slightly tighter, but it earns its length.

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

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

Description fully covers the tool's role in the workflow, details all input parameters with examples, and describes the return dict comprehensively. Given the presence of an output schema and sibling tools, the description is complete and actionable.

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?

Despite 0% schema description coverage, the description explains each parameter in detail: description with example, symbol with list of allowed values, timeframe with granularities. This adds significant meaning beyond the plain 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 'Find an existing PROVEN strategy that matches a plain-English idea' and explains the resulting choice (deploy existing or generate fresh). It distinguishes itself from siblings like generate_strategy and one_shot by specifying its role as a discovery step.

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 instructs 'CALL THIS FIRST when a user describes a strategy idea' and provides detailed conditional logic: present match, ask user, then call one_shot with appropriate arguments depending on choice. Also clarifies behavior when no match is found.

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

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

Annotations indicate openWorldHint=true and readOnlyHint=false, suggesting side effects. The description does not explain that the tool uses an AI model (implied by claude_model) or that it may call external APIs. It also does not describe the return format or side effects, such as saving generated code. Given the annotations carry some burden, the description fails to add sufficient 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 front-loaded with the purpose, but the parameter list is lengthy and could be more structured (e.g., bullet points). Every sentence is informative, but the length is borderline excessive for a tool description.

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 params, 0 required, output schema exists), the description covers purpose and parameters reasonably. However, it lacks differentiation from sibling tools like get_strategy_code (retrieval) or one_shot (generation with backtest). No usage examples are provided, and the output format is left to the output schema. Completeness is adequate but not thorough.

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

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

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 8 parameters, including defaults, enumerated values for symbol and timeframe, and guidance that 'description' is the primary request. This adds significant meaning beyond the bare schema, earning a 4.

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

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

The description clearly states 'Generate Python strategy code (no training/deploy)' and 'Use when the user wants raw code.' This conveys a specific verb (generate) and resource (strategy code), distinguishing it from siblings like get_strategy_code or one_shot. However, it does not explicitly contrast with all siblings, so a 4 is appropriate.

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

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

The description provides context ('Use when the user wants raw code') and notes that the 'description' parameter is treated as the primary user request. However, it does not mention when not to use this tool or suggest alternatives among siblings, leaving some ambiguity.

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

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

Annotations indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds crucial behaviors: it BLOCKS until finish (~2.5 min), returns pending:true on timeout, and does not render a card. No contradiction with annotations.

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

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

The description is well-structured with paragraphs and bullet points, front-loading the main purpose. While fairly long, every sentence provides necessary information. Could be slightly more concise but overall effective.

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 (blocking, async, multiple result cases), the description covers the return dict with all fields, error/timeout handling, and community-source behavior. The output schema exists, and the description adequately supplements it.

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 sole parameter `job_token` has 0% schema description coverage. The description adds meaning by stating it is 'the token returned by one_shot', linking to the sibling tool. This is helpful but minimal, thus a score of 3.

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

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

The description clearly states the tool's purpose: 'Wait for a `one_shot` deploy to finish and return its final result.' It specifies the action (wait and return result), the resource (deploy result), and distinguishes from sibling `get_model_chart` by noting it does not render another card.

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

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

The description provides explicit guidance: call ONCE after `one_shot`, do not use `get_model_chart`, handle timeout by calling again, and specific instructions for community-source deploys. It clearly states when to use and what to avoid.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral details: rendering difference between ChatGPT (interactive widget) and Claude (artifact), and the structured output includes trade log and stats. No contradictions.

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

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

Description is front-loaded with purpose, usage, parameter explanation, and return value. Each sentence adds distinct value without redundancy. Despite length, it is well-organized 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 the simple single-parameter tool and presence of an output schema, the description thoroughly covers behavior, output structure (even detailing keys like exit_reason values), and platform-specific behavior. No gaps.

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

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

Schema coverage is 0%, but the description explains the 'stem' parameter with an example and its source (list_models/one_shot). This adds meaning beyond the bare schema, but could further specify format or constraints.

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

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

Description uses specific verb 'Visualize' and resource 'trained model's backtest', clearly distinguishing it from sibling tools like list_models and one_shot by focusing on the chart view.

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 to use after one_shot or list_models with the model's stem, and explains it shows the user how it traded, including context like 'is it actually any good' view. No mention of when not to use, but the guidance is very clear.

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

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

Discloses that price is from close of most recent 1-minute bar (not raw live tick), explains the stale flag (15 min threshold), and notes FX market weekend closures. This goes beyond annotations (readOnlyHint, openWorldHint) by detailing the data source and staleness behavior.

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?

Well-structured with a summary line, context paragraph, and explicit Args/Returns sections. Slightly wordy but every sentence adds value. Could be more concise but remains 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 (1 optional param, no required params) and the presence of an output schema (implied by return description), the description covers all necessary aspects: input, behavior, output fields. No gaps for an agent to understand invocation and results.

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

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

Despite 0% schema description coverage, the description fully explains the 'symbol' parameter: lists all valid G7 pairs, states default EURUSD, and implies it's optional. This completely compensates for the schema gap.

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

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

Clearly states it gets the latest price for a G7 FX pair as a 'quick check'. Distinguishes from siblings like get_deploy_result or get_strategy_code which serve different purposes.

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

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

Explicitly says 'Useful for context before deploying a strategy', providing a clear use case. Does not mention alternatives or when to avoid, but given the tool's simplicity, this is adequate.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds context: no signup needed, returns specific fields including code, and instructs to show the code and offer to deploy. No contradiction with annotations.

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

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

Description is efficient, front-loaded with main action, then usage context, parameter, and returns. Slightly verbose with the 'SHOW the code...' instruction, but still concise overall.

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 existence of output schema, description explains return fields in dict and workflow (use after browse_community, show code, offer to deploy). Complete for agent decision-making.

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, but description fully explains the parameter: 'community_id: The `id` of a community entry (from `browse_community`).' This provides clear meaning and source, fully compensating for schema lack.

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

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

Description clearly states 'Get the actual Python code behind a community leaderboard strategy.', using specific verb 'Get' and resource 'Python code'. It distinguishes from siblings by mentioning use after `browse_community` and alternative deployment via `one_shot`.

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 ('Use after `browse_community`') and when not to use or alternative ('To deploy it unchanged, pass the same id to `one_shot`'). Also clarifies read-only, no signup needed.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=false. The description adds valuable context: the tool returns a short-lived URL for the user to approve, and by default works with an anonymous trial account. This clarifies the behavioral flow beyond the annotations.

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

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

The description is well-structured and concise. The first sentence states the core purpose, followed by specific usage scenarios and behavioral details. Every sentence adds value, with no redundancy or filler.

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

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

Given the zero-parameter schema and presence of an output schema, the description covers the essential workflow: anonymous trial, URL generation, and user approval. It does not mention error cases or failure modes, but is otherwise complete for the tool's complexity.

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, so schema description coverage is effectively 100%. The description does not need to add parameter details, and it appropriately focuses on the tool's purpose and flow.

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

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

The description clearly states the tool's purpose: 'Link this chat to the user's existing QuantifyMe account.' It uses a specific verb (link) and resource (QuantifyMe account), and is easily distinguishable from sibling tools like browse_community or list_models.

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 lists conditions for calling the tool: 'when the user says they already have a QuantifyMe account' or 'asks why their models are missing' or 'wants what they deploy here to show up in their own dashboard.' It also explains the default anonymous behavior but does not explicitly mention when not to call or alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating a safe, read-only operation. The description adds no further behavioral context beyond stating the action, so it meets the baseline but offers no additional value.

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

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

A single, front-loaded sentence that is clear and without any extraneous information. Every word is necessary.

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 no parameters and an output schema, the description is mostly complete. It specifies scope ('user's'). However, it could be improved by differentiating from the sibling 'list_models' to avoid 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 zero parameters and 100% coverage, so the baseline is 3. The description correctly adds no parameter information since none exist.

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

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

The description clearly states it lists the user's currently deployed (live) models, with a specific verb ('list') and resource ('deployed live models'), distinguishing it from the sibling 'list_models' which likely lists all models.

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

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

The description implies usage for viewing live models but provides no explicit guidance on when to use this tool versus alternatives like 'list_models', nor any conditions 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint=true. The description adds that the tool returns pre-computed train/test stats, which is a useful behavioral detail beyond annotations.

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

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

A single clear sentence with no wasted words. 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?

Given 0 parameters, rich annotations, and an output schema (present but not detailed here), the description fully covers the tool's purpose and output content.

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

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

Input schema has no parameters (100% coverage). With 0 parameters, the description need not add param detail; baseline 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 it lists the user's trained models with pre-computed stats. It distinguishes from sibling tools like list_deployed (deployed models) and browse_community (community resources).

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 implicitly indicates when to use it (to view trained models), but no explicit guidance on when not to use it or comparisons with alternatives like list_deployed or get_model_chart.

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 that the deploy runs in background, returns immediately with a job_token, and that the live card streams progress. Mentions daily limits for Claude models. The description adds significant behavioral context beyond annotations (destructiveHint=true, readOnlyHint=false). No contradiction.

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 thorough but somewhat lengthy; however, it is well-structured with a summary, parameter list, return value explanation, and usage instructions. Every sentence adds value, though a more concise format could be achieved while retaining 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 tool's complexity (8 parameters, multiple modes, asynchronous behavior, output schema), the description is complete. It covers all modes, precedence, defaults, return fields, next steps, daily limits, and cross-references to other tools (list_models, browse_community, get_deploy_result), adequately equipping an AI agent to use the tool correctly.

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

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

Despite 0% schema description coverage, the description thoroughly documents all 8 parameters: explains allowed values, defaults (e.g., symbol defaults to EURUSD, timeframe to 15min), precedence, and special behaviors (e.g., claude_model ignored when preset is set). Compensates fully for missing schema descriptions.

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

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

The description clearly states the tool's purpose as 'End-to-end deploy: generate strategy → train → deploy live' and distinguishes three input modes (prompt, preset, community_id) with precedence rules, differentiating it from siblings like generate_strategy and browse_community.

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 each mode, precedence (community_id > preset > prompt), that it should be called exactly once per request, and provides the next step to call get_deploy_result. Also advises against pre-picking presets/community strategies and instructs how to handle community-sourced results.

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?

Describes rendering a widget with three panels (JS timer, WebSocket, HTTP poll) each showing live value and status. Annotations already mark it as read-only, idempotent, and open-world. No contradictions.

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

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

Front-loaded with key purpose, then explains widget details and usage in a few concise sentences. 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?

With output schema present, no need to detail returns. For a diagnostic tool with one optional parameter, the description covers purpose, behavior, and usage adequately.

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 description carries full burden for parameter semantics. Only mentions 'G7 pair to stream (default EURUSD)' for the single param, adding marginal value. Sufficient for one param but not rich.

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?

Opens with 'Diagnostic: test whether LIVE data streaming works in this client,' specifying verb (test) and resource (streaming mechanisms). Clearly distinguishes from siblings like get_quote by being a diagnostic tool.

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

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

Explicitly states 'Use when a live/ticking chart isn't moving,' providing clear when-to-use guidance. Does not mention when not to use, but context is sufficient.

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

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

Discloses beyond annotations that the tool is simulated (no real charge) and capped at $100, which is critical for agent decision-making. Annotations indicate it's a write operation and not idempotent, but description adds the simulation 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?

Two sentences that are front-loaded with the main action, every sentence adds value with no redundancy.

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

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

Fully covers the tool's purpose, behavioral traits (simulation, cap), and return value (new credit balance). Output schema exists, so return details are structurally covered.

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

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

Only one parameter (amount_usd) with no description in the schema. The description implies funding amount but does not elaborate on syntax, limits (beyond $100 cap mentioned), or data type requirements. Schema coverage is 0%, so description partially compensates but could add more detail.

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

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

Clearly states the tool funds QuantifyMe credits with crypto (USDC), specifying it's agent-native, simulated, capped at $100, and returns the new balance. Distinguishes from sibling tools which are about other actions like browsing or generating strategies.

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 describes when to use (funding with crypto) and provides context (no signup, no human, no card). Lacks explicit when-not-to-use or alternatives, but the context is sufficient among sibling tools.

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