xpay✦ Finance Collection

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 describes output characteristics (probabilities, insights) but fails to disclose behavioral traits: read-only status (implied by 'Get' but not confirmed), error handling for invalid slugs, rate limits, data freshness/staleness, or whether insights are cached vs. real-time. Significant gap for a data-fetching tool with no safety annotations.

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

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

Two sentences with no filler. The first front-loads key capabilities (probabilities, trading activity, AI-friendly insights), while the second explains the data combination logic. 'AI-friendly insights' is slightly vague, preventing a perfect score, but overall structure is efficient.

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

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

Given no output schema exists, the description partially compensates by listing output categories (probabilities, trading activity, insights), but lacks structural details, return format, or error conditions. For a 2-parameter tool, this is minimum viable coverage—adequate but missing richness expected when annotations are absent.

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 100% schema description coverage (both slug and include_trades are documented), the baseline is 3. The description adds marginal semantic context by linking 'recent trades' to the include_trades parameter and implying the slug identifies a probabilistic market, but doesn't add format constraints, examples, or validation rules 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 uses specific verb 'Get' + resource 'market analysis' and enumerates specific components (probabilities, trading activity, AI-friendly insights). The mention of 'probabilities' suggests prediction market focus, differentiating it from stock-market siblings like getQuote or get_market, though it doesn't explicitly name these alternatives or clarify when to choose this over get_market.

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 phrase 'Combines market data with recent trades' implies this tool aggregates data that might otherwise require multiple calls, suggesting usage when comprehensive analysis is needed. However, it lacks explicit when-to-use/when-not-to-use guidance and doesn't name specific sibling alternatives to avoid (e.g., get_market for basic data only).

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 of behavioral disclosure. While it explains the tool performs a valuation calculation, it omits critical behavioral traits: whether the operation is idempotent, what data format is returned (e.g., JSON valuation object), potential rate limits, or whether the calculation is synchronous.

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 appropriately concise with two sentences and places the core action ('Run a tailored DCF analysis') first. The second sentence contains slightly superfluous marketing language ('offering a more personalized and precise valuation'), but overall avoids unnecessary verbosity.

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 high complexity (19 financial parameters in a nested structure), absence of output schema, and 0% parameter description coverage, the description is insufficient. It does not explain the required 'symbol' parameter, the relationship between input variables, or the structure of the valuation result, leaving critical gaps for an agent attempting to construct valid inputs.

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 for the 18+ nested financial parameters (beta, ebitPct, taxRate, etc.), the description fails to compensate adequately. It vaguely references 'detailed inputs' and 'variables' but provides no semantic meaning for required fields like 'symbol' or the financial percentages, leaving the agent without guidance on valid value ranges or calculation logic.

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 identifies the tool as running a 'tailored Discounted Cash Flow (DCF) analysis' and distinguishes it from standard DCF tools by emphasizing 'Custom' and 'fine-tune their assumptions'. However, it does not explicitly differentiate from the sibling tool `calculateCustomLeveredDCF`, leaving ambiguity about which custom DCF variant to select.

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 contexts through phrases like 'fine-tune their assumptions' and 'detailed inputs', suggesting use when custom financial modeling is needed. However, it fails to provide explicit when-to-use guidelines, prerequisites (e.g., requiring financial expertise), or comparisons to alternatives like `getDCFValuation` or `calculateCustomLeveredDCF`.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the external 'FMP Custom DCF Advanced API' but discloses nothing about computation idempotency, error handling (e.g., invalid symbols), rate limits, or whether results are cached. The term 'Run' suggests execution but lacks specificity on side effects or resource intensity.

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

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

The description is two sentences and reasonably sized, but suffers from redundant adjectives ('tailored', 'personalized', 'precise') that add little informational value. The critical 'levered' aspect from the tool name is buried in absence rather than front-loaded in the 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 tool's complexity (19+ financial parameters, nested input structure) and lack of output schema or annotations, the description is insufficient. It fails to explain what 'levered' DCF implies for the valuation methodology, what the output represents (enterprise value, equity value, per-share price), or how the numerous percentage parameters interact.

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 reported as 0%, requiring the description to compensate. While it vaguely references 'detailed inputs' and 'variables', it provides no semantic guidance on the 18+ complex financial parameters (e.g., whether percentages are expressed as decimals or whole numbers, relationships between EBIT/EBITDA, or that costOfDebt is required for levered calculations).

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 runs a 'tailored Discounted Cash Flow (DCF) analysis' which identifies the core verb and resource. However, it fails to explain what 'levered' means (a critical financial distinction) and does not differentiate from the sibling tool 'calculateCustomDCF', leaving ambiguity about when to choose this variant over the standard custom DCF.

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 mentions 'fine-tune their assumptions' implying use for customized valuation scenarios, but provides no explicit guidance on when to use this versus 'calculateCustomDCF' (likely unlevered) or 'getLeveredDCFValuation' (likely standard inputs). No prerequisites, exclusions, or alternative selection criteria are provided.

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

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

With no annotations provided, the description carries the full burden. It discloses specific activity types returned (MERGES, SPLITS, REDEEMS) but lacks details on pagination behavior, rate limits, error conditions, or whether this is a safe read-only operation.

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

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

Two well-structured sentences with zero waste. First sentence covers purpose and filtering capabilities; second covers return value specifics. Information is front-loaded and every sentence 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?

Given the 7-parameter schema with full coverage and no output schema, the description adequately covers the tool's purpose and return content types. It could improve by describing the output structure or pagination behavior since no output schema exists.

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%, establishing a baseline of 3. The description maps parameters to conceptual groups (market, condition, time range) but adds no additional semantic detail, validation rules, or format specifications 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 it 'Fetches activity data for a specific user' with specific return types (MERGES, SPLITS, REDEEMS), distinguishing it from generic trade history tools. However, it doesn't explicitly differentiate from sibling tools like dome_trade_history.

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

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

The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives like dome_trade_history or dome_positions. No prerequisites or exclusion criteria are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It effectively discloses behavioral traits: timestamp format (Unix milliseconds), currency formatting constraints, and conditional return behavior (single most recent price vs. historical range). It does not explicitly state safety properties (read-only), though 'fetches' implies non-destructive access.

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?

Five sentences with zero waste: data source, general return value, conditional time-range behavior, timestamp format constraint, and currency format constraint. Information is front-loaded and every sentence 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?

Adequate for input parameters (all 5 documented in schema), but significant gap regarding output structure. Without an output schema, the description should describe the return format (e.g., array of price objects, fields included), but only vaguely mentions 'price data.' Also omits pagination behavior details despite having a pagination_key parameter.

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 100% schema description coverage, the baseline is 3. The description reinforces the currency format requirements and timestamp units, but this information is already present in the schema parameter descriptions. It adds minimal semantic value beyond what the structured schema provides.

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 it 'Fetches historical crypto price data from Binance,' specifying the exact verb, resource, and data source. This clearly distinguishes it from siblings like dome_chainlink_prices (different source) and dome_candlesticks (different data type).

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 implied usage guidance by explaining that 'When no time range is provided, returns the most recent price,' which helps users understand parameter interaction. However, it lacks explicit guidance on when to use this versus alternatives like dome_market_price (real-time) or dome_candlesticks (OHLCV data).

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 of behavioral disclosure. It fails to mention rate limits, pagination behavior, authentication requirements, or the structure/format of the returned candlestick data (e.g., OHLCV fields). The schema provides range limits, but the description adds no behavioral context.

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

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

The description is a single sentence and appropriately front-loaded with the action. However, the inclusion of 'condition_id'—which appears to be a phantom parameter not present in the schema—means the sentence does not fully earn its place due to the misleading information.

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

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

For a simple 3-parameter data retrieval tool with complete schema documentation, the description is minimally adequate. However, given the lack of output schema and annotations, it should ideally describe the return format (e.g., candlestick structure) and clarify the market identification mechanism to compensate.

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%, providing detailed descriptions for all three parameters including interval mappings and range limits. The description mentions 'specified interval' and implies time range via 'historical', meeting the baseline expectation when the schema is comprehensive. However, it confusingly references 'condition_id' which is absent from 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 states a specific action ('Fetches') and resource ('historical candlestick data'), but contains a significant confusion by referencing 'condition_id' to identify the market, which does not appear in the input schema. This creates ambiguity about how to specify the target market.

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 siblings like 'dome_market_price' or 'dome_binance_prices'. There are no prerequisites, filtering suggestions, or 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?

With no annotations provided, the description carries the full burden and successfully identifies the Chainlink data provenance, timestamp format (Unix milliseconds), and default behavior. Could be improved by mentioning rate limits, data latency, or error handling patterns.

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

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

Four efficient sentences with zero waste. Information is front-loaded with purpose, followed by behavioral defaults and format specifications. Every sentence 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?

Given the lack of output schema, the description inadequately explains the return data structure (merely stating 'Returns price data' without specifying fields, array structure, or price granularity). Otherwise complete for the input requirements.

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%, establishing a baseline of 3. The description largely confirms schema details (timestamp format, currency examples, default limits) without adding significant semantic depth beyond what's already documented in the parameter 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?

Description clearly states the tool 'Fetches historical crypto price data from Chainlink' with specific verb (fetches), resource (historical crypto price data), and distinguishes from siblings like dome_binance_prices by explicitly naming Chainlink as the data source.

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 implicit usage guidance by explaining 'When no time range is provided, returns the most recent price,' but lacks explicit comparison to sibling tools (e.g., when to prefer Chainlink over Binance prices or other crypto data sources).

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 of behavioral disclosure. It states the tool 'fetches' data, implying a read-only operation, but does not confirm this, nor does it disclose error conditions, rate limits, data freshness guarantees, or what happens if at_time is omitted (though this is in the schema description).

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

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

The description consists of exactly two sentences with no filler text. The first establishes the core function and resource, while the second explains the key optional feature. 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?

For a single-parameter getter tool with no output schema provided, the description adequately covers the primary function (current price) and key variant behavior (historical). However, it lacks information about the return value structure and does not clarify the relationship with sibling price tools, leaving gaps in contextual 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?

