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

Annotations provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially open-ended data. The description adds value by listing all parameters, which helps the agent understand the scope of filtering options (keywords, date ranges, chain, limit, cursor, sources). However, it doesn't describe behavioral aspects like pagination mechanics (cursor usage), rate limits, authentication requirements, or what 'sources' refers to.

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 - just one sentence listing parameters. While efficient, it's under-specified rather than appropriately concise. It front-loads the core purpose but lacks any explanatory context. Every word earns its place, but more context would be helpful for a tool with 7 parameters and no schema descriptions.

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 with 0% schema coverage and no output schema, the description is incomplete. It lists parameters but doesn't explain their semantics, expected formats, or relationships. The annotations help by indicating this is a read-only, open-world operation, but the description doesn't explain what the tool returns or how results are structured. For a complex query tool, more context would be 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?

With 0% schema description coverage, the description carries full burden for parameter documentation. It lists all 7 parameters by name, which provides basic semantic information about what can be controlled. However, it doesn't explain what each parameter means (e.g., what 'chain' represents, what format 'start' and 'end' should use, what 'sources' options are available). The description compensates somewhat but doesn't fully explain parameter purposes.

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 'Multi-keyword mentions' which indicates the tool deals with keyword mentions, but it's vague about what resource or system this operates on. It doesn't specify whether this searches documents, social media, news articles, or another data source. The title annotation 'ELFA: Keyword Mentions' provides some context, but the description itself lacks specificity about the domain or target resource.

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. With sibling tools like 'elfa_query', 'elfa_token_news', and 'elfa_trending_tokens' that might also involve keyword-related operations, there's no indication of how this tool differs or when it's the appropriate choice. No prerequisites, exclusions, or comparison to 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?

Annotations indicate readOnlyHint=true and openWorldHint=true, suggesting safe read operations with flexible endpoints. The description adds context by specifying it's a 'proxy' that returns JSON, but doesn't elaborate on behavioral traits like error handling, authentication needs (implied by ELFA context), rate limits, or what 'any ELFA path' entails. It doesn't contradict annotations, but adds minimal value beyond them.

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

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

The description is extremely concise with two sentences that efficiently convey core functionality: it's a generic proxy for ELFA calls and returns JSON. Every word earns its place, and it's front-loaded with the main purpose. No unnecessary details or redundancy.

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

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

Given the tool's complexity (generic proxy with 4 parameters, no output schema, and annotations covering safety), the description is minimally adequate. It explains what the tool does but lacks details on ELFA system context, error responses, or usage examples. With openWorldHint=true, more guidance on endpoint discovery would be helpful, but the description doesn't provide 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?

Schema description coverage is 100%, with clear descriptions for all 4 parameters (path, method, query, body). The description adds that path is 'like /v2/...' and body is 'for non-GET,' providing slight additional context. However, it doesn't explain parameter interactions (e.g., when query/body are required) or ELFA-specific semantics, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose as a 'Generic ELFA proxy' that can 'Call any ELFA path with method/query/body' and 'Returns JSON.' This specifies the verb (call/proxy), resource (ELFA paths), and output format. However, it doesn't explicitly differentiate from sibling tools like elfa_keyword_mentions or elfa_trending, which appear to be more specific ELFA 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?

The description provides no guidance on when to use this generic proxy tool versus the more specific sibling tools (e.g., elfa_keyword_mentions, elfa_trending). It mentions it can call 'any ELFA path,' but doesn't specify contexts where this generic approach is preferred over dedicated tools or when it might be inappropriate. No alternatives or exclusions are mentioned.

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

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

Annotations indicate readOnlyHint=false (implying mutation) and openWorldHint=false (suggesting deterministic behavior). The description adds that it reloads from 'common locations,' which provides useful context beyond annotations. However, it doesn't specify effects (e.g., overwriting current env vars) or error conditions, leaving behavioral gaps.

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

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.

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 (0 parameters, no output schema) and annotations covering safety aspects, the description is adequate but minimal. It lacks details on outcomes (e.g., success indicators) or integration with sibling tools, making it only moderately complete for a mutation tool.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately avoids redundant information, maintaining a high score for this dimension.

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 ('Reload') and target resource ('.env files from common locations'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential siblings that might also manipulate .env files, though no such siblings exist in the provided 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., when .env files exist), exclusions, or related tools like 'elfa_set_auth' or 'elfa_set_base' that might interact with environment settings.

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=false and openWorldHint=false, suggesting this is a mutation tool with closed-world behavior. The description adds value by specifying it sets API auth, implying configuration changes, but doesn't disclose details like persistence, error handling, or rate limits. No contradiction with annotations, but minimal behavioral context beyond them.

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 and front-loaded: the first sentence states the purpose, followed by a clear parameter list with examples. Every sentence earns its place with no wasted words, making it efficient and well-structured.

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 moderate complexity (3 parameters, mutation indicated by annotations, no output schema), the description is partially complete. It covers parameters well but lacks context on how this auth setting integrates with sibling tools, return values, or error scenarios, leaving 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?