With 100% schema description coverage for the single parameter (at_time), the baseline is 3. The description adds semantic context by linking at_time to 'historical lookups', which reinforces the schema description. However, it loses some credit for referencing 'token_id' which appears to be absent from 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 states the tool fetches market prices by token_id and mentions historical lookup capability. However, it fails to distinguish from the sibling tool 'dome_market_price_get', and confusingly references 'token_id' which does not appear in the provided input schema (which only contains 'at_time' per context signals).

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 implied usage guidance by noting that historical lookups are possible via the at_time parameter. However, it lacks explicit guidance on when NOT to use this tool (vs real-time alternatives) or prerequisites for the token_id/market identification.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the behavioral trait of returning dual-sided prices (yes/no) specific to prediction markets and mentions historical lookup capability. However, it omits mutation safety, rate limits, error conditions, or data freshness 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 consists of three efficient sentences with no filler. It front-loads the core action (fetches market price), follows with return value details, and ends with the specific parameter usage, maximizing information density.

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 absence of an output schema, the description partially compensates by describing the conceptual return values (yes/no prices). However, with zero annotations and only one described parameter, it should clarify the output format/structure and unambiguously specify how the market is identified (addressing the market_ticker discrepancy).

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% for the single parameter shown (at_time), establishing a baseline of 3. The description adds value by explaining that at_time enables 'historical lookups' beyond the schema's timestamp description. However, it confusingly references 'market_ticker' which is absent from the schema, potentially misleading agents about required inputs.

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 fetches current market prices for Kalshi prediction markets (distinguishing from generic stock/forex tools in the sibling list) and specifies it returns both 'yes' and 'no' side prices. However, it references 'market_ticker' as the identifier while the provided schema only contains 'at_time', creating ambiguity about how the target market is specified.

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 by explaining that the 'at_time' parameter enables historical lookups, suggesting when to use it versus real-time fetches. However, it lacks explicit guidance on when to use this tool versus siblings like 'dome_market_price' or 'dome_markets_get', or prerequisites like market identification.

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 of behavioral disclosure. It fails to mention what the tool returns (no output schema exists), pagination behavior, whether the operation is read-only, or any rate limiting concerns.

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 efficiently structured with no wasted words. It front-loads the primary action and resource, making it appropriately concise given the comprehensive schema coverage.

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 11 parameters and no output schema or annotations, the description lacks critical context. It does not explain return values, pagination strategy, or distinguish from the dedicated 'search_markets' sibling, rendering it incomplete for a tool of this 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?

With 100% schema description coverage across all 11 parameters, the schema itself documents the inputs thoroughly. The description adds only a generic reference to 'various filters' without elaborating on specific parameter semantics, meeting the baseline expectation.

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 (Find) and resource (markets on Polymarket), establishing a clear purpose. However, it fails to distinguish from siblings like 'search_markets' or 'dome_markets_get', which appear to offer similar functionality.

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. Notably, it mentions 'including the ability to search' but does not clarify when to use this versus the sibling 'search_markets' tool, leaving ambiguity.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to specify the return format, pagination behavior (despite limit/offset parameters), rate limits, or whether this queries a real-time API versus cached data. The only behavioral hint is the implied read-only nature of 'Find'.

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

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

The description is a single, front-loaded sentence that efficiently communicates the core function. It avoids redundancy with the schema, though the list of filters could be more structured (e.g., noting that all parameters are optional) to improve scannability.

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 tool with 7 parameters and no output schema, the description adequately identifies the target platform (Kalshi) but lacks critical context about the return payload structure and the tool's relationship to the broader dome_* ecosystem. It mentions 'volume' when the parameter is actually 'min_volume', creating minor imprecision.

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 100% schema description coverage, the baseline is 3. The description mentions specific filters (market ticker, event ticker, status, volume) that map to parameters, but adds no semantic value beyond the schema's existing documentation—no format constraints, example values, or inter-parameter dependencies are explained.

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 'Find[s] markets on Kalshi' with specific filtering capabilities (market ticker, event ticker, status, volume). However, it does not distinguish from similarly named siblings like 'dome_markets' or 'search_markets', leaving ambiguity about which tool to use for different search scenarios.

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. Given the presence of siblings like 'dome_markets', 'search_markets', and 'dome_market_price_get', the absence of when-to-use criteria or prerequisites (e.g., authentication requirements for Kalshi) significantly hampers selection.

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

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

With no annotations provided, description carries full burden and succeeds well: specifies timestamp units ('milliseconds'), data availability constraint ('history starting from October 14th, 2025'), output structure ('bids, asks, and market metadata'), and parameter interaction rules. Missing only safety hints (read-only status) and rate limits.

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

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

Six sentences total, all high-value. Front-loaded with primary purpose, followed by conditional behavior, output format, units, data constraints, and parameter warnings. No redundant or filler text.

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

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

Despite no output schema, description partially compensates by listing return contents ('bids, asks, and market metadata'). Covers essential constraints (date availability, parameter interactions) for a 5-parameter time-series tool. Would need return value details or error conditions for a 5.

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 100% coverage, establishing baseline of 3. Description adds crucial semantic information beyond schema: explicitly states that 'limit and pagination_key parameters are ignored' when fetching latest without time bounds, which explains parameter interdependencies not evident from individual field 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?

Description opens with specific verb 'Fetches' + resource 'historical orderbook snapshots' + scope 'for a specific asset (token ID) over a specified time range'. Clearly distinguishes the tool's function from siblings like dome_market_price or dome_trade_history by emphasizing 'historical snapshots' and 'orderbook' depth (bids/asks).

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 clear conditional logic: 'If no start_time and end_time are provided, returns the latest orderbook snapshot'. Also notes that limit/pagination_key are ignored when fetching latest. However, does not explicitly name sibling alternatives (e.g., dome_orderbook_history_get) or when to use real-time vs historical 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?

With no annotations provided, the description carries the full burden and excels by disclosing: the output format (yes/no bids, cents and dollars), timestamp units (milliseconds), data availability constraints (history from Oct 29, 2025), and behavioral quirks (limit parameter ignored in certain conditions). This provides comprehensive 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 consists of four tightly constructed sentences with zero waste: purpose declaration, conditional behavior for latest snapshot, output format specification, and timestamp/parameter constraints. Information is front-loaded and every sentence 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?

Given the tool's moderate complexity (4 parameters, two operational modes) and lack of annotations or output schema, the description is remarkably complete. It explains return values, data availability limits, and parameter interactions. Minor gaps remain regarding authentication requirements or rate limits, but these may be handled at the server level.

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?

While the schema has 100% description coverage (baseline 3), the description adds valuable semantic context beyond the schema by explaining the interaction between start_time/end_time parameters and the limit parameter behavior ('ignored when fetching the latest'). This clarifies the logical relationship between parameters.

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

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

The description clearly states the tool fetches historical orderbook snapshots for Kalshi markets using specific verbs ('Fetches') and identifies the resource ('historical orderbook snapshots'). However, it does not explicitly differentiate from the sibling tool 'dome_orderbook_history', leaving potential ambiguity about which to use.

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

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

The description provides clear conditional logic for usage: 'If no start_time and end_time are provided, returns the latest orderbook snapshot.' It also notes when the limit parameter is ignored. However, it lacks explicit guidance on when to use this tool versus the sibling 'dome_orderbook_history' or other market data 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?

With no annotations provided, the description carries the full burden. It discloses the important behavioral filter (>=10,000 shares threshold/0.01 normalized) and that 'market info' is included. However, it fails to explain that the wallet address is implicit/automatically determined rather than passed as a parameter, which could confuse the agent.

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 efficiently structured in two clauses: what it fetches and what it returns/filter criteria. Every element serves a purpose. It could be improved by front-loading the pagination behavior or auth context, but it is appropriately sized with minimal waste.

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

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

Given the tool has only 2 optional parameters and no output schema, the description provides the essential behavioral context (the share threshold). However, without an output schema, it should ideally describe the structure of the returned positions more thoroughly, and it leaves ambiguity regarding the wallet address 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 100% description coverage for its two parameters (limit, pagination_key), establishing a baseline score of 3. The description does not mention these parameters, but given the high schema coverage, it doesn't need to. The mention of 'proxy wallet address' in the description is confusing since no such parameter exists in 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 the tool 'Fetches all Polymarket positions' (specific verb + resource) and includes the specific filter criteria 'balance >= 10,000 shares (0.01 normalized)'. However, it mentions operating on 'a proxy wallet address' without clarifying how that address is provided (likely implicit/auth-based), which slightly muddles the scope.

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?

There is no explicit guidance on when to use this tool versus siblings like 'dome_wallet' or 'dome_activity'. While 'Polymarket positions' implies a specific use case, the description does not state prerequisites (e.g., requiring an authenticated session) or suggest alternatives for different data needs.

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 successfully conveys the cross-platform equivalence behavior (matching markets across Polymarket/Kalshi), but fails to disclose operational details like rate limits, caching behavior, or what constitutes 'equivalence' between markets.

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, efficiently structured sentence without filler words. Information is front-loaded with the action verb. The only detriment is the inaccurate inclusion of 'sport' which wastes cognitive load on a non-existent parameter.

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 this is a single-parameter tool with no output schema and no annotations, the description provides minimal viable context by explaining the cross-platform equivalence concept. However, it should ideally describe the return structure or what data fields identify equivalent markets across platforms.

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?

While the schema has 100% coverage and documents the date format (YYYY-MM-DD), the description introduces confusion by referencing a 'sport' parameter that doesn't exist in the schema. This mismatch between description and schema reduces clarity rather than adding value.

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

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

The description clearly identifies the core function (finding equivalent markets across prediction platforms like Polymarket and Kalshi) and the domain (sports events). However, it incorrectly implies the tool filters 'by sport and date' when the schema only contains a date parameter, creating confusion about the tool's actual scope.

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 provided on when to use this tool versus siblings like dome_sports or dome_markets. The description doesn't clarify prerequisites (e.g., whether to use dome_sports first to identify valid sports) or when cross-platform equivalence lookup is preferable to single-platform queries.

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 of behavioral disclosure, yet it fails to mention whether this is a read-only operation, what format the response takes, or any rate limiting concerns. The description only states the functional purpose without disclosing side effects, error behaviors, or authentication requirements.

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

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

The description is a single, efficient sentence that front-loads the core action ('Find equivalent markets') and immediately qualifies it with scope (sports events), platforms (Polymarket, Kalshi), and input methods. Every phrase serves a distinct purpose in clarifying the tool's specific function 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?

While the description adequately explains the tool's purpose for a lookup operation with well-documented parameters, it lacks critical context given the absence of annotations and output schema; specifically, it omits details about the return structure, success/failure behaviors, or operational constraints. For a cross-platform market lookup tool, this represents a minimally viable but incomplete specification.

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

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

The input schema has 100% description coverage, documenting both the kalshi_event_ticker and polymarket_market_slug parameters including their mutual exclusivity constraints. The description references these parameters conceptually ('using a...') but does not add semantic meaning, syntax details, or usage examples beyond what the schema already provides, warranting the baseline 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 uses the specific verb 'Find' with the resource 'equivalent markets across different prediction market platforms' and narrows the scope to 'sports events.' It clearly distinguishes from siblings like dome_markets or dome_sport_by_date by emphasizing the cross-platform equivalence functionality rather than general market listing or date-based sports queries.

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 by mentioning the required inputs ('using a Polymarket market slug or a Kalshi event ticker'), but it does not explicitly state when to prefer this tool over siblings like dome_sport_by_date or dome_markets. No explicit when-not guidance or alternative recommendations are provided.

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

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

With no annotations provided, the description effectively compensates by disclosing return content ('executed trades with pricing, volume, and taker side information') and critical unit constraints ('All timestamps are in seconds'). It implies read-only behavior through 'Fetches' but does not explicitly state safety properties.

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 three-sentence structure is optimally front-loaded: purpose with filtering scope, return value description, and timestamp units. Every sentence provides distinct information with no redundancy or waste.

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

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

While the description covers the basic operation and return format adequately for a data retrieval tool, it is incomplete regarding the tool ecosystem. The existence of 'dome_trade_history_get' as a sibling creates ambiguity that the description must resolve but doesn't. No output schema exists to compensate.

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 100% schema coverage, the description adds valuable semantic context by grouping parameters as 'optional filtering by ticker and time range' and emphasizing the timestamp units. This framing helps agents understand the filtering paradigm beyond individual parameter definitions.

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 'Fetches historical trade data for Kalshi markets' with specific resource and domain identification. However, it fails to distinguish from the sibling tool 'dome_trade_history_get', which appears to be a functional duplicate or variant, leaving agents without guidance on which to select.

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 mentions 'optional filtering' implying parameters are not required, but provides no explicit guidance on when to use this tool versus alternatives, particularly the critical distinction from 'dome_trade_history_get'. No prerequisites, exclusions, or selection criteria are provided.

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

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

No annotations are provided, so the description carries the full disclosure burden. It mentions 'optional filtering' but omits pagination behavior (despite limit/offset params), rate limits, data freshness guarantees, or whether empty filters return all records. No indication of what the trade data contains.

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

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

Single sentence, front-loaded action verb ('Fetches'), no redundant words. Efficiently summarizes the filter dimensions without verbosity.

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 an 8-parameter data retrieval tool with no output schema and no annotations, the description is insufficient. It lacks return value structure, sibling differentiation, pagination guidance, and scope constraints (e.g., max historical range).

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 100% schema description coverage, the baseline is 3. The description adds semantic mapping by grouping parameters into business concepts (market, condition, token, time range, wallet), but doesn't clarify the pagination logic or time format details 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 states the tool fetches historical trade data and lists filter dimensions, but fails to distinguish from the sibling tool 'dome_trade_history' (without _get suffix). Given the near-identical naming, this ambiguity creates selection risk for the agent.

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 provided on when to use this tool versus 'dome_trade_history' or other data retrieval siblings like 'dome_orderbook_history_get'. No prerequisites or exclusion criteria are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies the read-only 'fetch' operation and lists return fields, but lacks details on performance characteristics (beyond the schema note), rate limits, caching behavior, or error conditions (e.g., what happens if an invalid address is provided).

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

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

The description consists of three efficient sentences that are front-loaded with the core action (fetching wallet info). Every sentence contributes distinct information: input method, basic returns, and optional metrics. There is no redundant or filler text.

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

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

Given the absence of an output schema, the description adequately documents the return structure (associated EOA, proxy, wallet type, and optional trading metrics). With 100% input schema coverage, the description doesn't need to elaborate heavily on inputs, though it could benefit from mentioning error handling or the specific 'Unix timestamp' format for time parameters (which is only in the schema).

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 100% schema description coverage, the description adds value by integrating the parameter semantics into a coherent narrative. Specifically, it provides the concrete example 'with_metrics=true' and explains the EOA/proxy choice at the conceptual level, helping the agent understand the parameter interaction beyond individual field 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 'Fetches wallet information' using specific resources (EOA or proxy addresses) and identifies what it returns (EOA, proxy, wallet type, optional metrics). However, it does not explicitly differentiate from sibling tool 'dome_wallet_profitandloss', leaving potential ambiguity about which wallet tool to use for financial vs. metadata queries.

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

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

The description implies the mutual exclusivity of EOA/proxy inputs through the word 'either', and the schema descriptions clarify this constraint explicitly. However, there is no explicit guidance on when to use this tool versus 'dome_wallet_profitandloss' or 'dome_activity', or when to set with_metrics=true versus false.

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

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

With no annotations provided, the description carries full burden and successfully discloses critical behavioral traits: it explicitly defines the calculation methodology (realized gains only from confirmed sells or redeems, not until market redemption) and clarifies the divergence from dashboard expectations. Missing minor details like rate limits or empty response 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?

Four sentences with zero waste: core purpose is front-loaded, followed by the critical distinction from Polymarket UI, then calculation methodology. Every sentence earns its place by providing essential semantic or behavioral context 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?

The description adequately covers the calculation methodology and data semantics for a financial tool, but has a significant gap regarding how the wallet address is specified (mentioned in text but absent from schema). Without an output schema, it also omits description of the return structure or 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?

Schema description coverage is 100%, establishing a baseline of 3. The description mentions a 'specific wallet address' which does not appear as a parameter in the schema, creating ambiguity about whether the wallet is derived from authentication context. It does not add syntax details beyond the schema's defaults and examples.

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 'Fetches the realized profit and loss (PnL) for a specific wallet address' with specific scope (time range, granularity). It effectively distinguishes the data concept (realized vs unrealized PnL) from Polymarket's dashboard, but does not explicitly differentiate from sibling tools like dome_wallet or dome_trade_history.

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 implicit usage guidance by explaining that this returns realized gains only (from sells/redeems), unlike Polymarket's unrealized PnL dashboard. However, it lacks explicit 'when to use' guidance comparing it to sibling wallet or trading history tools, and does not mention prerequisites like wallet authentication.

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 of behavioral disclosure. It fails to indicate whether this is read-only, what happens when no acquisition data exists, rate limits, or data freshness. Only mentions that it 'provides detailed information' without behavioral specifics.

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 minimal fluff. The second sentence clarifies scope with specific examples (mergers, takeovers). Minor deduction for redundancy ('using the Acquisition Ownership API' restates the tool name concept).

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 2-parameter tool with no output schema, the description adequately explains the domain concept (acquisition ownership tracking). However, lacking annotations and output schema, it misses behavioral context and return value structure that would help an agent handle responses.

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 100% schema description coverage (symbol and limit both documented), the baseline is 3. The description adds context that 'symbol' refers to tracking ownership changes for that entity, but does not add format constraints, validation rules, or syntax details 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 the tool tracks stock ownership changes during acquisitions, with specific examples (mergers, takeovers, beneficial ownership). It distinguishes itself from sibling M&A tools by focusing specifically on ownership structure impacts rather than deal details.

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

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

No explicit guidance on when to use this tool versus siblings like getLatestMergersAcquisitions or searchMergersAcquisitions. While the scope is implied by 'ownership changes,' there are no when/when-not conditions or prerequisites stated.

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 disclosure burden. Claims 'real-time market activity' but omits return format, pagination, rate limits, or auth requirements. The filtering claim is functionally inaccurate given the schema.

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 of reasonable length, but the second sentence wastes space on unsupported functionality (filtering) and marketing language ('ensuring you access') rather than factual behavioral disclosure.

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

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

No output schema exists, yet the description fails to describe return values (symbol list? full profiles? exchanges?). For a parameter-free list tool, output description is essential for usability.

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 zero parameters (baseline 4), the description incorrectly implies filtering parameters exist ('allows users to filter'). This contradicts the empty schema with additionalProperties: false, creating false expectations about required inputs.

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?

States it lists actively trading companies and instruments, but falsely claims filtering capability ('allows users to filter') which contradicts the empty input schema. Fails to differentiate from sibling list tools like getMostActiveStocks or getCryptocurrencyList.

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 no guidance on when to use this versus alternative list endpoints such as getCryptocurrencyList, getETFList, or getMostActiveStocks. No prerequisites or exclusion criteria mentioned.

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

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

With no annotations provided, the description carries the full burden. It mentions the external data source (FMP API) and input type (historical price data), but fails to disclose safety properties (read-only vs destructive), caching behavior, rate limits, or error handling for invalid symbols.

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 zero waste. The first sentence front-loads the core action (Calculate ADX), while the second provides essential domain context (trend strength analysis). 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?

For a single-indicator retrieval tool with complete schema coverage, the description is minimally viable. It explains what ADX represents financially, but given the lack of output schema and annotations, it should ideally describe the return format or data availability limits.

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 all five parameters (symbol, periodLength, timeframe, from, to) adequately documented in the JSON schema. The description adds minimal semantic value beyond the schema (only implying historical data relates to date parameters), warranting the baseline 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 calculates the Average Directional Index (ADX) using the FMP API, specifying the financial metric (ADX) and its purpose (trend strength/direction analysis). While it defines what ADX measures, it doesn't explicitly differentiate when to choose ADX over sibling technical indicators like getRSI or getSMA.

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 trend strength analysis but provides no explicit guidance on when to use this tool versus alternative technical indicators (e.g., RSI for momentum, SMA for simple averages). No prerequisites, rate limit warnings, or error scenarios are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It partially satisfies this by listing specific return data types (bid/ask prices, volume), but omits operational details such as read-only safety, idempotency, rate limits, or error handling behaviors that agents need when annotations are absent.

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

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

The description consists of exactly two efficient sentences with no filler. The first sentence front-loads the core purpose (accessing aftermarket quotes), while the second elaborates on specific data points returned, making every word earn 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?

Given the low complexity (one required string parameter) and lack of output schema, the description adequately covers return value semantics by mentioning bid/ask prices and volume. It could be improved by explicitly stating the return structure (e.g., 'returns a single quote object'), but is sufficient for a simple data retrieval 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?