With 0% schema description coverage, the description fully compensates by listing all three parameters (key, headerName, scheme) and providing semantic details: key is a string, headerName options (Authorization or x-elfa-api-key), and scheme examples (e.g., Bearer). This adds essential meaning beyond the bare 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's purpose: 'Set ELFA API auth' specifies the verb ('Set') and resource ('ELFA API auth'), making it understandable. However, it doesn't differentiate from sibling tools like 'elfa_set_base' or explain how this auth setting relates to other ELFA tools, missing full sibling distinction.

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. It doesn't mention prerequisites (e.g., if auth is required before using other ELFA tools), exclusions, or context for usage, leaving the agent without clear usage instructions.

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 this is not read-only and not open-world, but the description adds minimal behavioral context beyond this. It specifies what gets configured (the base URL) but doesn't mention persistence, scope (session vs. global), validation of the URL format, or error behavior. The description doesn't contradict annotations but adds only basic operational 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, efficient sentence that immediately conveys the tool's purpose with a helpful example. There's no wasted text, and it's appropriately sized for a simple configuration tool.

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 configuration tool with 1 parameter and no output schema, the description is minimally adequate. It explains what the tool does but lacks important context about when and why to use it, how it interacts with other ELFA tools, and what happens after configuration. The annotations provide basic safety hints but don't fill these 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?

With only 1 parameter and 0% schema description coverage, the description compensates well by explaining that the 'base' parameter should be a URL like 'https://api.elfa.ai'. This provides clear semantic meaning beyond the schema's type information, though it could be more explicit about format requirements or constraints.

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

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

The description clearly states the action ('Set') and the resource ('ELFA base URL'), providing a specific example of what the base URL should look like. However, it doesn't explicitly differentiate this tool from its sibling 'elfa_set_auth', which likely handles authentication settings rather than base URL configuration.

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. It doesn't mention prerequisites (like whether authentication must be set first), when this configuration is needed, or how it relates to sibling tools like 'elfa_set_auth' or 'elfa_reload_env'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, read-only operation with limited scope. The description adds useful context about masking keys and including .env load info, which aren't covered by annotations. However, it doesn't disclose behavioral traits like response format, error conditions, or performance 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?

The description is a single, efficient sentence that front-loads the core purpose ('Show current ELFA config') and adds specific details without waste. Every word earns its place, and there's no redundancy or fluff.

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

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

Given the tool has 0 parameters, annotations covering safety (readOnlyHint) and scope (openWorldHint), but no output schema, the description is adequate but incomplete. It explains what the tool shows but not the format or structure of the output, which could be important for an agent to interpret results correctly.

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

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

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary 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 verb 'Show' and the resource 'current ELFA config' with specific details about what's included (key masked, .env load info). It distinguishes from siblings like elfa_reload_env or elfa_set_auth by focusing on status display rather than modification. However, it doesn't explicitly differentiate from all siblings (e.g., elfa_query might also show information).

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. It doesn't mention when to use elfa_status instead of elfa_query or other siblings, nor does it specify prerequisites or exclusions. The 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?

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description doesn't contradict. However, the description adds no behavioral context beyond what annotations provide—it doesn't explain what 'news' entails (e.g., real-time updates, historical data, or aggregated feeds), rate limits, or authentication needs. With annotations covering safety and scope, the description adds minimal value, scoring a baseline 3.

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 under-specified rather than concise—it wastes space on a tautological phrase and a bare parameter list without meaningful context. It lacks front-loaded purpose and structured details, making it inefficient for an agent to parse. While short, it doesn't earn its place with useful information, so it scores low.

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 with 0% schema coverage, no output schema, and annotations only covering read-only and open-world hints, the description is incomplete. It doesn't explain what 'news' returns, how parameters interact, or error conditions. For a tool with this complexity, the description fails to provide adequate context, leaving significant 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?