The input schema has 100% description coverage for its single 'symbol' parameter. Since the schema already documents the parameter as 'Stock symbol,' and the description does not add additional semantic context (e.g., format examples like 'AAPL' or case sensitivity), it meets the baseline expectation for high-coverage schemas.

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 accesses 'real-time aftermarket quotes for stocks' using the specific verb 'access.' It distinguishes from siblings like getQuote and getBatchAftermarketQuote by emphasizing 'aftermarket' and 'outside of regular trading hours,' though it does not explicitly contrast with the batch variant (getBatchAftermarketQuote) or mention the single-symbol nature implied by the schema.

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 implied usage context by noting the data is for 'outside of regular trading hours,' suggesting when to prefer this over standard quote tools. However, it fails to explicitly name alternatives (e.g., getQuote for regular hours, getBatchAftermarketQuote for multiple symbols) or state prerequisites like requiring a valid stock symbol format.

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 compensates partially by disclosing return data fields ('trade prices, sizes, and timestamps') since no output schema exists. However, it omits rate limits, error behaviors, data retention windows, and whether this returns a snapshot or streaming feed.

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 well-structured sentences with zero waste. First sentence establishes purpose and timing; second details specific data points accessed. Information is front-loaded and appropriately sized for tool complexity.

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

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

Adequate for a simple single-parameter retrieval tool. Given no output schema, the description appropriately enumerates the data fields returned (prices, sizes, timestamps). Could improve by noting error cases (e.g., no aftermarket activity) or symbol validation, but sufficient for agent selection.

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 100% description coverage ('Stock symbol'), establishing baseline 3. The description doesn't add parameter-specific details (e.g., format examples like 'AAPL', case sensitivity, or validation rules) beyond what the schema provides, but none are required given the simple single-parameter structure.

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?

Clear verb ('Track') and resource ('real-time trading activity'), with specific domain context ('after regular market hours', 'post-market session'). Implicitly distinguishes from sibling getAftermarketQuote by emphasizing executed trades ('trade prices, sizes, and timestamps') rather than quotes, though it doesn't explicitly name sibling tools.

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

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

Provides temporal context ('after regular market hours') but lacks explicit guidance on when to use this versus getBatchAftermarketTrade (for multiple symbols) or getAftermarketQuote (for quote data vs trade data). No prerequisites or exclusions stated.

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. While 'View' implies read-only behavior, the description lacks details about data freshness, caching policies, rate limits, or whether this returns real-time or scheduled hours. No mention of potential performance implications for retrieving all exchanges at once.

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

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

The description consists of two brief sentences. The second sentence ('Check when different markets are active') is slightly redundant with the first, restating the same functionality rather than adding new information, but the overall structure is efficient and front-loaded.

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

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

Given the absence of an output schema, the description should ideally characterize the return format (e.g., whether it includes timezone data, holiday schedules, or session types). While the purpose is clear for a simple parameterless tool, the lack of return value documentation leaves a gap in contextual completeness.

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

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

The input schema contains zero parameters, which per guidelines establishes a baseline score of 4. The description correctly implies no filtering is available by stating it retrieves hours for 'all exchanges'.

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 'View[s] the market hours for all exchanges' with specific verb and resource. The inclusion of 'all' implicitly distinguishes it from the sibling tool getExchangeMarketHours (singular), though it does not explicitly name that alternative.

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 the singular getExchangeMarketHours. It does not indicate whether this returns a bulk dataset suitable for caching or if users should prefer the specific exchange variant for targeted queries.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'real-time' data, it lacks critical details about what constitutes 'short quotes' (the only parameter), expected response structure, authentication requirements, or rate limiting constraints.

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

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

The description consists of two efficient sentences without significant fluff. However, the second sentence ('giving them a broad view...') is somewhat generic and could have been used to clarify the 'All' distinction from siblings or explain the return format.

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 single-parameter data retrieval tool, the description is minimally adequate. However, given the lack of output schema and annotations, it should have clarified the distinction from 'getIndexQuotes' and explained what data fields are returned (e.g., price, volume, change percent).

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

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

The input schema has 100% description coverage for its single 'short' parameter. Per the rubric, this establishes a baseline score of 3. The main description adds no additional context about the parameter's function or the difference between short and full quotes.

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 identifies the tool provides 'real-time quotes for a wide range of stock indexes' using specific verbs and resources. However, it fails to explicitly distinguish from the sibling tool 'getIndexQuotes', leaving ambiguity about why 'All' is the correct choice versus filtering by specific symbols.

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 is provided on when to use this tool versus alternatives like 'getIndexQuote' (singular) or 'getIndexQuotes'. There is no mention of prerequisites, rate limits, or when the 'short' parameter should be utilized.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal context. It doesn't indicate data volume, rate limiting concerns for bulk retrieval, default pagination behavior when parameters are omitted (both are optional), or whether the data is static or frequently updated. The mention of 'FMP' assumes provider context not all agents may have.

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-sentence structure is appropriately sized and front-loaded with the core action. Minor redundancy exists in referencing 'FMP All Industry Classification API' which partially restates the tool name, but otherwise every sentence earns its place by defining scope and return value types.

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 tool with only two optional pagination parameters and no output schema, the description adequately compensates by enumerating the specific data fields returned (SIC codes, industry titles). It appropriately doesn't speculate on return structure beyond what's verifiable, though mentioning the expected result count or dataset size would improve completeness.

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

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

The input schema has 100% description coverage for both parameters (page and limit), establishing a baseline of 3. The description adds no domain-specific context about valid ranges, maximum limits, or the relationship between pagination and the 'comprehensive' dataset mentioned in the first sentence.

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 accesses 'industry classification data' and specifies key outputs (SIC codes, industry titles, business contact information). However, it doesn't explicitly differentiate from similar siblings like 'getIndustryClassificationList' or 'searchIndustryClassification', leaving ambiguity about which to use for bulk retrieval versus targeted searches.

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 provided on when to use this tool versus alternatives. Given the presence of 'searchIndustryClassification' in the sibling list, the description should explicitly state this is for bulk/paginated retrieval of all classifications, while search is for filtering specific results. The optional pagination parameters imply bulk usage, but this isn't explicitly stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses what data is returned (free float, float shares, outstanding shares) but omits operational details like pagination behavior, rate limits, or authentication requirements that would help an agent handle the response correctly.

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 two-sentence structure is efficient and front-loaded with the core action. Minor redundancy exists in mentioning 'FMP All Shares Float API' which restates the tool name, but overall there is little waste.

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

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

Given the tool's moderate complexity (2 optional pagination parameters, no output schema), the description adequately covers the resource and return fields. However, it lacks guidance on handling paginated responses or result set size expectations, which would be valuable for a bulk 'getAll' operation.

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

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

The input schema has 100% description coverage (page and limit are well-documented with defaults and max values), establishing a baseline of 3. The description does not add additional parameter context (e.g., explaining pagination strategy), but the schema is self-sufficient.

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 'Access[es] comprehensive shares float data for all available companies' and specifies the data fields returned (free float, float shares, outstanding shares). It distinguishes this as a bulk retrieval tool ('all available companies') which differentiates it from the sibling 'getShareFloat' (singular), though it could explicitly name that sibling for clarity.

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 bulk usage by specifying 'all available companies' and mentions the use case ('analyze liquidity'), but lacks explicit guidance on when to use this versus the single-company 'getShareFloat' alternative or pagination behavior for large result sets.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It identifies the data source (FMP Financial Estimates API) and examples of returned metrics, but lacks critical safety information (read-only status, rate limits, data freshness/delay) that agents need for proper invocation.

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

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

The description consists of two well-structured sentences with zero redundancy. The first sentence establishes the core function and API source; the second provides concrete examples of returned data and use case context. Every sentence 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?

Given 100% schema coverage and simple parameter types (no nested objects), the description adequately compensates for the missing output schema by listing specific returned metrics (revenue, EPS). However, it could improve by noting the read-only nature of the operation or pagination behavior details.

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

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

The input schema has 100% description coverage (symbol, period, page, limit all documented). The description mentions 'stock symbols' and financial estimates context but does not add semantic details beyond the schema (e.g., format requirements for symbol, or that period affects forecast horizon). Baseline 3 applies 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 retrieves 'analyst financial estimates' with specific examples (revenue, EPS) and identifies the API source (FMP). However, it does not explicitly distinguish from similar sibling tools like getEarningsReports or getPriceTargetConsensus, which also deal with analyst data but different data types.

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 mentions the general use case ('inform your investment decisions') but provides no explicit guidance on when to use this tool versus alternatives like getEarningsReports (actuals vs estimates) or getPriceTargetConsensus. No prerequisites, exclusions, or selection criteria are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal details. It references the 'FMP Available Countries API' indicating an external dependency, but fails to disclose idempotency, caching behavior, rate limits, or error conditions. It also does not describe the return format despite the absence of an output schema.

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

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

The description consists of two sentences. The first is efficient and descriptive. The second is indirect ('This API enables users...') and speculative about downstream usage rather than describing the tool's actual function. It could be condensed to a single, clearer sentence without losing meaning.

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

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

No output schema exists, yet the description fails to describe what the endpoint returns (e.g., country codes, names, objects, array structure). For a zero-parameter tool with no annotations and no output schema, the description should compensate by detailing the response format, which it omits. This leaves significant gaps in the contract.

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 contains zero parameters, establishing a baseline score of 4. The description correctly implies no filtering parameters are needed ('comprehensive list'), which aligns with the empty schema. No additional parameter semantics are required or provided.

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 identifies the resource (countries with available stock symbols) and the action (access/list). It distinguishes from sibling tools like getAvailableExchanges and getAvailableSectors by specifying the geographic scope. However, the second sentence drifts into user capabilities ('enables users to filter and analyze') rather than tool function, slightly diluting the clarity.

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 siblings (e.g., getAvailableExchanges) or prerequisites (e.g., needing country codes before calling other endpoints). It implies usage context ('filter and analyze') but never explicitly states selection criteria.

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 disclosure burden. While it mentions scope ('complete list', 'comprehensive overview'), it fails to disclose return format, pagination behavior, rate limits, or explicit read-only status. For a data retrieval tool with zero annotation coverage, this provides minimal behavioral 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 two sentences with minimal bloat. Minor redundancy exists in the second sentence ('This API provides...') which restates what is already implied, but overall the structure is front-loaded with the core action and remains appropriately sized for the tool's simplicity.

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 low complexity (zero parameters, no annotations, no output schema), the description adequately covers the basic function. However, it lacks description of the return value structure which would be helpful compensation for the missing output schema, leaving a minor gap in completeness.

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

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

The input schema contains zero parameters, establishing a baseline score of 4. The description appropriately does not introduce parameter details since none exist, though it implicitly confirms the tool requires no filtering inputs by mentioning 'complete list'.

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 the tool 'Access[es] a complete list of supported stock exchanges' using a specific verb and resource. It clearly distinguishes from siblings like getAvailableCountries or getAvailableSectors by focusing specifically on 'global stock exchanges' and mentioning the FMP API context.

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 implied usage context ('allowing users to identify where securities are traded and filter data by specific exchanges'), suggesting when it might be useful. However, it lacks explicit guidance on when to use this versus sibling tools like getAvailableCountries or getExchangeMarketHours, and includes no 'when-not-to-use' exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify that this is a safe read-only operation, lacks return format details (array of strings vs objects), and omits rate limits or pagination behavior despite referencing the external FMP API.

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 well-structured sentences with no redundancy. The first states the core function; the second provides context. Every sentence earns its place with efficient information density.

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

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

For a zero-parameter tool without an output schema, the description adequately explains the conceptual return (a list of industries) but fails to describe the data structure, fields, or format of the returned industries, leaving agents uncertain about what they will receive.

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?

Zero parameters are required, establishing a baseline score of 4 per evaluation rules. The description appropriately does not invent parameter semantics where 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 identifies the resource (industries) and action (access/list), specifying these are industries where stock symbols are available. However, it does not explicitly differentiate from similar classification siblings like getAvailableSectors or getAllIndustryClassification.

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 second sentence mentions the use case (filtering and categorizing companies), there are no explicit guidelines on when to prefer this over alternatives like getAvailableSectors or getAvailableCountries, nor any prerequisites mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a 'complete list' but fails to describe the return format (array of strings vs objects), whether the data is static or cached, rate limits, or authentication requirements.

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

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

The description consists of two reasonably efficient sentences. The second sentence ('enabling deeper analysis...') is slightly generic but provides context for usage intent without excessive verbosity.

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 absence of an output schema, the description should ideally describe the return structure (e.g., list of sector names/objects). It explains what the tool accesses but not what the caller receives back, leaving a gap for a simple list-fetching 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?

The input schema contains zero parameters, which establishes a baseline score of 4. The description correctly implies no filtering is needed by stating 'complete list', but does not explicitly confirm that no inputs are required.

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

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

The description clearly states the tool 'Access[es] a complete list of industry sectors' using a specific API, providing both verb and resource. However, it does not distinguish from the sibling tool 'getAvailableIndustries' despite the potential confusion between sectors and industries in financial classification systems.

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 description explains that the API 'helps users categorize and filter companies,' it provides no explicit guidance on when to use this tool versus alternatives like 'getAvailableIndustries' or 'getAllIndustryClassification', nor does it mention prerequisites or specific use cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about the return payload (indicating that results include 'how many' transcripts are available per symbol), but omits other critical behavioral traits such as read-only safety, idempotency, pagination behavior, or rate limiting considerations.

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

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

The description consists of two efficiently structured sentences with no redundant information. The first sentence establishes the core action and resource, while the second specifies the data content (availability counts), making optimal use of limited space.

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 input parameters, no nested objects) and lack of output schema, the description adequately covers the essential return value information by specifying that it retrieves both the list of symbols and quantitative availability metrics. However, it could be improved with a brief note on the expected data structure or 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?