The description lists parameter names ('symbols, chain, start, end, limit, cursor, sources') but provides no semantics—no explanations of what they mean, expected formats, or usage. With 0% schema description coverage and 7 parameters, this leaves all parameters undocumented. The list adds marginal value over an empty schema, but fails to compensate for the coverage gap, scoring below the baseline.

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 'Token news' is a tautology that restates the tool name 'elfa_token_news' without specifying what the tool actually does. It doesn't provide a clear verb or resource, nor does it distinguish this tool from siblings like 'elfa_trending_tokens' or 'elfa_keyword_mentions'. The title annotation 'ELFA: Token News' adds minimal context but doesn't compensate for the description's vagueness.

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. It doesn't mention any context, prerequisites, or exclusions, nor does it differentiate from sibling tools like 'elfa_trending_tokens' or 'elfa_query' that might handle related data. With zero usage instructions, this leaves the agent guessing about appropriate scenarios.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description doesn't contradict. It adds value by specifying the API endpoint ('/v2/aggregations/trending-tokens'), providing context beyond annotations, though it lacks details on rate limits or response behavior. No contradiction with annotations exists.

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 key information (alias and endpoint). There's no wasted text, making it highly concise and well-structured for quick comprehension.

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 4 parameters with 0% schema coverage, no output schema, and annotations only covering read/access hints, the description is incomplete. It doesn't explain what the tool returns, how parameters affect results, or differentiate it from similar tools, leaving significant gaps for agent usage.

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

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

Schema description coverage is 0%, and the description lists parameter names without explaining their meanings (e.g., what 'timeframe' or 'chain' represent). It fails to compensate for the schema's lack of descriptions, leaving parameters largely undocumented and unclear to 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?

The description states it's an alias to a specific API endpoint with parameters listed, which gives a vague purpose. It doesn't clearly explain what the tool actually does (e.g., fetch trending tokens from ELFA) or how it differs from sibling tools like 'elfa_trending_tokens', leaving the agent to infer functionality from the endpoint name.

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. The description mentions it's an alias but doesn't explain its relationship to 'elfa_trending_tokens' or other siblings, nor does it specify contexts or prerequisites for usage, offering minimal practical 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?

Annotations provide readOnlyHint=true and openWorldHint=true, indicating it's a safe read operation with open-world data. The description adds minimal behavioral context by listing parameters but doesn't disclose details like rate limits, authentication needs, or what 'aggregation' entails (e.g., sorting, filtering). No contradiction with annotations exists, but the description adds little beyond what annotations already cover.

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 with two short sentences, front-loading the purpose and then listing parameters. There's no wasted text, but it could be more structured by explaining parameters briefly. It's appropriately sized for a simple tool but lacks depth.

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 4 parameters with 0% schema coverage, no output schema, and annotations covering only safety aspects, the description is incomplete. It doesn't explain what the tool returns (e.g., list of tokens with metrics), how parameters interact, or provide examples. For a data aggregation tool with multiple inputs, this leaves significant gaps for an agent to use it 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 the schema provides no parameter details. The description lists parameter names ('timeframe, chain, limit, cursor') but doesn't explain their meanings, expected formats (e.g., timeframe as '1d' or '7d'), or constraints. This adds minimal value beyond the bare schema, failing to compensate for the low coverage.

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

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

The description states 'Trending tokens aggregation' which indicates the tool aggregates trending tokens, but it's vague about what 'trending' means (e.g., by price, volume, social mentions) and doesn't specify the resource or output format. It distinguishes from siblings like 'elfa_trending' (which might be broader) and 'elfa_token_news' (news-focused), but the distinction is implicit 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 guidance is provided on when to use this tool versus alternatives. It doesn't mention when to choose it over 'elfa_trending' (which might be a similar tool) or 'elfa_keyword_mentions' (which could overlap in token analysis), and there are no prerequisites or exclusions stated in the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, deterministic calculation. The description adds context about the calculation method ('SMA + population stdev') and data orientation ('oldest→newest'), which helps understand the tool's behavior beyond the annotations. However, it doesn't disclose performance characteristics, error conditions, or output format 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?