The input schema contains zero parameters, which establishes a baseline score of 4. The description appropriately does not invent parameter-related information, and the empty schema is self-documenting for this simple list retrieval operation.

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 defines the tool's purpose: retrieving a complete list of stock symbols that have earnings call transcripts available, including counts of accessible transcripts. It effectively distinguishes this from siblings like `getEarningsTranscript` (which presumably fetches actual transcript content) by focusing on symbol availability rather than document retrieval.

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 related alternatives like `getEarningsTranscript`, `getEarningsTranscriptList`, or `getLatestEarningsTranscripts`. It fails to indicate that this is a prerequisite discovery tool for identifying which companies have transcript data before attempting to fetch specific documents.

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 disclosure burden. It mentions 'Get' implying a read operation, but doesn't clarify rate limits, pagination behavior, data freshness, whether data is cached, or what happens if the symbol is invalid. 'Recent_n' parameter suggests time-series data but temporal semantics aren't explained.

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 efficiently structured as a single front-loaded sentence with zero redundancy. However, extreme brevity (5 words) contributes to under-specification rather than clarity given the tool's domain complexity.

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 crowded namespace of balance sheet-related siblings and absence of output schema, the description is inadequate. It doesn't explain output format, financial statement period granularity, currency, or how this aggregates data differently from getBalanceSheetStatement or getBalanceSheetStatementAsReported.

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 'symbol' and 'recent_n' fully documented in the JSON schema. The description adds no parameter-specific context (e.g., whether symbol format varies by exchange, or if recent_n refers to quarters or years), warranting the baseline score 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 states the verb ('Get') and resource ('company balance sheet data'), but fails to distinguish from numerous siblings (getBalanceSheetStatement, getBalanceSheetStatementAsReported, getBalanceSheetStatementTTM, etc.). It doesn't specify whether this returns annual/quarterly data, as-reported or standardized format, or TTM figures.

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 provided on when to use this tool versus the six sibling balance sheet endpoints. No prerequisites mentioned (e.g., whether symbol needs to be uppercase), no filtering capabilities described, and no indication of data frequency or reporting standards.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It identifies the bulk nature ('multiple companies') and data type ('growth data'), but fails to disclose critical bulk API behaviors: pagination handling, rate limiting, authentication requirements, or read-only safety assurances (implied by 'retrieve' but 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 but contains filler text ('The Balance Sheet Growth Bulk API allows users to') that restates the tool name rather than adding value. The benefit clause ('enabling detailed analysis...') is somewhat redundant given the straightforward retrieval 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?

For a two-parameter tool with simple string inputs and no output schema, the description adequately covers the core purpose. However, given the complexity implied by 'Bulk' operations and the absence of annotations, it should explicitly address scope limitations or pagination behavior to be fully 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?

The input schema has 100% description coverage with clear examples and enumerated values (Q1-Q4, FY). The description adds no parameter-specific semantics, but the baseline score of 3 is appropriate since the schema fully documents both required fields without needing additional clarification.

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

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

The description clearly states the tool retrieves 'growth data across multiple companies' balance sheets' using specific verbs and resources. It distinguishes from siblings like getBalanceSheetStatementsBulk (non-growth) and getBalanceSheetStatementGrowth (single company) by emphasizing both 'growth data' and 'multiple companies,' though the phrase 'allows users to' is filler that prevents a 5.

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

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

The description provides no explicit guidance on when to use this tool versus single-company alternatives (getBalanceSheetStatementGrowth) or non-growth bulk endpoints (getBalanceSheetStatementsBulk). While 'multiple companies' implies bulk usage scenarios, there are no explicit when/when-not directives or named 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 are provided, so the description carries the full burden. It discloses the scope (publicly traded companies) and implies detail level ('detailed'), but lacks critical behavioral context such as data latency (real-time vs. quarterly reporting delays), rate limits, authentication requirements, or whether the operation is idempotent.

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

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

The description consists of two efficient sentences with zero waste. The first sentence defines the tool's function, and the second sentence explains the value proposition/use case. Information is front-loaded and every clause 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?

Given the simple input schema (3 primitive parameters, 100% documented) and lack of output schema, the description provides adequate business context. However, without annotations or output schema, the description should ideally hint at the return structure (e.g., JSON array of quarterly reports) or data freshness, which it omits.

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 100% schema description coverage, the baseline score applies. The schema clearly documents the 'symbol', 'period', and 'limit' parameters. The description adds no parameter-specific guidance (e.g., explaining that 'period' filters fiscal quarters), but none is needed given the comprehensive 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 specifies the action ('Access'), resource ('detailed balance sheet statements'), and target entities ('publicly traded companies'). It further elaborates on the data contents (assets, liabilities, shareholder equity) which helps distinguish it from income statement or cash flow siblings. However, it fails to differentiate from closely named siblings like 'getBalanceSheetStatementAsReported' or 'get_balance_sheet'.

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 description implies a use case ('gain insights into a company's financial health'), it provides no explicit guidance on when to prefer this tool over the numerous sibling balance sheet tools (e.g., getBalanceSheetStatementGrowth, getBalanceSheetStatementTTM, getBalanceSheetStatementAsReported). Given the crowded namespace, this lack of differentiation is a significant selection hazard.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source ('official filings') and content scope (assets, liabilities, equity), but omits other behavioral traits like rate limits, caching behavior, or idempotency. The verbs 'Access' and 'View' imply read-only behavior, though this is not explicitly confirmed.

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

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

The description consists of two sentences with minimal redundancy. The first sentence repeats the tool name pattern ('As Reported Balance Statements') slightly unnecessarily, but overall the content is front-loaded and efficient without extraneous marketing language.

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 absence of an output schema, the description compensates by specifying the three major balance sheet components returned (assets, liabilities, equity). For a simple 3-parameter retrieval tool with primitive types, this level of description is sufficient, though explicit mention of return format (e.g., JSON array of filings) would improve it further.

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%, documenting symbol, period, and limit adequately. The description does not add parameter-specific semantics (e.g., explaining that 'symbol' expects a ticker, or that 'period' filters filing frequency) beyond what the schema already provides, warranting the baseline 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 accesses 'balance sheets as reported by the company' and mentions specific data categories (assets, liabilities, equity). It references 'official filings' which hints at the 'As Reported' distinction from siblings like getBalanceSheetStatement, though it could explicitly clarify the difference between standardized and as-reported data.

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 lacks explicit guidance on when to select this tool versus the similar getBalanceSheetStatement (standardized) or getFinancialStatementFullAsReported (full statements). While 'directly from official filings' implies usage for raw SEC data, it does not explicitly state when-not to use alternatives or provide decision criteria.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the analytical focus (tracking changes in financial position) but omits critical operational details: whether this calculates YoY/QoQ growth rates, pagination behavior, rate limits, or that it is a safe read-only operation. The description hints at the calculation type ('growth') but doesn't specify the methodology.

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 efficient sentences with minimal redundancy. The first sentence includes the API name which slightly restates the tool name, but the second sentence effectively communicates the value proposition. Information is front-loaded with the primary action ('Analyze the growth') appearing immediately.

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 absence of an output schema and annotations, the description should explain what data structure or growth metrics are returned (e.g., percentage changes, raw deltas, time series format). It explains the analytical purpose but leaves the actual return values undocumented, which is a significant gap for a financial analysis 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?

Input schema has 100% description coverage with clear definitions for symbol, period, and limit. The description mentions analyzing growth 'over time' which loosely maps to the period/limit parameters, but adds no additional semantic context such as expected symbol format (ticker vs CIK) or that limit controls the lookback period for growth calculations.

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 analyzes 'growth of key balance sheet items over time' and mentions tracking changes in assets, liabilities, and equity. This distinguishes it from the standard getBalanceSheetStatement sibling. However, it fails to differentiate from similar growth variants like getBalanceSheetGrowthBulk or getBalanceSheetStatementTTM.

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 single-symbol tool versus the bulk variant (getBalanceSheetGrowthBulk), nor when to prefer this over TTM or raw statement versions. No prerequisites or alternative selection criteria are mentioned despite numerous sibling tools with overlapping functionality.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal insight. It fails to mention critical bulk-operation traits: expected payload size, whether the response includes all available companies for the period, rate limiting concerns, or pagination behavior. 'Comprehensive access' is vague and doesn't disclose the scope or performance characteristics of this operation.

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

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

The description is appropriately sized at three sentences with no significant fluff. The first sentence is slightly redundant (repeating 'Bulk Balance Sheet Statement API'), but the information is generally front-loaded with the specific data contents (assets, liabilities, equity) mentioned early, followed by the use case.

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

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

Given that this is a bulk data tool with no output schema and no annotations, the description is notably incomplete. It omits crucial context for a bulk endpoint: the expected volume of data, how to handle large responses, whether the data is real-time or cached, and the exact mechanism of company selection (all companies vs. filtered). For a tool returning potentially massive datasets, this lack of behavioral context is a significant gap.

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

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

The input schema has 100% description coverage for both parameters (year and period), establishing a baseline score of 3. The description adds no additional parameter context—such as valid date ranges, the interaction between period and year, or that these are the only filters available for the bulk dataset—so it neither exceeds nor falls 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 clearly identifies the resource (balance sheet data) and action (comprehensive access/retrieving), and distinguishes from single-company siblings via 'across multiple companies.' However, it fails to explicitly clarify that 'bulk' implies returning all available companies without requiring company identifiers (evident from the schema lacking symbol/parameters), which could confuse users familiar with the singular variant.

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 implied usage context ('Ideal for comparing the financial health... on a large scale'), but lacks explicit when-to-use/when-not-to-use guidance. It does not contrast with the singular `getBalanceSheetStatement` or explain that this should be used when analyzing many companies simultaneously versus individual lookups.

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, yet the description omits critical behavioral details: it doesn't explain TTM aggregation logic (rolling 12-month window), doesn't confirm read-only safety, and mentions no rate limits or pagination behavior beyond the 'limit' parameter existing.

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, reasonably efficient. Minor fluff in 'with the Balance Sheet Data API' (redundant given tool name), but otherwise front-loaded with actionable verbs and specific financial components.

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

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

No output schema exists, yet the description doesn't explain the return structure or the critical TTM temporal dimension. Given the tool fetches complex financial data and has no annotations, the description should explicitly define TTM and outline the response 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?

Schema has 100% description coverage ('Stock symbol', 'Limit on number of results'), establishing baseline 3. The description adds no additional parameter semantics (e.g., symbol format, max limit constraints, or default behavior) beyond what the schema already provides.

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?

Clear verb ('Access') and resource ('balance sheet statements'), with specific components listed (assets, liabilities, equity). However, it fails to explain the 'TTM' (Trailing Twelve Months) aspect that distinguishes this tool from the sibling 'getBalanceSheetStatement', leaving the temporal aggregation behavior ambiguous.

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 no guidance on when to use TTM data versus annual/quarterly statements available in sibling tools. No mention of prerequisites, rate limits, or selection criteria between 'getBalanceSheetStatement' and this TTM variant.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the real-time nature, the post-market/aftermarket context, and specific data fields returned (bid, ask prices, volume) which compensates for the missing output schema. It lacks operational details like rate limits or authentication requirements.

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

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

The description consists of two efficient sentences with zero waste. The first sentence front-loads the core action and API identity, while the second details the specific data returned, earning its place by compensating for the absent output schema.

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

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

Given the tool's simplicity (one required string parameter) and lack of output schema, the description is appropriately complete. It clarifies the aftermarket domain and lists return data fields (bid/ask/volume) that would otherwise be unknown. It could be improved by mentioning specific post-market trading hours constraints.

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

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

The input schema has 100% description coverage for its single 'symbols' parameter. The description does not add semantic details beyond the schema (e.g., max symbol count, formatting examples, or validation rules), warranting the baseline score of 3 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 uses specific verbs ('Retrieve', 'Access') and clearly identifies the resource (real-time aftermarket quotes for multiple stocks). It distinguishes itself from sibling tool getAftermarketQuote by emphasizing 'multiple stocks' and 'Batch', and differentiates from getBatchQuotes by specifying 'aftermarket' and 'post-market trading'.

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 through words like 'Batch' and 'multiple stocks', suggesting when to use this over single-quote tools. However, it lacks explicit guidance on when to prefer this over getAftermarketQuote (singular) or getBatchQuotes (regular hours), and states no prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It adds valuable behavioral context by specifying 'real-time' data, 'aftermarket' (post-market) timing, and specific returned fields (prices, volumes, timestamps). However, it omits operational details like error handling for invalid symbols, rate limits, or data freshness guarantees.

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 well-constructed sentences with zero waste. The first sentence front-loads the core action and API context; the second specifies the data content. Every word earns its place with no redundancy or filler content.

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

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

For a single-parameter data retrieval tool with 100% schema coverage, the description adequately covers the essential context: what data is retrieved (aftermarket trades), for what scope (batch/multiple), and what fields are returned. No output schema exists, but the description compensates by listing the data points (prices, volumes, timestamps).

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 100% schema description coverage for the single 'symbols' parameter, the baseline is 3. The description reinforces the batch purpose by mentioning 'multiple stocks' and 'several companies simultaneously,' aligning with the parameter's intent, but does not add syntax details (e.g., case sensitivity, delimiters) beyond what the schema provides.

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

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

The description uses specific verbs ('Retrieve', 'Track') and clearly identifies the resource (aftermarket trading data) and scope (multiple stocks simultaneously). It distinguishes from siblings like getAftermarketTrade (single stock) and getBatchAftermarketQuote (quotes vs trades) by emphasizing 'multiple stocks' and specifying data types like 'trade prices, volumes, and timestamps'.

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 batch usage for 'multiple stocks' and 'several companies simultaneously,' signaling when to use this over single-stock alternatives. However, it lacks explicit guidance naming sibling alternatives (e.g., getAftermarketTrade) or stating when not to use this tool versus quote-based batch endpoints.

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

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

With no annotations provided, the description carries the full burden but lacks critical behavioral details such as rate limits for batch requests, data freshness/staleness, error handling for invalid symbols, or authentication requirements beyond mentioning the FMP API name.

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 clear structure: first establishes the operation and API, second explains the value proposition. Slightly verbose with 'with the FMP Batch Market Capitalization API' but generally 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?

No output schema exists, yet the description fails to specify the return format, data fields (e.g., symbol, marketCap, timestamp), currency, or structure of the response, which is essential for a financial data retrieval 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?

The input schema has 100% description coverage for the single 'symbols' parameter. The description mentions 'multiple companies' which aligns with the parameter but does not add format constraints, maximum symbol limits, or examples beyond the schema's 'comma-separated' definition.

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 (retrieve market capitalization data) and resource (multiple companies/batch), distinguishing it from singular alternatives like getMarketCap through explicit use of 'multiple companies' and 'batch' terminology.

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

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

The description implies the batch use case ('compare market size of various companies simultaneously') but does not explicitly state when to use this versus the singular getMarketCap or provide explicit alternative recommendations.

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

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

With no annotations provided, the description carries the full burden. It discloses 'real-time' data and return contents (prices, volume, detailed data), but omits safety profiles (read-only status), rate limits, error behavior for invalid symbols, or caching 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 consists of two efficient, front-loaded sentences with zero waste. The first establishes the core operation; the second explains the value proposition (portfolio tracking) and return data scope.

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 single-parameter tool without an output schema, the description adequately compensates by specifying the return contents (prices, volume, detailed data). Given the low complexity and lack of nested objects, this is sufficient for agent invocation decisions.

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

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

The input schema has 100% description coverage ('Comma-separated list of stock symbols'), establishing a baseline of 3. The description adds contextual meaning by referencing 'multiple companies' and 'large portfolios,' reinforcing the parameter's purpose without adding syntax details 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 clearly states the tool retrieves 'multiple real-time stock quotes' using the FMP API, distinguishing it from single-quote tools like getQuote. However, it does not explicitly differentiate from sibling getBatchQuotesShort, leaving ambiguity about when to prefer detailed vs. short data.

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

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

The description provides clear context for when to use the tool—'track large portfolios or monitor multiple stocks simultaneously'—guiding the agent toward batch operations. However, it lacks explicit exclusions (e.g., 'do not use for single stocks') or named 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 are provided, so the description carries the full disclosure burden. It successfully notes the 'real-time' nature and lists specific returned fields (price, change, volume), but omits safety characteristics (read-only status), rate limits, or error behaviors that would help an agent understand operational constraints.

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 optimally concise with two well-structured sentences. The first identifies the API and primary function; the second details the specific data returned. No redundant or 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 the absence of an output schema, the description partially compensates by listing the key returned fields (current price, change, volume). However, it misses the opportunity to explicitly contrast with getBatchQuotes regarding data depth, which would help an agent select between the two batch options.

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 100% schema description coverage ('Comma-separated list of stock symbols'), the schema already documents the parameter fully. The description adds minimal semantic value beyond the schema, merely noting 'several companies in one streamlined request' which reinforces but does not extend the parameter semantics. Baseline 3 is appropriate 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?

Description clearly states the tool accesses 'real-time, short-form quotes for multiple stocks' with specific verbs (Access/Get) and resource. It distinguishes from siblings like getQuote (single stock) via 'multiple stocks/batch' and from getBatchQuotes via 'short-form' and the specific data fields mentioned (price, change, volume).

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 ('quick snapshot') but lacks explicit when-to-use guidance versus the sibling getBatchQuotes tool. It does not state when the short-form data is preferable to full batch quotes or what the limitations are.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify critical traits: whether data is real-time or delayed, the ranking methodology (percentage vs. absolute price change), typical list size, or whether the operation is read-only. The term 'Track' is ambiguous regarding subscription vs. snapshot 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?

The description consists of two efficiently structured sentences with no filler. The first sentence front-loads the core action (tracking gainers), while the second provides immediate value context (growth opportunities), making it appropriately sized.

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

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

Given the lack of output schema and annotations, the description is minimally viable but has clear gaps. It omits the timeframe for price changes (e.g., 'today's gainers'), return format (list of symbols vs. full quotes), and data freshness—details necessary for a financial data tool to be invoked with confidence.

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 contains zero parameters, establishing a baseline of 4. The description appropriately does not invent parameter semantics where none exist, though it could have clarified why no filtering is possible (e.g., 'returns the full list of top gainers without filtering').

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

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

The description clearly states the tool retrieves stocks with 'largest price increases' using the Top Stock Gainers API, providing a specific verb and resource. However, it does not explicitly differentiate from siblings like 'getMostActiveStocks' (volume-based) or clarify the timeframe for these gains (intraday vs. daily).

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 a use case ('offering potential growth opportunities') but provides no explicit guidance on when to use this versus alternatives like 'getBiggestLosers' or market analysis tools. There are no prerequisites, filters, or exclusion criteria 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 carries the full burden. It explains what the data represents (significant declines, fastest falling stocks) but omits critical behavioral details like whether the data is real-time or end-of-day, the timeframe for calculating 'largest' drops, rate limits, or return data structure.

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

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

The description consists of two efficient sentences with the primary purpose stated immediately. There is minor redundancy between 'largest price drops' and 'falling the fastest,' but overall structure is sound with no extraneous 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 has no parameters, no annotations, and no output schema, the description adequately covers the conceptual purpose but lacks sufficient detail about the return data format, the specific metric used to determine 'biggest' (percentage vs. absolute), or the time period 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?

The input schema contains zero parameters, establishing a baseline score of 4 per evaluation guidelines. With no parameters to describe, the description is not penalized for parameter omission.

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 accesses data on stocks with the largest price drops, using specific verbs ('Access', 'Identify', 'track') and identifying the resource (stocks with significant declines). It implicitly distinguishes from sibling getBiggestGainers by specifying 'drops' and 'declines,' though it could be more explicit about the 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 implied usage context—use this to identify companies experiencing significant declines or track falling stocks—but lacks explicit when-to-use guidance, prerequisites, or references to alternative tools like getBiggestGainers for opposing market movements.

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 of behavioral disclosure. It fails to mention the data source behavior (Sina), whether it returns quarterly/annual statements, TTM calculations, or the structure of the returned data. The 'recent_n' parameter suggests pagination/limiting behavior, but the description doesn't explain this.

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 at 5 words, but underspecified for the tool's complexity. While not verbose, the single sentence doesn't earn its place effectively because it provides only generic information that could apply to multiple sibling tools without clarifying scope or differentiation.

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 presence of numerous similar cash flow tools and no output schema, the description is incomplete. It lacks explanation of return format, data source specifics (Sina), geographic market focus (implied by '000001' example but not stated), and differentiation from TTM, AsReported, and Growth variants of cash flow statements.

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 100% description coverage ('Data source', 'Stock symbol/ticker', 'Number of most recent records'). The description adds no parameter-specific guidance beyond the schema (e.g., no explanation of the 'sina' source, no format details for the symbol). Baseline 3 is appropriate given complete 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 states the tool retrieves cash flow statement data with a clear verb ('Get') and resource ('company cash flow statement data'), but fails to distinguish from siblings like 'getCashFlowStatement', 'getCashFlowStatementAsReported', or 'getCashFlowStatementTTM'. The critical distinction that this tool sources from Sina (implied by the default parameter value) for potentially different markets is omitted.

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 provided on when to use this tool versus the numerous alternatives (getCashFlowStatement, getCashFlowStatementGrowth, getCashFlowStatementTTM, etc.). No prerequisites, exclusions, or selection criteria are mentioned.

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

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

No annotations are provided, so the description carries the full burden. While it mentions retrieving growth data, it fails to disclose what specific growth metrics are calculated (YoY, QoQ percentages?), return format, pagination behavior, or rate limits for bulk operations.

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

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

The description consists of two efficient sentences that front-load the purpose. The opening 'The Cash Flow Statement Growth Bulk API allows you to' is slightly wordy rather than using an active verb like 'Retrieves', but overall structure is sound with no wasted content.

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

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

For a simple two-parameter tool, the description adequately covers the high-level purpose. However, given the lack of output schema and the complexity of financial 'growth' calculations, it should specify what growth metrics are returned (percentages, periods compared) to be 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?

With 100% schema description coverage for both parameters (year, period), the schema adequately documents inputs. The description adds no additional parameter context (e.g., valid date ranges, format examples), meeting the baseline expectation.

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 'bulk growth data for cash flow statements' for 'multiple companies simultaneously', distinguishing it from single-company tools like getCashFlowStatementGrowth. However, it doesn't explicitly contrast with the singular growth variant (getCashFlowStatementGrowth) to clarify the 'bulk' 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 notes it's 'ideal for analyzing the cash flow growth trends of multiple companies simultaneously', implying when to use it. However, it lacks explicit when-not guidance or named alternatives (e.g., when to use getCashFlowStatementGrowth instead).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but omits key traits: whether this returns structured JSON vs raw text, pagination behavior (despite the limit parameter), data freshness/frequency, or read-only nature. It describes business domain concepts (cash activities) but not technical operational 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?

Two sentences totaling ~30 words. The first sentence is slightly marketing-oriented ('Gain insights'), but the second efficiently specifies the three cash flow activity categories. Information is front-loaded appropriately with no redundant repetition of the tool name.

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 financial data retrieval tool with 3 well-documented parameters and no output schema, the description adequately covers the business purpose but lacks technical completeness. It should mention that this retrieves historical reported data (not projections) and clarify the return structure, given the absence of output schema 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 description coverage is 100% (symbol, period, limit all documented in JSON schema). The description adds no parameter-specific guidance (e.g., explaining that period=Q1-Q4 represents fiscal quarters, or symbol format expectations), warranting the baseline score of 3.

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

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

The description clearly identifies the resource (cash flow statement) and specific content (operations, investments, financing activities) using concrete verbs ('analyze'). However, it fails to distinguish from siblings like getCashFlowStatementAsReported, getCashFlowStatementGrowth, or get_cash_flow, which is critical given the extensive list of cash-flow-related tools.

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

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

No guidance provided on when to use this tool versus alternatives (e.g., bulk endpoints for multiple symbols, TTM endpoints for trailing twelve months, or AsReported for raw SEC filings). The agent must infer applicability from parameter names alone.

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

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

With no annotations provided, the description carries the full disclosure burden. It mentions data comes 'directly from official reports' and identifies the three cash flow sections, but omits pagination behavior (despite having a 'limit' parameter), data freshness, whether 'as reported' means raw XBRL/SEC filings, or response structure 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?

Two sentences with minimal waste. The first sentence contains slight redundancy ('with the As Reported Cash Flow Statements API' restates the tool name), but the second efficiently conveys the three cash flow categories. Information is front-loaded with the core action ('View cash flow statements') appearing immediately.

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

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

Adequate for a basic retrieval tool, mentioning the three standard cash flow sections. However, given the absence of output schema and annotations, the description should clarify the 'as reported' data format distinction and ideally hint at the response structure (e.g., annual/quarterly arrays). Sibling differentiation gap prevents a higher score.

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 100% description coverage (symbol, period, limit). The description implies the 'symbol' parameter by referencing 'company' and implies period by context of financial statements, but adds no semantic value beyond the schema (e.g., no guidance on reasonable limit values or period selection strategy). Baseline 3 is appropriate given schema completeness.

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 identifies the resource (cash flow statements) and specific variant ('as reported'/'directly from official reports'). It specifies the three key sections (operations, investments, financing). However, it fails to distinguish from the sibling 'getCashFlowStatement' (standardized format), which is critical for financial data tools where 'as reported' vs 'standardized' is a key decision point.

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 provided on when to use this tool versus siblings like 'getCashFlowStatement', 'getCashFlowStatementGrowth', or 'getCashFlowStatementTTM'. The description states what the tool does but offers no criteria for tool selection among the numerous cash flow variants available.

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. While it mentions the FMP API provider, it fails to disclose the growth calculation methodology (e.g., YoY vs QoQ), the specific cash flow line items returned, rate limits, or the response structure. 'Measure' implies a read-only operation, but this is not explicitly stated.

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 two-sentence structure is appropriately sized and front-loaded with the key action. Minor redundancy exists between 'Measure the growth rate' and 'Determine how quickly... is increasing or decreasing,' but neither sentence is wasted.

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 tool with simple parameters (3 params, no nesting, 100% schema coverage) but no output schema or annotations, the description minimally suffices by identifying the API and purpose. However, given the crowded namespace of similar financial tools, it lacks completeness by not specifying the growth metrics returned or contrasting with sibling variants.

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 100% schema description coverage, the schema adequately documents symbol, period, and limit. The description mentions 'company's cash flow' and 'over time,' which loosely map to symbol and period, but adds no concrete usage guidance (e.g., ticker format, fiscal quarter semantics) beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool measures 'growth rate of a company's cash flow' using the FMP API, providing a specific verb and resource. It implicitly distinguishes from siblings like getCashFlowStatement by emphasizing 'Growth,' though it doesn't explicitly differentiate from similar growth variants like getCashFlowGrowthBulk or getCashFlowStatementTTM.

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 does not clarify when to prefer this over getCashFlowStatement (raw data), getCashFlowStatementTTM (trailing twelve months), or getCashFlowGrowthBulk (bulk data), leaving the agent without selection criteria.

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, and the description fails to disclose critical behavioral traits for a bulk API: pagination behavior, output format (JSON/CSV), rate limits, or approximate data volume. It only adds domain context about cash flow categories (operating/investing/financing).

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 slight redundancy ('provides access' vs 'enables users to retrieve'). Opens with tautological 'The Cash Flow Statement Bulk API' instead of leading with the action. Not inefficient but could be tighter.

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

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

No output schema exists, yet the description doesn't explain return structure, field coverage, or bulk-specific considerations (e.g., whether it returns an array of statements or a file download). For a bulk data tool, this is a significant gap.

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

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

Input schema has 100% description coverage with clear examples (e.g., '2023', 'Q1'). The description adds no parameter-specific guidance, but baseline 3 is appropriate given the schema comprehensively documents both parameters.

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

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

The description clearly identifies the resource (cash flow statements) and action (retrieve bulk data). It distinguishes from siblings by emphasizing 'bulk' and 'wide range of companies,' though it could explicitly contrast with the singular getCashFlowStatement.

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 provided on when to use this tool versus alternatives like getCashFlowStatement (single company), getCashFlowStatementGrowth, or get_cash_flow. No prerequisites or exclusions mentioned.

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

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

With no annotations provided, the description carries the full burden but omits critical behavioral details: whether the data is real-time or delayed, how the 'limit' parameter affects historical period retrieval (e.g., 5 years vs 10 years), rate limits, or the specific structure of cash flow line items returned.

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 two-sentence structure is efficient, but the opening phrase 'Gain insights into...' is marketing fluff that adds no technical value. The second sentence provides substantive content about cash flow categories, but the TTM aspect remains unexplained.

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 absence of an output schema and annotations, the description inadequately explains what data structure is returned (e.g., whether it includes multiple TTM periods or just the latest). The critical 'TTM' distinction from standard cash flow statements is missing despite the complex sibling tool landscape.

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 descriptions for 'symbol' (Stock symbol) and 'limit' (Limit on number of results). The description adds no additional parameter semantics, examples, or format constraints beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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 identifies the resource (cash flow activities/operations, investments, financing) but fails to clarify the 'TTM' (Trailing Twelve Months) scope implied by the tool name. It does not distinguish this from siblings like getCashFlowStatement or get_cash_flow, leaving ambiguity about whether this returns trailing twelve month data, quarterly, or annual statements.

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 provided on when to prefer this tool over the 100+ sibling financial tools, specifically getCashFlowStatement or getCashFlowStatementGrowth. No prerequisites (like valid stock symbols) or exclusion criteria are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It omits critical details such as pagination behavior, rate limits, data freshness, auth requirements, or the volume of data returned (despite having a 'limit' parameter that suggests large datasets).

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?

While structurally brief (two sentences), the second sentence wastes space on audience demographics rather than functional guidance. The description is not front-loaded with critical behavioral constraints or usage boundaries.

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

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

With no output schema provided, the description fails to compensate by describing the return structure, fields included (e.g., CIK number, company name mappings), or data format. For a simple list endpoint, this omission leaves agents uncertain about what data structure to expect.

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

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

The input schema has 100% description coverage for its single parameter ('limit'), establishing a baseline score of 3. The description adds no semantic context about the parameter (e.g., recommended values, maximum limits, or impact on performance), relying entirely on the 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 identifies the resource (CIK numbers for SEC-registered entities) but uses the vague verb 'access' instead of specific actions like 'list' or 'retrieve all'. It fails to distinguish from sibling tools such as 'searchCIK' or 'getCompanyProfileByCIK', leaving ambiguity about whether this returns a complete list or supports querying.

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 like 'searchCIK' or 'searchCompaniesByCIK'. The second sentence provides generic audience descriptions ('businesses, financial professionals') that do not help an AI agent determine selection criteria or prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully indicates the data types returned (prices, changes, volumes) and real-time nature ('up-to-the-minute'), but lacks operational details such as rate limits, authentication requirements, caching behavior, or error conditions that would be critical for an external API integration.

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

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

The description consists of two efficiently structured sentences with zero redundancy. The first sentence front-loads the action and API context; the second specifies data coverage and commodity examples. Every word contributes to understanding the tool's function.

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

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

Given the low complexity (one optional boolean parameter, no nested objects) and absence of an output schema, the description adequately covers return value categories (prices, changes, volumes). However, it could improve by indicating whether the response is an array or single object, or detailing the structure of commodity symbols expected.

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% (the 'short' parameter is documented), establishing a baseline score. However, the description adds no value beyond the schema regarding what 'short format' entails (which fields are omitted or included), nor does it provide guidance on when to use short=true versus the default long format.

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

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

The description uses a specific verb ('Get') with clear resource ('quotes for commodities') and scope ('up-to-the-minute', 'real-time'). It distinguishes from siblings like listCommodities (which lists available instruments) by emphasizing price data retrieval, and differentiates from getForexQuotes/getCryptoQuotes via explicit commodity examples (oil, gold, agricultural products).

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 ('Track the latest prices') but provides no explicit guidance on prerequisites (e.g., whether to call listCommodities first to get valid symbols), no 'when-not-to-use' exclusions, and does not reference sibling tools as alternatives. The agent must infer applicability from the commodity examples provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes what data is returned (compensation, demographics), but fails to disclose operational traits like read-only status, rate limits, pagination behavior, or error responses for invalid symbols.

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

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

The description is two sentences with minimal redundancy. The first sentence establishes the action and API source; the second enumerates returned fields. It efficiently conveys the scope without excessive verbosity, though 'essential data' is slightly filler-ish.

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 2-parameter schema and lack of output schema, the description appropriately enumerates the returned fields (name, title, compensation, demographics). However, it omits the return structure (array vs object) and does not address error cases or data completeness limitations.

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

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

The input schema has 100% description coverage ('Stock symbol', 'Filter for active executives'). The description does not add semantic detail beyond the schema, such as expected symbol format or what constitutes an 'active' executive, warranting the baseline score for high-coverage schemas.

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 'Retrieve[s] detailed information on company executives' and specifies the data returned (name, title, compensation, demographics). It implicitly distinguishes from sibling `getExecutiveCompensation` by emphasizing demographic details (gender, year of birth), though it could explicitly differentiate between these overlapping tools.

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

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

The description provides no guidance on when to use this tool versus alternatives like `getExecutiveCompensation` or `getCompanyProfile`. It does not mention prerequisites (beyond the required symbol parameter in schema) or when-not-to-use conditions.

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

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

With no annotations provided, the description carries the full burden. It discloses the data source (FMP Company Notes API) and enumerates return fields (CIK, symbol, note title, exchange), which helps predict output structure. However, it omits safety properties (idempotency, rate limits), error behaviors, or whether this retrieves real-time vs. historical data.

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

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

The description consists of exactly two efficient sentences. The first establishes the action and API source; the second lists specific return fields. There is no redundant information or marketing fluff, making it appropriately front-loaded 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 the low complexity (single required string parameter, no nested objects), the description adequately compensates for the missing output schema by listing the four key data fields returned (CIK, symbol, title, exchange). It doesn't cover pagination, error cases, or data freshness, but this is acceptable for a simple lookup 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?

The input schema has 100% description coverage with the 'symbol' parameter documented as 'Stock symbol'. The description adds no additional semantic context about the parameter (e.g., expected format, whether it accepts tickers or CUSIPs). With high schema coverage, this meets the baseline expectation.

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

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

The description clearly states the tool retrieves 'detailed information about company-issued notes' using the FMP API, with specific verb (Retrieve) and resource (company-issued notes). While the resource type distinguishes it from sibling company data tools (getCompanyProfile, getCompanyExecutives), it doesn't explicitly differentiate from other securities/debt tools in the sibling 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 like getCompanyProfile or getCompanySECProfile. It doesn't mention prerequisites (e.g., needing a valid stock symbol) or when not to use it. Users must infer applicability from the resource name alone.

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

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

With no annotations provided, the description carries the full burden. It partially compensates by listing example return fields (market capitalization, stock price, industry), giving the agent a sense of what data to expect since no output schema exists. However, it lacks details on rate limits, caching behavior, or whether data is real-time versus delayed.

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

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

The description is two sentences with the primary purpose front-loaded. It efficiently identifies the API source (FMP) and example data points. Minor deduction for the vague phrase 'and much more,' which doesn't earn 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?

Given the tool's simplicity (single parameter) and lack of output schema, the description adequately hints at return content by listing specific financial fields. However, given the crowded sibling space with multiple profile-related tools (getCompanyProfileByCIK, getCompanySECProfile, getCompanyProfilesBulk), the failure to clarify distinctions leaves the description functionally incomplete for tool selection.

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

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

The input schema has 100% description coverage ('Stock symbol' for the symbol parameter), establishing a baseline of 3. The description mentions 'specific stock symbol' but does not add semantic details beyond the schema (e.g., expected format like 'AAPL' vs 'Apple Inc', or case sensitivity).

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 'Access[es] detailed company profile data' and specifies it works 'for a specific stock symbol,' distinguishing it from bulk operations like getCompanyProfilesBulk. However, it does not explicitly differentiate from symbol-adjacent siblings like getCompanyProfileByCIK (CIK lookup) or getCompanySECProfile (SEC-specific data).

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 getCompanyProfileByCIK (when you have a CIK instead of symbol), getCompanyProfilesBulk (for multiple symbols), or getCompanySECProfile (for SEC-specific data). There are no stated prerequisites or exclusions.

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

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

No annotations provided, so description carries full burden. It lists example return fields (stock price, market cap, industry) which helps compensate for missing output schema. However, lacks operational details: error behavior for invalid CIKs, data freshness, or rate limits.

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

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

Two sentences with some redundancy ('This API allows users...' restates the first sentence). The phrase 'with the FMP Company Profile by CIK API' is tautological. The field enumeration ('and much more') is vague but acceptable.

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 single-parameter lookup tool with no output schema, the description adequately lists representative return fields. However, given zero annotations and no output schema, it should specify error handling (e.g., 'returns empty object if CIK not found') to be complete.

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

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

Schema has 100% coverage with 'CIK number' description. The description adds context that CIK is a 'unique' identifier and expands the acronym, but doesn't specify format requirements (numeric string, leading zeros, length) that would help prevent errors.

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?

States specific action (Retrieve) and resource (company profile data) with clear identifier (CIK). Mentions 'unique CIK identifier' implying exact lookup. However, fails to explicitly differentiate from sibling tool 'getCompanyProfile' (presumably by ticker symbol), leaving ambiguity about which identifier to use when.

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?

Incorrectly uses 'search for companies' when this is an exact lookup by unique ID, potentially confusing it with sibling 'searchCompaniesByCIK'. No explicit when-to-use guidance versus 'getCompanyProfile' or guidance on CIK format (e.g., leading zeros).

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