The description is extremely concise and well-structured in a single sentence. It front-loads the purpose, then efficiently documents all parameters with their types, defaults, and important semantics (data ordering). Every element serves a clear purpose 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?

For a calculation tool with good annotations (readOnlyHint, openWorldHint) but no output schema, the description adequately covers the core functionality and parameters. However, it doesn't explain what the tool returns (Bollinger Band values, SMA line, etc.) or how results are structured, leaving gaps for an agent to understand the output format.

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 fully compensates by explaining all three parameters: 'values:number[] (oldest→newest)' clarifies data structure and ordering, 'period?:number(20)' provides default value and optionality, and 'mult?:number(2)' provides default value and optionality. This adds essential meaning beyond the bare schema, though it doesn't explain parameter constraints 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 the tool's purpose: 'Compute Bollinger Bands (SMA + population stdev).' It specifies the verb ('Compute') and resource ('Bollinger Bands') with technical detail about the calculation method. However, it doesn't explicitly differentiate from sibling technical analysis tools like 'ta_rsi' or 'ta_summary' beyond mentioning the specific indicator name.

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. It doesn't mention sibling tools like 'ta_rsi' or 'ta_summary' for different technical indicators, nor does it specify appropriate contexts or prerequisites for Bollinger Bands analysis. The parameter documentation implies usage but offers no comparative 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?

Annotations already provide readOnlyHint=true and openWorldHint=false, indicating this is a safe, deterministic calculation. The description adds useful context about the Wilder method and return format ('Returns latest RSI'), which goes beyond annotations. However, it doesn't mention computational complexity, error conditions, or data requirements beyond what's in parameters.

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 efficient single sentence that packs purpose, parameters with semantics, and return value. Every word earns its place with zero redundancy. The structure is front-loaded with the core purpose followed by implementation 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?

For a calculation tool with good annotations (readOnlyHint, openWorldHint) but no output schema, the description provides complete context about what it computes, how to format inputs, and what it returns. The main gap is lack of error handling information, but otherwise covers the essential aspects well.

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 fully compensates by explaining both parameters: 'values:number[] (oldest→newest)' clarifies the array ordering requirement, and 'period?:number(14)' specifies the default value and optional nature. This adds significant meaning beyond the bare 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 specific action ('Compute RSI (Wilder)'), resource (RSI indicator), and distinguishes from siblings by specifying the Wilder method. It explicitly identifies the mathematical calculation being performed rather than just restating the name.

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 context through the parameter explanation (values array ordering, period default), but doesn't explicitly state when to use this tool versus alternatives like ta_bollinger or ta_summary. No guidance is provided about when this tool is appropriate versus other technical analysis 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 provide readOnlyHint=true and openWorldHint=false, indicating a safe, deterministic operation. The description adds minimal behavioral context by specifying it returns both indicators in one call, which hints at efficiency but doesn't detail output format, error handling, or computational limits. Since annotations cover safety, the description adds some value but lacks depth, aligning with a baseline score.

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

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

The description is highly concise and front-loaded: the first sentence states the purpose, followed by a compact parameter list. Every sentence earns its place with no wasted words, making it easy for an agent to parse quickly. The structure efficiently conveys essential information without redundancy.

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

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

Given 4 parameters, 0% schema coverage, no output schema, and annotations covering safety, the description is moderately complete. It defines the tool's purpose and parameters but lacks details on return values, error conditions, or performance considerations. For a technical analysis tool with multiple inputs, more context would help, but it meets a basic threshold.

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 lists all parameters with types and defaults (e.g., 'rsiPeriod?:number(14)'), adding meaning beyond the bare schema. However, it doesn't explain parameter roles (e.g., what 'values' array represents or valid ranges), leaving gaps. With 4 parameters and no schema descriptions, this partial compensation justifies a mid-range score.

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: 'Return both RSI and Bollinger in one call.' It specifies the verb ('Return') and resources ('RSI and Bollinger'), making the function explicit. However, it doesn't distinguish this from its sibling tools 'ta_bollinger' and 'ta_rsi' by explaining why one would use this combined tool versus the individual ones, which prevents a perfect score.

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. It mentions sibling tools 'ta_bollinger' and 'ta_rsi' exist but offers no context on trade-offs, such as efficiency or use cases for combined versus separate calculations. Without any when-to-use or when-not-to-use advice, the agent lacks decision-making support.

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