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 discloses that the tool combines data but does not mention read-only nature, permissions, rate limits, response format, or any side effects. This is a significant gap for a tool with no structured metadata.

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

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

The description is two sentences, front-loaded with the primary action, and contains no unnecessary words. Every phrase contributes meaning, making it highly efficient.

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

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

With only 2 parameters and no output schema, the description should clarify what the 'comprehensive market analysis' includes (e.g., return structure, fields). It mentions 'probabilities' and 'trading activity' but lacks specifics on response format or error conditions, leaving an agent under-informed about expected results.

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

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

Schema description coverage is 100%, with both 'slug' and 'include_trades' already documented. The description adds no extra parameter semantics beyond what the schema provides, so it meets the baseline without enhancing understanding.

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

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

The description clearly states the tool's function: 'Get comprehensive market analysis' and specifies components like 'probabilities, trading activity, and AI-friendly insights.' It distinguishes itself from sibling tools by explicitly noting it 'Combines market data with recent trades,' which separates it from individual market data or trade history 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 implies usage for when both market data and recent trades are needed, but it doesn't explicitly state when to choose this over alternatives like dome_market_price or dome_trade_history. There are no direct comparisons or exclusions, so guidance is only implicit.

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 only mentions it uses the FMP Custom DCF Advanced API and fine-tunes assumptions; it does not disclose output format, whether it returns a valuation estimate, any rate limits, or side effects. The description lacks substantive 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 concise at two sentences and front-loads the core action. The second sentence is somewhat generic and could be replaced with more specific information, but it is not overly verbose.

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

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

Despite having a nested input object with many optional parameters and no output schema, the description is minimal. It does not explain the expected return value, the required 'symbol' field, or provide enough context for an agent to know how to construct a valid request. The complexity is high, but description offers little support.

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

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

Schema description coverage is 0% in the tool description; the description does not mention any parameter names or meanings, just 'detailed inputs'. Even the input schema's descriptions are terse (e.g., 'Beta'), and the description fails to add any semantic context or clarify which parameters 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 runs a tailored Discounted Cash Flow analysis, using a specific verb and resource. It distinguishes itself as 'custom' from standard DCF tools, but does not explicitly differentiate from the sibling tool calculateCustomLeveredDCF.

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

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

The description implies usage when a user needs fine-tuned, personalized valuation assumptions ('tailored', 'fine-tune assumptions'), but it provides no explicit when-to-use or alternative guidance. It does not mention scenarios where standard or levered DCF might be more appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only describes the purpose and capability. It does not mention output format, data source, side effects, rate limits, or whether the operation is read-only. This is a significant gap for a calculation tool.

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 relatively concise at two sentences, but it includes vague marketing phrases like 'more personalized and precise valuation' that add little value. It is not as tight as it could be, but it does front-load the core action.

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?

This tool involves a nested object with 19 parameters and has no output schema or annotations. The description provides almost no operational context, such as what data is needed, what the result looks like, or how it differs from simpler DCF tools, making it inadequate for effective use.

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

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

Schema description coverage is 0%, meaning the schema's field descriptions are just labels like 'Beta' and 'Tax rate' without additional meaning. The description fails to compensate by explaining any of the input parameters or the nested 'input' object structure, leaving the agent without semantic understanding of the required data.

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 'Run' and the resource 'DCF analysis' using the FMP Custom DCF Advanced API, indicating a tailored analysis. However, it does not explicitly differentiate from similar sibling tools like calculateCustomDCF or getLeveredDCFValuation, so it lacks strong sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as calculateCustomDCF or standard DCF endpoints. It does not state scenarios, exclusions, or prerequisites, leaving the agent without decision criteria for tool 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does state that the tool fetches and returns activity data, which implies a read operation, and mentions the types of activities included. However, it does not disclose return structure, pagination behavior, ordering, or any access 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 two sentences with no filler. It front-loads the action and resource, then adds return-value context. Every sentence earns its place and the length is appropriate.

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, no annotations, and no output schema, the description covers the core purpose and filter options, and notes the return content. However, it omits practical details like default limits, ordering, and result shape, which the agent would need to fully handle the response.

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%, so the baseline is 3. The description references the optional filter dimensions (market, condition, time range) but does not add syntax, parameter-specific details, or examples 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?

The description clearly states a specific action ('Fetches activity data') with a specific resource ('for a specific user') and distinguishes the tool by naming the returned event types (MERGES, SPLITS, REDEEMS). This is enough to differentiate from siblings like dome_trade_history or dome_wallet.

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 when to use the tool: when you need a user's activity with optional filtering by market, condition, and time range. However, it does not provide explicit exclusions or mention alternative tools when a different kind of data is needed.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that without a time range only the most recent price is returned, timestamps are in Unix milliseconds, and currency format requirements (lowercase alphanumeric). These are beyond schema info and help the agent avoid common mistakes. However, it does not mention pagination behavior or return value shape, leaving some gaps.

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

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

The description is five sentences, front-loaded with the purpose, and each sentence adds necessary context: scope, default behavior, units, and format. There is no fluff or repetition, and it is appropriately sized for the tool's 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?

The description covers core behavior but lacks details about the return format (e.g., fields or structure) since there is no output schema. It also does not mention pagination usage in the description itself, although the schema describes pagination_key. For a 5-parameter tool with no output schema, more context about what 'price data' looks like 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?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it reiterates currency format and timestamp units already present in the schema. It does not provide extra semantic context for parameters like pagination_key or explain how limit interacts with time ranges beyond what schema says.

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 crypto price data from Binance for a specific currency pair over an optional time range. It distinguishes itself from siblings like dome_candlesticks and dome_market_price by explicitly focusing on historical price data with optional time filtering.

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?

Usage context is implied through phrases like 'historical crypto price data' and 'optional time range', but no explicit when-to-use vs alternatives are given. There is no mention of exclusions or named alternative tools, so the agent must infer usage from the purpose alone.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only indicates that data is fetched (a read operation) and mentions an interval, but omits details about return format, rate limits, error cases, or the fact that the referenced condition_id is not a parameter. This is insufficient for a tool with no annotation support.

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

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

The description is a single, concise sentence with no wasted words. However, the mention of condition_id, which is not in the schema, adds confusion and reduces clarity slightly, so it doesn't earn a perfect 5.

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

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

With no output schema and no annotations, the description should provide more context about return values, limitations, or the missing market identifier. It fails to explain how to identify the market, making the tool difficult to invoke correctly.

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

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

The input schema provides 100% coverage with descriptions for start_time, end_time, and interval, including range limits. The description adds no new parameter semantics; it only restates 'over a specified interval' which already appears in the schema. Baseline of 3 is appropriate.

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

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

The description states the tool fetches historical candlestick data, which is a specific action and resource. However, it references 'condition_id' as the market identifier, but this parameter is absent from the input schema, creating confusion about how to specify the market. It doesn't clearly differentiate from sibling price and market 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 is provided on when to use this tool versus alternatives like dome_market_price or dome_orderbook_history. The description only states its function, implying usage but offering no context, 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?

Since no annotations are provided, the description carries the full burden of disclosure. It explains key behavioral aspects: optional time range, default to latest price when no range is given, Unix millisecond timestamps, and slash-separated currency format. This goes beyond the raw schema and gives users essential operational context.

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

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

The description is four compact sentences, front-loaded with the primary action ('Fetches historical crypto price data'). Every sentence provides useful information, with no redundancy or filler.

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

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

Given the tool has 5 parameters, no output schema, and no annotations, the description covers the main usage patterns: fetching historical ranges, getting the latest price, timestamp units, and currency format. It does not describe the return structure or pagination behavior, but the schema already explains pagination_key and limit, and the absence of an output schema may make this acceptable.

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%, so the schema already documents all five parameters. The description reinforces the currency format and timestamp units, but these details are also present in the parameter descriptions. It adds some value by explaining the interplay between time range parameters and the limit default, but does not significantly expand on 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 historical crypto price data from Chainlink, specifying a distinct resource (Chainlink prices) and behavior (historical data with optional time range). This distinguishes it from sibling tools like dome_binance_prices or dome_market_price.

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

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

The description provides clear context on when to use the tool: for historical crypto prices from Chainlink, with optional time ranges, and notes the behavior when no time range is given (returns most recent price). It does not explicitly mention alternatives or exclusions, but the Chainlink source makes its purpose distinct.

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 a read operation via 'fetches' and mentions historical lookup capability, but doesn't describe the response format, error conditions, or that token_id appears to be required. The added behavioral context is minimal beyond 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?

The description is two short, front-loaded sentences with no redundant information. It efficiently communicates the primary purpose and the historical lookup option.

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 read tool with one optional parameter, the description is mostly adequate. Gaps include no mention of response structure (given no output schema) and no context on how token_id relates to other market tools like dome_markets, which could be important for an agent.

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

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

The schema fully documents at_time with type and meaning, and the description introduces token_id as an identifier not present in the schema, which is critical for invoking the tool. However, the description does not elaborate on token_id's format or type, so some ambiguity remains.

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 current market price for a market by token_id, with a specific verb and resource. However, it does not distinguish this tool from the similarly named sibling dome_market_price_get, so it lacks sibling differentiation.

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

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

The description implies usage for current or historical price lookups, but provides no guidance on when to choose this tool over dome_market_price_get or dome_markets, and offers no exclusions or alternative references.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return of both yes/no sides and historical lookup via at_time, but the text references a 'market_ticker' parameter that is absent from the input schema. This misleading reference undermines transparency about the actual required inputs.

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, consisting of two sentences that are front-loaded with the core purpose. Every sentence contributes value, avoiding 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?

With no output schema and no annotations, the description must fully contextualize the tool. It fails to explain how the market is specified given the missing market_ticker parameter, does not clarify the meaning of 'dome' or Kalshi-specific terms, and leaves the near-identical sibling dome_market_price indistinguishable. This under-specification hinders effective use.

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

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

The input schema has 100% description coverage for the only parameter (at_time), so the baseline is 3. The description only restates the historical lookup behavior without adding new meaning, and its mention of a non-existent market_ticker parameter introduces confusion rather than clarity.

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

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

The description clearly states the tool's function: fetching current market prices for a Kalshi market and returning both yes/no sides. However, it does not differentiate from the sibling tool dome_market_price, so it misses the opportunity to distinguish itself.

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 current or historical price lookups but provides no explicit guidance on when to choose this tool over dome_market_price or other price-fetching siblings. There are no exclusions or alternative references, leaving the usage context partially inferred.

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?

There are no annotations, so the description must disclose behavioral traits. It only states 'Find markets' without explaining query behavior, pagination, result format, or any side effects. The agent cannot infer whether this is a safe read-only operation or what the response will look like.

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 one short sentence and completely free of fluff. It is front-loaded with the primary purpose and can be read in under two seconds. 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?

With 11 parameters, no annotations, and no output schema, this description is insufficient. It does not explain return values, default behavior, or context for using the numerous filters. A tool this complex requires more context to be safely invoked.

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 covers all parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond saying 'various filters', which is already evident from the schema. It repeats the idea of filters but does not elaborate on parameter syntax or relationships.

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

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

The description clearly states the tool's action ('Find markets on Polymarket') and the resource ('markets'), with a specific scope ('using various filters including the ability to search'). It is a specific verb+resource statement, but it does not differentiate from siblings like dome_markets_get or search_markets.

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 search_markets or dome_markets_get. It does not mention any exclusions or prerequisites, so the agent is left without context for choosing among sibling 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 of behavioral disclosure. It simply states the action and filter options without mentioning default behavior, pagination details, return format, or any side effects. This is a significant gap for a tool with no structured safety metadata.

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

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

The description is a single concise sentence that is front-loaded with the main purpose. It is not verbose, but it omits some useful context that could make it more informative, so it is slightly above 'minimum viable' but not exceptional.

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 7 parameters and no output schema, the description is insufficient. It does not explain what the response looks like, how pagination works (even though limit/offset are in the schema), or whether there are any restrictions on filter combinations. This makes it incomplete for an AI to fully understand the tool's capabilities and invocation 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?

The input schema already describes all 7 parameters with 100% coverage, so the description adds little beyond naming a few filter types (ticker, event, status, volume). It does not provide additional meaning or format details beyond what the schema already contains, matching 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 action ('Find') and the resource ('markets on Kalshi'), and lists several filter types, making the tool's purpose understandable. It does not explicitly differentiate from similar sibling tools like dome_markets or search_markets, but the mention of Kalshi and specific filters provides reasonable 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?

The description implies the tool is for finding markets via filters, but it gives no explicit guidance on when to use this vs. alternative tools. There is no mention of alternatives, exclusions, or prerequisites, so the usage context is only implicit from the verb 'Find'.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful details beyond the schema: return contents (bids, asks, market metadata), timestamp units, data history start date, and the fact that limit/pagination_key are ignored when fetching the latest snapshot. It does not cover all possible behavioral aspects (e.g., ordering, pagination mechanics), but the provided details are substantive.

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 concise and front-loaded with the main purpose, then provides sequential conditional details (latest vs. historical, timestamp units, data availability, ignored params). Every sentence contributes necessary information with no fluff.

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

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

Given the absence of an output schema, the description adequately summarizes return content (bids, asks, metadata) and covers key edge cases like the latest snapshot and data history start. It could be more explicit about ordering and response structure, but it is reasonably complete for a data-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?

Schema description coverage is 100%, so the baseline is 3. The description adds some value by clarifying the latest-snapshot edge case and ignored parameters, but this information is already present in the schema descriptions. It does not meaningfully enrich parameter understanding 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 clearly states the tool fetches historical orderbook snapshots for a specific token ID over a time range, with a clear verb and resource. However, it does not distinguish itself from the nearly identical sibling dome_orderbook_history_get, so it falls short of 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 clear context on when to use the tool (historical snapshots with start/end times, or latest snapshot if these are omitted) but does not explicitly mention alternatives or say when NOT to use it versus sibling tools like dome_market_price or dome_orderbook_history_get.

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

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

With no annotations, the description carries the full burden. It discloses several behavioral traits: returns snapshots with yes/no bids/asks in cents and dollars, timestamps in milliseconds, data availability starting October 29, 2025, and limit being ignored when fetching latest. This is thorough for a read-only fetch, though it does not discuss error handling or pagination.

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 with front-loaded purpose, followed by boundary conditions, return content, units, and a note about limit. Each sentence earns its place with no redundancy or fluff.

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

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

Despite lacking an output schema, the description adequately explains the return contents (yes/no bids/asks, price units) and adds key context about time range handling, timestamps, and data history. It could mention ordering or pagination behavior, but overall it is sufficiently complete for invoking this tool correctly.

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

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

The input schema already covers 100% of parameters with clear descriptions, including the optionality of start_time/end_time and the limit behavior. The description adds minor context (millisecond timestamps, data start date) but mostly reiterates schema content. Thus, 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 fetches historical orderbook snapshots for a specific Kalshi market (ticker) over a time range, with a fallback to the latest snapshot. This specific verb+resource+scope accurately distinguishes it from sibling tools like dome_orderbook_history and dome_market_price.

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

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

The description provides clear context: it is used for historical orderbook data for a specific ticker, and if no time range is provided it returns the latest snapshot. It also notes that limit is ignored in the latest-snapshot case. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of full guidance.

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

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

The description discloses a meaningful behavioral trait: it only returns positions with balance >= 10,000 shares (0.01 normalized), which helps set expectations. However, with no annotations, it does not state whether the tool is read-only, how pagination works, or how the wallet address is determined, leaving gaps in 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 a single sentence that is front-loaded with the core action and includes only essential details. No wasted words, making it highly concise and well-structured.

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

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

With no annotations or output schema, the description carries the full burden, but it fails to address the absent wallet address parameter and does not explain pagination behavior or return format. The context is incomplete for an agent to confidently invoke the 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?

Both parameters (limit and pagination_key) have descriptive schema text, so baseline is 3. The description adds no extra meaning beyond the schema and fails to clarify the missing wallet address parameter, which could confuse parameter mapping.

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 Polymarket positions for a proxy wallet address, with a specific verb and resource. However, it does not distinguish from sibling tools like dome_wallet or getPositionsSummary, and the reference to 'proxy wallet address' is ambiguous since no such parameter exists in 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or recommend other tools for related use cases, leaving the agent without decision support.

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 adds useful scope context (cross-platform matching) and implies a read-only lookup, but it fails to disclose return format, empty-result behavior, rate limits, auth needs, or why 'sport' appears in the description but not in the input 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 is a single front-loaded sentence that wastes few words and leads with the action verb. It loses a point because the 'by sport and date' clause is misleading given the schema, which slightly undermines the efficiency of the wording.

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

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

The tool is simple (one parameter, no output schema), so the bar is lower, but the description still leaves key gaps: it never explains what 'equivalent markets' means in terms of returned data, what happens when no matches exist for the date, or how the 'sport' mention relates to the single date input. These unresolved issues make the description incomplete for confident invocation.

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

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

The schema covers the date parameter at 100%, giving a baseline of 3, but the description actively detracts by introducing 'sport' as a filter dimension that does not exist in the parameters. An agent may search for a sport parameter, not find one, and be confused about how to satisfy the stated 'by sport' scope.

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 ('Find') plus a clearly defined resource ('equivalent markets across different prediction market platforms' for sports events), which conveys the core purpose and distinguishes it from sibling tools like dome_markets or dome_sports via the cross-platform equivalence angle. However, it claims filtering 'by sport and date' while the schema only accepts a date parameter, creating ambiguity about whether sport is actually a valid filter.

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 dome_sports, dome_markets, or search_markets. There are no stated exclusions, prerequisites, or conditions that would help an agent choose this tool over its siblings.

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

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

No annotations are provided, so the description carries the full burden. 'Find' implies a read-only lookup, but the description does not disclose response format, pagination, rate limits, or authentication needs. It adds no behavioral context beyond the inherent meaning 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 states the tool's purpose, inputs, and scope. Every word contributes value, and there is no filler or redundancy.

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

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

For a tool with no output schema, the description only says 'equivalent markets' without specifying what the response contains or how results are structured. Inputs are fully covered by the schema, so this is adequate but incomplete for a caller expecting clear return-value semantics.

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 each parameter already described, so the baseline is 3. The description's mention of 'Polymarket market slug or Kalshi event ticker' merely restates the schema without adding value formats, examples, or usage nuances.

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 ('Find'), names the resource ('equivalent markets across different prediction market platforms'), specifies the scope ('for sports events'), and identifies the required inputs ('Polymarket market slug or Kalshi event ticker'). This clearly distinguishes it from sibling tools like dome_markets or dome_sport_by_date.

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 gives clear usage context: use when you have a Polymarket slug or Kalshi ticker and need equivalent markets on other platforms. It does not explicitly name alternatives or exclusions, but the 'sports events' qualifier and specific input types make the intended scenario clear.

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

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

With no annotations, the description carries the burden of disclosing behavior. It discloses return types (executed trades, pricing, volume, taker side) and timestamp units (seconds), which is helpful. However, it omits details about pagination behavior, rate limits, or any side effects, leaving some gaps.

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

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

The description is three concise sentences, front-loaded with the main purpose, and every sentence adds useful information without redundancy. It is well-structured and easy to parse.

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

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

The description covers the core purpose and return information, but it lacks important contextual details such as pagination behavior (how limit/offset work together), the default limit, and how this tool differs from its '_get' sibling. Given the simplicity of the tool, more guidance 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that start_time and end_time are in seconds, which is not explicitly stated in the schema. It also groups ticker and time range as filters, enhancing understanding of their purpose.

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

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

The description clearly states the tool fetches historical trade data for Kalshi markets, specifying the resource and action. However, it does not differentiate from the sibling tool 'dome_trade_history_get', which likely serves a similar purpose, so it misses the opportunity to distinguish between them.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions optional filtering but does not explain when this tool is preferred over other related tools like dome_trade_history_get or dome_orderbook_history.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states that it fetches data; it does not mention ordering, pagination behavior, response format, rate limits, or any other behavioral traits. For a read operation, this is a minimal but not entirely absent disclosure, yet it lacks context that would help an agent anticipate results.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key capabilities. Every word earns its place, and there is no redundant information. It is appropriately sized for the tool's 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 tool has 8 optional parameters and no output schema, the description is adequate but thin. It does not explain the return structure, defaults, or how filters interact. However, the schema covers parameter details, and the tool is a straightforward fetch, so the description is not severely incomplete. It is missing some context but is not misleading.

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 already provides descriptions for all 8 parameters, with 100% coverage. The description only lists the filter categories (market, condition, token, time, user) without adding new meaning. This meets the baseline but does not exceed it, as no extra context about parameter combinations or formats is given.

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 trade data, a specific action, and lists the main filter dimensions (market, condition, token, time range, user wallet). It is clear and uses a specific verb+resource. However, it does not explicitly differentiate itself from the closely named sibling dome_trade_history, so it loses a 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 is provided on when to use this tool versus alternatives like dome_trade_history or dome_orderbook_history_get. There is no mention of preferred scenarios, exclusions, or prerequisites. The optional filtering implies a search use case, but that is not explicit enough to guide selection among siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses the input modes, return values, and optional metrics. However, it does not mention error behavior for providing both or neither address, nor any performance implications beyond what the schema already notes. The transparency is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with the action, and every sentence contributes meaningful information. There is no redundancy or fluff.

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

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

Despite no output schema and no annotations, the description covers the core functionality, input modes, and return values. It does not elaborate on all parameters (e.g., start_time, end_time) but the schema fully documents those. Overall, it is complete enough for a straightforward wallet 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some value by explaining the outputs (EOA, proxy, wallet type, metrics) but largely paraphrases the schema's own parameter descriptions. It does not significantly enhance understanding beyond the schema.

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

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

The description uses a specific verb and resource ('Fetches wallet information') and clearly identifies the two input modes (EOA or proxy) and the output contents. It is clear and unambiguous, but it does not explicitly differentiate from sibling tools like dome_wallet_profitandloss, so it falls short of 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 clearly implies when to use this tool: when you have an EOA or proxy wallet address and need associated wallet details or optional trading metrics. It provides context (either/or input, optional metrics) but does not explicitly state when not to use it or name alternatives, so it gets a 4.

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

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

With no annotations, the description carries the burden of disclosure. It clearly explains that gains are only realized from confirmed sells or redeems, and not until a finished market is redeemed. This is significant behavioral context beyond what a typical PnL tool would state, though it omits response format details.

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

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

The description is concise, with two sentences that front-load the core functionality and then provide a clarifying note. Every sentence adds value, with no redundant 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?

The description explains the core concept well, but the absence of an output schema and the mismatch between mentioning a 'specific wallet address' and the schema lacking such a parameter create gaps. The simple parameter set is fully covered, but the tool's context is incomplete without knowing how the wallet is identified or what the response looks like.

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

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

The schema description coverage is 100%, with each parameter having a description. The description mentions 'time range and granularity' which aligns with start_time, end_time, and granularity, but does not add further semantic detail beyond the schema. The baseline of 3 is appropriate.

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

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

The description clearly states the tool fetches realized PnL for a wallet with a specific verb and resource. It distinguishes itself from Polymarket's dashboard by noting the difference between realized and unrealized PnL. However, the schema does not include a wallet address parameter, creating ambiguity about how the wallet 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 provides context on when to use this tool by explaining it tracks realized gains only, unlike the dashboard's unrealized PnL. This implies the tool is appropriate when realized PnL is needed. It does not explicitly mention alternatives or exclusions, but the note serves as useful guidance.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the type of information provided ('detailed information on how mergers... impact ownership') but does not disclose output format, pagination behavior, rate limits, authentication needs, or any safety constraints. The read-only nature is implied by 'Track' but 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 description is concise at two sentences, with the core functionality front-loaded in the first sentence. The second sentence adds useful contextual detail about mergers/takeovers, though it contains slight redundancy ('This API provides detailed information'). Overall, it is efficient 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's simplicity (2 parameters, no output schema), the description gives a reasonable overview but lacks explicit details about return values or data structure. It is adequate for understanding the general purpose but incomplete for an agent to fully anticipate the tool's behavior without additional context.

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 provides 100% coverage with descriptions for both 'symbol' and 'limit', so the baseline is 3. The description adds no parameter-specific semantics beyond what the schema already contains, but it does not contradict or omit anything either.

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 a specific action ('Track changes in stock ownership during acquisitions') and the resource ('stock ownership structure'). It distinguishes itself from sibling tools like getLatestMergersAcquisitions by focusing on ownership impact rather than just listing transactions, though it doesn't explicitly call out that 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?

There is no guidance on when to use this tool versus alternatives. The description only explains what the tool does, not in which scenarios it should be chosen over other merger/acquisition or ownership-related tools, nor any prerequisites or contextual 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It claims 'real-time market activity' and 'allows users to filter', but the input schema is empty, making the filtering claim misleading. It does not disclose limitations, pagination, or what 'actively trading' precisely means, leaving the agent with incomplete behavioral expectations.

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 but contains redundancy, repeating 'actively trading' in both sentences. The second sentence adds little new information and introduces an inaccurate 'filter' claim. It is not excessively wordy but could be tighter and more accurate.

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 list tool with no parameters and no output schema, the description gives a general sense that the return is a list of actively trading securities, but it does not specify the response structure, fields, pagination, or what counts as 'actively trading'. It is minimally viable but leaves meaningful gaps.

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

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

The tool has zero parameters and the input schema is empty with 100% coverage, meaning there is nothing to document beyond the baseline. The description's mention of filtering is unsupported by the schema but does not affect parameter semantics directly. The baseline of 4 is appropriate.

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

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

The description uses the specific verb 'List' and identifies the resource as 'actively trading companies and financial instruments', making the tool's primary purpose clear. It also references the FMP Actively Trading List API, which adds a source context. However, it does not explicitly distinguish this from similar list tools like getMostActiveStocks or getBiggestGainers, so it loses a 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or scenarios where another tool would be more appropriate. Given the many sibling tools for market activity, this lack of usage direction is a significant gap.

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 burden. It identifies the data source (FMP ADX API) and the use of historical price data, which is useful. However, it does not disclose output format, limitations, or error conditions, though the read-only nature of a calculation is fairly clear.

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

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

The description is two concise sentences with no fluff. The first sentence states the core action and resource; the second adds context about the tool's purpose 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?

For a simple indicator tool with no output schema and no annotations, the description gives enough context for selection—it names the indicator, its purpose, and data source. Invocation details are fully covered by the schema. A mention of the return structure would be nice, but the description is adequate for the tool's simplicity.

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

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

The input schema has 100% coverage with descriptions for all parameters. The description adds no extra meaning to the parameters beyond what the schema already provides, such as periodLength being 'for the indicator'—so the baseline score applies.

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 action ('Calculate ADX') and the resource ('a stock'), and explains what ADX measures (trend strength and direction). It is specific to this tool, but it does not explicitly differentiate from sibling indicator tools 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 a use case (analyzing trend strength and direction) but does not explicitly state when to choose this tool over alternatives such as getRSI or getEMA. There is no mention of exclusions or preferred scenarios beyond the general purpose.

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

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

With no annotations, the description carries the full burden. It discloses that quotes are real-time and include bid/ask and volume, but lacks details on return format, potential delays, or limitations. It is not misleading but could be richer.

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

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

The description is two sentences, front-loaded with the main purpose, and each sentence adds value. No fluff or redundant 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 single-parameter tool with no output schema, the description adequately covers what the tool does and what data it returns. It could mention more about the quote format, but the complexity is low and the description is sufficient.

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

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

The schema already documents the single parameter 'symbol' with a simple description. The tool description adds that the tool is for stocks, but does not provide additional detail beyond the schema. With 100% schema coverage, 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 accesses real-time aftermarket quotes for stocks, specifying key data points like bid/ask prices and volume. It distinguishes from siblings such as getAftermarketTrade (trades vs quotes) and getQuote (regular market quotes).

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

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

The description clearly implies use outside regular trading hours, which provides context for when to use this tool. However, it does not explicitly mention alternatives or exclusion criteria, though the 'outside of regular trading hours' phrasing gives clear context.

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

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

With no annotations provided, the description must disclose behavioral traits fully. It mentions 'real-time' and a few data fields but does not clarify return format (single trade vs list), ordering, time boundaries, or rate limits. This is only slightly more informative than the tool 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, front-loaded with the main purpose and followed by specific examples of returned data. Every word contributes; no redundancy or fluff.

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

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

The tool has minimal complexity (one parameter, no output schema). The description covers the core purpose and data elements but omits details about the response structure and any limitations, which would be helpful given the absence of an output 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?

Schema description coverage is 100% for the single 'symbol' parameter, which is documented as 'Stock symbol'. The description adds no extra detail about symbol format or usage, so the baseline of 3 applies.

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 real-time aftermarket trading activity and lists specific data points (prices, sizes, timestamps). It distinguishes itself from sibling tools like getAftermarketQuote by focusing on trades rather than quotes, and the singular 'Trade' in the name implies a per-symbol service.

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 getAftermarketQuote or getBatchAftermarketTrade. It implies usage for aftermarket trades but does not state exclusions, prerequisites, or selection criteria, leaving the agent without decision context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only operation via 'View' and 'Check', but does not describe the return format (e.g., list, map), timezone handling, or any limitations such as data freshness or coverage. This is adequate but leaves significant gaps.

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

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

The description is extremely concise, consisting of two short sentences that immediately communicate the tool's purpose. There is no wasted information, and it is front-loaded with the key action ('View the market hours for all exchanges').

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 parameters, no output schema), the description is minimally sufficient. However, it could provide more context about what 'market hours' includes (e.g., regular vs extended hours) and the expected output structure. The existence of a similar sibling (getExchangeMarketHours) suggests this tool's unique value should be more explicit, but the description does not clarify the 'all' versus 'single' distinction beyond the name.

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

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

The tool has zero parameters and an empty input schema, so the baseline is 4. The description correctly avoids adding parameter details, as there are none to explain. The schema coverage is 100% (vacuously), and no parameter semantics are needed.

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

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

The description clearly states the tool's function: 'View the market hours for all exchanges' and 'Check when different markets are active.' It uses a specific verb and resource, and the name reinforces the 'all' scope. However, it does not explicitly distinguish itself from the sibling tool 'getExchangeMarketHours', which may target a single exchange.

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

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

The description implies usage when one needs market hours across all exchanges ('Check when different markets are active'), but it provides no explicit guidance on when to use this versus alternatives like getExchangeMarketHours or getHolidaysByExchange. There are no exclusions or alternative suggestions.

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

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

With no annotations, the description carries the full burden. It discloses that quotes are 'real-time' and that the call aggregates multiple indexes, which are useful behavioral traits. However, it does not mention default parameter behavior, rate limits, return structure, or any caveats, leaving notable gaps in 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 exactly two sentences, front-loaded with the main purpose, and contains no redundant or filler content. Every phrase contributes to explaining what the tool does.

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 nature (one optional parameter, no output schema), the description adequately conveys the core functionality and use case. It does not elaborate on parameter effects, but for a batch quote tool this is a minor gap. The sibling list provides additional context for comparison.

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

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

Schema coverage is 100% with a clear description for the 'short' parameter (default false). The tool description does not mention the parameter at all, adding no extra meaning beyond the schema. Baseline 3 is appropriate since schema fully documents the parameter.

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

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

The description clearly states the tool provides real-time quotes for stock indexes, with a scope of multiple indexes in a single request. It distinguishes from single-index tools by emphasizing 'wide range' and 'multiple indexes', but does not explicitly differentiate from sibling tools like getIndexQuotes.

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 tracking market performance across many indexes at once, but lacks explicit when-to-use guidance or comparisons with alternatives such as getIndexQuote or getIndexShortQuote. Context is present but no exclusions or specific scenarios 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, the description carries the full burden of behavioral disclosure. It mentions the data types returned but does not describe pagination behavior, authentication requirements, or any side effects. The agent is left without safety or operational context.

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

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

The description is two concise sentences with no redundant content. It is front-loaded with a clear action and resource, making it easy to parse quickly.

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 paginated list tool with well-described schema parameters, the description sufficiently conveys the result content. It lacks explicit mention of pagination usage, but the overall low complexity makes the description adequate.

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

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

The schema already provides clear descriptions for both page and limit parameters, achieving 100% coverage. The description does not add any parameter-specific information beyond what the schema states.

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 comprehensive industry classification data with specific fields like SIC codes and industry titles. However, it does not differentiate from sibling tools such as getIndustryClassificationList, which have similar names and purposes.

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

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

No guidance is provided on when to use this tool versus alternatives like searchIndustryClassification or getIndustryClassificationList. The description only explains what the tool does, not when it should be preferred.

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 does not explain pagination behavior, response format, or any rate limits/limitations, even though page and limit parameters exist in the schema. The description only lists return fields, which is purpose information rather than 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 long and immediately states the tool's core function. Every clause adds value, naming the data source, the returned fields, and the analytical use case without any 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?

For a simple bulk data retrieval tool with no output schema and no annotations, the description provides the essential purpose and core fields, but lacks guidance on pagination usage, output shape, or potential caveats. It is adequate but leaves the agent inferring how results are structured and how to page through large datasets.

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 provides 100% coverage for both parameters with descriptions for page and limit. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool accesses comprehensive shares float data for all available companies, which distinguishes it from the sibling getShareFloat tool. It names the specific resource and scope (all companies), and the term 'retrieve critical information' with field examples establishes a concrete purpose.

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 'for all available companies' and 'wide range of companies' clearly implies bulk usage, distinguishing it from a single-symbol tool like getShareFloat. However, it does not explicitly mention when not to use this tool or name an alternative for individual company lookups, stopping short of the highest rating.

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

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

No annotations are provided, so the description must carry the full burden. It indicates a read-only operation via 'Retrieve', but omits details about rate limits, authentication, pagination behavior, or response structure. Missing useful context like whether estimates are consensus or individual analyst 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 is two sentences, front-loaded with the core action ('Retrieve analyst financial estimates') and contains minimal fluff. The phrase 'to inform your investment decisions' is somewhat promotional but not harmful; overall it is concise and structured.

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

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

For a tool with no output schema, the description gives a reasonable overview of the returned content (revenue, EPS, key metrics) but does not explain the response structure, pagination behavior, or how page/limit affect results. It is adequate but leaves gaps in how to interpret the response.

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%, so the schema already documents all parameters (symbol, period, page, limit) once. The description adds no additional parameter semantics beyond mentioning revenue/EPS, which are data attributes, not parameter behavior. 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's purpose: 'Retrieve analyst financial estimates for stock symbols' with specific examples like revenue and EPS. This verb+resource combination distinguishes it from sibling tools like getPriceTargetConsensus or getRatingsSnapshot, which focus on different 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 a context ('to inform your investment decisions') but no explicit when-to-use or when-not-to-use guidance, nor alternatives. It does not help differentiate from the many sibling financial data retrieval tools, so usage is only implied.

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 states the tool returns a 'comprehensive list of countries' but does not mention the output format (e.g., country names, codes, objects), alphabetical ordering, or potential pagination. This is not misleading but adds minimal context beyond the tool 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?

The description is two sentences. The first sentence is direct and front-loaded with the core purpose. The second sentence adds context about filtering/analyzing stock symbols, but is somewhat generic and could be trimmed. Overall, it is concise and readable 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 tool's simplicity (no parameters, no output schema), the description covers the basic purpose. However, it lacks any detail about the return structure—whether the result is a list of strings, objects with country codes, or something else. Since the description must compensate for the missing output schema, this 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?

The tool has zero parameters, and the schema coverage is 100% (an empty properties object). According to the rubric, a baseline of 4 is appropriate for no-parameter tools. The description does not need to add parameter semantics since there are none.

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

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

The description clearly states the tool's function: 'Access a comprehensive list of countries where stock symbols are available.' This uses a specific verb ('Access') and resource ('list of countries'), and is distinct from sibling tools like getAvailableExchanges or getAvailableIndustries. The mention of filtering by country of origin or primary market further clarifies its domain.

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 use case: 'enables users to filter and analyze stock symbols based on the country of origin or the primary market.' However, it does not explicitly state when to use this tool versus alternatives like getAvailableExchanges or getAvailableSectors. No exclusions or alternative references are provided, so guidance is only implicit.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It describes the API's general capabilities rather than the tool's specific behavior, omitting return format, rate limits, or the fact that no parameters are accepted (though the schema shows 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?

The first sentence is direct and useful, but the second sentence adds vague marketing language ('comprehensive overview', 'further analysis') without actionable detail. It could be tightened to a single 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?

For a zero-parameter tool with no output schema, the description should clarify what the returned list contains (e.g., exchange codes, names, market identifiers). It only says 'complete list', leaving the response structure and any usage context ambiguous.

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

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

The tool has zero parameters, which typically yields a baseline score of 4. However, the description misleadingly states that users can 'filter data by specific exchanges', implying a parameter that the schema does not support. This reduces clarity.

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 a complete list of supported stock exchanges, which is a specific resource. However, it does not explicitly differentiate itself from sibling list tools like getAvailableCountries or getAvailableSectors, though the resource is distinct.

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 when-to-use or alternative guidance is provided. The phrase 'for further analysis' implies a use case, but it does not specify when to choose this over other exchange-related tools such as getAllExchangeMarketHours or searchExchangeVariants.

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 alone must disclose behavioral traits. It lacks any details about response format (e.g., array of strings), ordering, pagination, authentication requirements, or error handling. For a zero-parameter tool, this is a notable gap.

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 concise at two sentences, with the purpose front-loaded. The only redundancy is the phrase 'using the FMP Available Industries API,' which is somewhat repetitive given the tool name, but it does not significantly detract.

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, zero-parameter tool without an output schema, the description gives a basic understanding but omits return value details. Since there are no annotations or output schema, mentioning the expected response structure would have made it more 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 tool has no parameters, so the baseline score is 4. The description correctly adds no parameter-specific details since none exist. The schema's 100% coverage (vacuous) means no information is missing.

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

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

The description clearly states the tool's function: accessing a list of industries where stock symbols are available. It distinguishes itself from sibling tools like getAvailableSectors or getAvailableCountries by focusing specifically on industries. However, it could be more explicit about the output being a simple list of industry names.

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

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

The description provides context on when to use this tool, mentioning it helps filter and categorize companies by industry for focused research. It does not explicitly mention alternatives or exclusions (e.g., use getAvailableSectors for sectors), but the usage context is clear enough.

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 for behavioral disclosure. It states only the basic action ('Access a complete list') and the use case, without detailing response format, pagination, authentication requirements, or any potential limitations. The term 'complete list' is the sole extra behavioral claim, leaving significant ambiguity.

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

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

The description is two sentences, with the core function stated upfront and the second sentence adding relevant context about sector categorization and analysis. No unnecessary words or details.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is mostly adequate but does not specify the response structure (e.g., an array of sector names) or whether the list is paginated. It leaves some ambiguity about what the agent should expect from the call.

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

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

The tool has zero parameters, so the input schema is empty. The baseline score for 0 parameters is 4, and the description adds no parameter-specific details, which is acceptable because there are no parameters to explain.

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 a complete list of industry sectors via the FMP Available Sectors API and explains its purpose in categorizing/filtering companies. While it doesn't explicitly contrast with sibling tools like getAvailableIndustries, the resource and action are unambiguous.

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

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

The description provides context for when to use the tool (for sector-based categorization and filtering of companies), but it does not offer explicit guidance on when not to use it or mention specific alternative tools. This is enough to understand the intended use case but lacks exclusions.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It indicates the tool returns symbols and counts of accessible transcripts, which gives some idea of the output. However, it does not mention that it is a read-only operation, that no parameters are accepted, or any potential rate limits or data freshness aspects.

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 concise at two sentences, front-loaded with the main purpose, and every sentence contributes meaningful information. There is no redundant or vague wording.

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 no parameters and no output schema, the description is fairly complete. It states the tool accesses a list of symbols with transcripts and provides counts. It lacks details about the response format or any authentication requirements, but for a simple list tool, it covers the essentials.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information, which is acceptable since there are none. It implies a complete, unfiltered list, which is consistent with the empty input 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 provides a 'complete list of stock symbols with available earnings call transcripts' and mentions the specific FMP API. This gives a specific verb and resource. However, it does not explicitly differentiate from sibling tools like getEarningsTranscriptList, though the purpose is reasonably distinct.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description implies a purpose for 'detailed financial analysis' but does not state when to prefer this over similar transcript-related tools, nor does it mention any limitations 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 of behavioral disclosure. It only says 'get' data, implying a read-only operation, but does not explain output behavior, pagination, default record count, or any quirks. It does not contradict annotations (since there are none), but it provides minimal behavioral context.

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

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

The description is extremely concise, a single sentence with no filler or redundancy. It is front-loaded with the core action. However, it is so terse that it sacrifices clarity and completeness, which is a minor structural issue but still efficient.

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

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

Given the tool's simple schema (2 params) but the large set of sibling balance-sheet tools, the description lacks necessary context about the exact type of balance sheet data and when it should be used. Without annotations or an output schema, the description leaves the agent with insufficient information to fully understand the tool's role and output.

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

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

Schema description coverage is 100%, with both symbol and recent_n well-described in the input schema. The description adds no additional parameter semantics or context beyond the schema. Baseline 3 is appropriate because the schema handles parameter documentation, and the description contributes no extra 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 states a specific verb and resource ('Get company balance sheet data'), but it is vague and does not distinguish from numerous balance sheet siblings like getBalanceSheetStatement, getBalanceSheetStatementTTM, and getBalanceSheetStatementAsReported. It lacks specificity about the period, format, or scope of the data returned. Overall the core purpose is clear but under-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?

No guidance is provided about when to use this tool versus the many balance-sheet and financial-statement siblings. There is no mention of exclusions or alternatives, so an agent cannot determine if this is the right tool for a given request. It only describes what it does, not when to choose it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only provides a high-level purpose. It does not mention return format, data scope, pagination, rate limits, or any prerequisites, leaving significant behavioral aspects undisclosed.

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 reasonably concise, but the trailing clause 'enabling detailed analysis of how financial positions have changed over time' adds little value. Overall, it is compact 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?

The description omits essential context: how the bulk selection works, what 'growth data' includes, and the output structure. With no output schema and no clarification of the company selection mechanism, the description is incomplete for agent decision-making.

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

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

Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds no specific parameter guidance and introduces ambiguity by mentioning 'multiple companies' while the schema only includes year and period, without explaining how companies are specified.

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

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

The description clearly states the tool retrieves growth data across multiple companies' balance sheets, using a specific verb ('retrieve') and resource. It effectively distinguishes it from sibling tools like getBalanceSheetStatementGrowth (likely single company) and getBalanceSheetStatementsBulk (statements, not growth).

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 analyzing growth trends across multiple companies, but does not explicitly state when to use this tool versus alternatives. There are no exclusions or comparisons to other bulk/growth endpoints, leaving usage guidance implicit rather than explicit.

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 only says 'Access' which implies a read-only operation, but it does not disclose output format, pagination, rate limits, or any limitations. The mention of analyzing assets, liabilities, and equity gives some context but not enough 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 concise, with two sentences that front-load the core purpose. The first sentence identifies the tool's function and target audience, while the second adds useful use-case context. It is efficient, though the second sentence is somewhat generic and could be more specific.

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 three-parameter tool with no output schema, the description covers the basic function and analytical use case. However, given the many closely related sibling tools, the description is incomplete without explaining what differentiates this tool (e.g., standard vs. TTM, as-reported, or growth versions). It also doesn't clarify whether results are historical or point-in-time.

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 all three parameters (symbol, limit, period), so the baseline is 3. The description does not add any parameter-specific details beyond the schema, though it does mention analyzing balance sheet components, which indirectly relates to the symbol parameter. This does not elevate the 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 sheet statements for publicly traded companies and specifies the key financial components (assets, liabilities, shareholder equity). However, it does not distinguish this tool from closely related siblings like get_balance_sheet, getBalanceSheetStatementAsReported, or getBalanceSheetStatementTTM, so it lacks sibling differentiation.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or alternative tools, despite the presence of many similar balance sheet tools. The only implied usage is analyzing financial health, which is too vague to guide tool 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, the description carries the full burden of disclosing behavior, but it only mentions 'directly from official filings' without covering pagination, limits, period defaults, or response structure. It does not contradict any annotations, but the lack of additional behavioral context (e.g., whether it returns historical or just latest data) is a significant gap.

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 concise, with two sentences that front-load the primary action and resource. The first sentence is somewhat redundant with the tool name but adds 'as reported by the company.' The second sentence provides useful detail on data content. No superfluous information is included.

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

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

Given no output schema and only three simple parameters, the description adequately conveys the core purpose and data scope. However, given the high number of sibling balance sheet tools, it lacks sufficient context to disambiguate usage. It covers the essential 'what' but not the 'when' or 'why' nuances.

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%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, but it does mention the content type (assets, liabilities, equity) which indirectly relates to what the data represents. It neither enriches nor detracts from the schema's clarity.

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, with specific mention of assets, liabilities, and equity from official filings. It uses a specific verb ('access') and names the resource ('As Reported Balance Statements API'), distinguishing it from standard or growth balance sheet tools, though it could more explicitly contrast with 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?

The description provides no guidance on when to use this tool versus alternatives like getBalanceSheetStatement or getBalanceSheetStatementTTM. It implies the 'as reported' nature but does not state explicit use cases or exclusions, leaving the agent to infer context from the tool name and sibling list.

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

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

No annotations are provided, so the description carries full burden. It states a high-level purpose but doesn't disclose whether growth is shown as percentages or absolute changes, how periods are represented, or what the response structure looks like. This leaves key behavioral traits undocumented.

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 no fluff, front-loading the purpose and adding a meaningful second sentence about tracking assets/liabilities/equity. Slight redundancy with the tool name is acceptable; overall efficiently 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 absence of annotations and output schema, the description should provide more detail about return values or growth presentation. It doesn't explain what the API response contains, how growth is calculated, or handle edge cases. This leaves the agent under-equipped to interpret results.

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

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

Schema description coverage is 100%, so all three parameters (symbol, period, limit) are already documented. The description adds domain context (assets, liabilities, equity) but doesn't clarify parameter semantics beyond the schema, matching the baseline for 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?

Description uses a specific verb 'Analyze' and identifies the resource as 'growth of key balance sheet items' with explicit scope (assets, liabilities, equity). It clearly conveys the growth-focused nature, distinguishing it from raw balance sheet siblings via the 'growth' term, though it doesn't name alternatives.

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?

Usage is implied: use when you want to track changes in balance sheet items over time. However, there is no explicit when-to-use vs alternatives (e.g., getBalanceSheetStatement, getBalanceSheetStatementTTM) or exclusions, leaving the agent to infer context.

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

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

No annotations are provided, so the description must carry full behavioral disclosure. It does not mention pagination, response size, rate limits, or how the tool selects companies given only year and period parameters. 'Comprehensive access' is vague and does not disclose return format, data volume, or any 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 three sentences, but the first sentence is vague ('comprehensive access') and the second is somewhat redundant. It is not excessively long, but it could be more direct and better structured with key details 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?

There is no output schema and no annotations, so the description should explain return structure, bulk behavior, and usage boundaries. It only mentions key figures and comparing companies, leaving major gaps for a bulk API tool, including how to specify companies and what the response contains.

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 for the two parameters (year, period) is 100%, so baseline is 3. The description adds context about the data content (total assets, liabilities, equity) but does not clarify the missing company selection parameter or how 'bulk' works with only year/period, which could confuse agents.

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 tool as a 'Bulk Balance Sheet Statement API' that provides balance sheet data for multiple companies, with specific fields (total assets, liabilities, equity). The word 'Bulk' distinguishes it from single-company balance sheet siblings, though it lacks a direct action verb like 'returns' or 'retrieves'.

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

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

The description states it is 'Ideal for comparing the financial health and stability of different companies on a large scale,' which clearly indicates when to use it. It does not explicitly mention alternatives or when not to use it, but the bulk versus single-company distinction is implied by the name and description.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It only says 'access' (implying read-only) but does not explain TTM specifics, data scope, limit semantics, or any potential caveats. The schema covers the limit parameter, but the description adds no extra behavioral context beyond the name itself.

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 concise, but it includes a redundant product name ('Balance Sheet Data API') and a somewhat fluffy concluding phrase about gaining insights. It is not badly overlong, but every sentence does not fully 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 low complexity (2 params, no nested objects), the description is passable but incomplete. It fails to mention the crucial TTM distinction, which is essential for correct tool selection. Since there is no output schema, a clearer description of what the returned balance sheet contains and how 'limit' applies would strengthen 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?

Schema description coverage is 100%, with clear descriptions for 'symbol' and 'limit', so the structured metadata already explains the parameters. The description does not add any further meaning, but the baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description states it provides 'detailed balance sheet statements for publicly traded companies' with a clear verb and resource, but it fails to mention the TTM (trailing twelve months) aspect that distinguishes this tool from siblings like getBalanceSheetStatement. This lack of differentiation makes it ambiguous which balance sheet 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?

There is no guidance on when to use this tool versus alternatives. It does not explain that this is the TTM version, nor does it mention exclusions or alternatives such as as-reported or growth statements. The only implied context is for analyzing financial health, which is too generic.

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 useful context: real-time data, post-market timing, and the specific data fields (bid, ask, volume). However, it does not disclose potential behavioral nuances like symbol limits, missing aftermarket quotes, or rate limiting.

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

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

The description is two sentences, front-loaded with the primary action and resource, and contains zero filler or redundant details.

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

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

For a simple one-parameter read-only tool with no output schema, the description sufficiently communicates the data scope (bid, ask, volume, other relevant data) and timing. It does not delve into return structure or limitations, but the tool is straightforward enough that this feels incomplete only at the margins.

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

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

Schema coverage is 100% with the parameter description 'Comma-separated list of stock symbols'. The tool description reinforces the 'multiple stocks' aspect but adds no new format or constraints beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

Description uses the specific verb 'Retrieve' and accurate resource 'aftermarket quotes for multiple stocks', clearly distinguishing it from singular getAftermarketQuote and regular-hours getBatchQuotes by emphasizing batch and post-market 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?

Provides clear context for when to use (multiple stocks, during post-market trading) but does not explicitly name alternatives or exclusions. The post-market and multiple-stock cues make the intended use obvious without needing to mention sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that data is real-time and includes post-market trade prices, volumes, and timestamps. However, it does not mention output structure, any limitations, or whether the response is keyed by symbol, which would be valuable 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 two sentences long, front-loaded with the main verb and resource, and contains no redundant phrasing. Each sentence adds value: the first states the core action, the second elaborates on the data fields.

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

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

For a simple one-parameter batch retrieval tool with no output schema, the description adequately covers the input and the returned data elements (prices, volumes, timestamps). It could be slightly more complete by clarifying whether the response is an object keyed by symbol or an array, but this is a minor gap.

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

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

The schema already provides a 100% clear description for the only parameter: 'Comma-separated list of stock symbols'. The description adds no new semantic details beyond paraphrasing with 'multiple stocks' and 'several companies', so it does not enhance the schema's 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 verb 'Retrieve' and the resource 'real-time aftermarket trading data for multiple stocks'. It specifically mentions the FMP Batch Aftermarket Trade API and distinguishes itself from siblings like getAftermarketTrade (singular) and getBatchAftermarketQuote by emphasizing 'trade data' and 'across several companies simultaneously'.

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 by saying 'for multiple stocks' and 'across several companies simultaneously', but it does not explicitly mention when to use this tool versus alternatives like getAftermarketTrade or getBatchAftermarketQuote, nor does it provide exclusion 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 burden. It implies a read-only operation ('Retrieve') and highlights the batch behavior (single request, multiple companies), but it does not disclose any potential limitations such as rate limits, maximum number of symbols, or data freshness. For a simple read tool, this is adequate but not rich in behavioral detail.

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

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

The description is two sentences, with the primary action and scope in the first sentence. It is well-structured and front-loaded, and the second sentence adds a brief use-case rationale without unnecessary verbosity. 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?

For a simple tool with a single, fully documented parameter, the description covers the core action and use case. There is no output schema, so the description should ideally specify return values more precisely, but 'market capitalization data for multiple companies' implies a collection of records. It lacks explicit details on the response format, but given the tool's simplicity, this is a minor gap.

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

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

Schema description coverage is 100% with 'symbols' described as 'Comma-separated list of stock symbols'. The description adds little beyond the schema, merely reinforcing that multiple companies are supported. It does not provide additional meaning about formatting, examples, or constraints, so it meets the baseline without exceeding it.

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

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

The description clearly states the action ('Retrieve market capitalization data') and the scope ('for multiple companies in a single request'), distinguishing it from single-company market cap tools. It also names the specific API (FMP Batch Market Capitalization API), leaving no ambiguity about the tool's function.

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

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

The description provides clear context for when to use the tool: when comparing market size of various companies simultaneously, streamlining valuation analysis. It does not explicitly mention alternatives or when not to use it, but the batch context is sufficient for a simple retrieval tool.

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 transparency burden. It discloses that quotes are real-time, retrieved in a single request, and include current prices, volume, and detailed data. However, it does not specify response format, auth/rate limits, or exact scope of 'detailed 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?

Two concise sentences, front-loaded with the core action, and every clause adds value. The use-case sentence is helpful for context without being wordy or redundant.

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 low-complexity tool with one fully described parameter, the description covers the purpose and typical use case. The lack of an output schema is partially mitigated by naming prices, volume, and detailed data, though 'detailed data' remains vague.

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

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

The schema already fully documents the single 'symbols' parameter as a comma-separated list, so the description adds no new parameter-level semantics. It merely restates the multi-company concept, which keeps the score at 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 uses a specific verb ('Retrieve'), a clear resource ('multiple real-time stock quotes'), and states the batch/API nature. It distinguishes from siblings like getQuote (single stock) and getBatchQuotesShort by emphasizing 'multiple' and 'detailed 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?

It provides a clear context: tracking large portfolios or monitoring multiple stocks simultaneously. However, it does not explicitly mention when not to use it or point to alternatives like getQuote or getBatchQuotesShort.

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 burden of disclosure. It adds context about real-time data, short-form fields, and batch processing, which is useful. It also lists expected output fields (price, change, volume). While it doesn't mention response format or limitations, it is not misleading and provides reasonable transparency for a read-only quote tool.

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

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

Two sentences, front-loaded with the core action and purpose. No redundant or extraneous information. The structure is clean and immediately comprehensible.

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

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

For a simple one-parameter tool with no output schema, the description provides sufficient context: it explains the batch quote nature, the short-form data, and example output fields. It could be more explicit about the response format, but the tool is straightforward and the description covers the essentials adequately.

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

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

The single parameter 'symbols' is fully described in the schema with 100% coverage as a comma-separated list. The description adds no new syntax or formatting details beyond the schema, only reinforcing the 'multiple' aspect. The schema already handles the semantics, so the description provides marginal additional value.

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

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

The description clearly states the tool accesses real-time, short-form quotes for multiple stocks, specifying the FMP Stock Batch Quote Short API. It mentions key data like price, change, and volume, which distinguishes it from single-stock quote tools like getQuoteShort and full batch tools like getBatchQuotes.

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 quickly fetching a snapshot of multiple stocks in one request, but it does not explicitly compare to alternatives or state when not to use this tool. The context of 'short-form' and 'multiple' is present, but no exclusions or alternative tools are named.

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 only describes the purpose ('track', 'identify') and does not mention return format, pagination, time period, or any limitations of the underlying 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?

The first sentence is concise and informative, but the second sentence largely restates the first with redundant marketing language ('significant price surges', 'potential growth opportunities'), adding little value.

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

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

There is no output schema or annotations, and the description does not explain what the tool returns (e.g., list of tickers, price changes). For a simple no-param tool, it still leaves a gap in what the agent can expect from the response.

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

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

The input schema has zero parameters, so the baseline is 4. The description appropriately does not invent parameter details; it simply frames the tool's context, which is sufficient for a no-parameter tool.

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

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

The description clearly states the tool's function: tracking stocks with the largest price increases via the Top Stock Gainers API. This distinguishes it from siblings like getBiggestLosers and getMostActiveStocks by specifying the exact resource and 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 explicit guidance is given on when to use this tool versus alternatives. The description implies usage for identifying top gainers, but it does not mention exclusions or direct users to other tools for related 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 must fully disclose behavioral traits. It only restates the tool's purpose without noting output format, sorting order, time frame, data granularity, or whether the data is real-time. Phrases like 'identify companies' and 'track stocks' add no concrete behavioral detail.

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

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

The description is short but redundant. 'Largest price drops,' 'significant declines,' and 'falling fastest' all convey the same idea across two sentences. The second sentence adds little beyond the first, making it less concise than it could be.

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 (no params, no output schema), the description still fails to specify what data is actually returned (e.g., list of tickers, percentage drops, prices). It says 'access data' but does not describe the response structure, leaving significant ambiguity for an agent that needs to interpret the tool's output.

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

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

The tool has zero parameters, and the schema is empty. The baseline for 0-param tools is 4; the description does not need to explain parameter semantics since none exist. The description adds no parameter information but also does not need to.

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's purpose: accessing data on stocks with the largest price drops. It uses a specific verb ('Access data') and a specific resource ('stocks with the largest price drops'), and it implicitly distinguishes itself from sibling tools like getBiggestGainers by focusing on declines rather than gains.

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

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

The description states the clear context for use: when you need information on the biggest stock market losers. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent can infer when to invoke this tool versus its gainer counterpart.

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 disclosure. It fails to mention any behavioral aspects such as return format, data source limitations, or the meaning of recent_n. The tool's behavior is completely opaque.

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

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

The description is a single concise sentence that is well-structured and easy to read. It wastes no words, but it is overly vague, lacking the specificity that would make the conciseness truly effective.

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

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

The tool has 3 parameters, no output schema, and no annotations, leaving the description as the sole source of context. It provides no information about what the cash flow data contains, how many records are returned, or the significance of the source parameter. This makes the description inadequate for effective use.

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

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

The schema already provides 100% coverage for parameters (source, symbol, recent_n), so the description does not need to repeat them. However, the description adds no additional meaning beyond the schema, earning 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 states the tool's action and resource: 'Get company cash flow statement data.' It is specific enough to understand the primary function but does not distinguish itself from sibling tools like getCashFlowStatement or getCashFlowStatementTTM, so it falls short of 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?

No guidance is provided on when to use this tool versus alternatives. The description merely states what it does without any context, prerequisites, or exclusions, leaving the agent without a basis for tool 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?

No annotations are provided, so the description must reveal behavior itself. It mentions tracking changes over time and multiple companies, but it does not disclose output format, pagination, growth calculation methodology, or whether all companies are returned for the given year and period. This is a significant behavioral gap.

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 compact, consisting of two sentences that front-load the tool's purpose and then offer a context for use. It is efficient with no filler, although the first sentence repeats the tool name and the second sentence is somewhat promotional.

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 and no annotations, the description carries the full burden of explaining response semantics. It fails to describe the shape of the returned data, the meaning of growth, or the company coverage behavior, making it incomplete for an agent trying to reason about the tool's output.

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

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

The schema provides descriptions for both required parameters, with year example and period options, so schema coverage is complete. The description adds no additional meaning about how the parameters affect results, and it does not clarify how multiple companies are selected given only year and period are accepted.

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 retrieving bulk growth data for cash flow statements, with a focus on tracking changes over time across multiple companies. This verb-resource-scope structure distinguishes it from the single-company getCashFlowStatementGrowth sibling, though the exact nature of growth data remains slightly generic.

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 only usage guidance is that the API is ideal for analyzing cash flow growth trends of multiple companies simultaneously, which implies bulk scenarios. However, it does not explicitly name alternatives, exclusions, or prerequisites, leaving the when-not-to-use case unclear.

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 burden of disclosing behavioral traits. It does not mention return format, whether historical data is provided, required inputs, or any operational details. It only gives a generic purpose statement, which provides minimal insight into actual tool 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 is short but padded with vague marketing language like 'Gain insights' and 'evaluate the financial health and sustainability.' The first sentence is redundant with the tool name, and neither sentence provides concrete operational information, so it is under-specified rather than concise.

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

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

With no annotations and no output schema, the description needs to explain return values and usage context, but it does not. It lacks information about what data is returned, how to interpret results, or any limitations. The schema covers parameters, but the description is insufficient for a complete understanding of the 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 schema description coverage is 100%, with 'symbol', 'limit', and 'period' all documented. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies. It does not clarify how parameters affect the output or provide 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 identifies the resource as a company's cash flow statement and explains it analyzes operations, investments, and financing activities. It is specific about the subject matter but does not distinguish it from sibling tools like get_cash_flow or getCashFlowStatementTTM, so it lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool compared to alternatives. It only implies usage for cash flow analysis without mentioning exclusions, prerequisites, or when to choose a different cash flow tool such as getCashFlowStatementTTM or getCashFlowGrowth.

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 burden. It adds useful behavioral context by stating the data comes directly from official company reports and covers operating, investing, and financing flows. However, it does not disclose return format, pagination, line-item variability, or other limitations such as period-specific nuances.

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 no redundant content. It front-loads the core purpose and adds a concise explanation of the data's content and source. Every word contributes to understanding.

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

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

With no output schema and no annotations, the description covers the conceptual purpose and data origin but omits response structure, result format, and explicit usage boundaries. The parameter schema is fully covered, yet the lack of return-value details leaves the description only minimally viable for an agent.

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

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

The input schema already describes all three parameters (symbol, period, limit) with clear descriptions and an enum for period, providing 100% coverage. The description adds no additional parameter-level semantics beyond those in the schema, so baseline 3 applies.

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 views cash flow statements 'as reported' by the company from official reports, using the specific verb 'View' and identifying the resource. This distinguishes it from siblings like getCashFlowStatement or getCashFlowStatementTTM that likely provide normalized or calculated 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 implies usage for analyzing official, as-reported cash flow data, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. There is no reference to sibling tools such as getCashFlowStatement, getCashFlowStatementGrowth, or bulk variants, so guidance is only inferred.

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

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

No annotations are provided, so the description must disclose behavior, but it only restates the high-level purpose. It doesn't explain the return structure, period-over-period calculation, handling of missing data, pagination, or other API constraints, leaving the agent with little behavioral insight.

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 short and front-loaded, but the second sentence ('Determine how quickly...') largely restates the first without adding substantive information. It is concise but mildly redundant.

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 and sparse description, the agent cannot anticipate what the response contains or how growth rates are presented. The schema covers parameters, but the return value and growth-rate semantics are unexplained, making the description incomplete for confident tool invocation.

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

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

The input schema already describes all three parameters (symbol, period, limit) with 100% coverage, so the baseline is 3. The description adds no parameter-specific detail, but none is necessary given the 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 identifies the action ('Measure the growth rate') and the resource ('company's cash flow'), which is sufficient to distinguish it from the many cash-flow statement/list siblings. However, it does not explicitly name any alternative tool, so it stops short of full differentiation.

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

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

The usage is implied: if you need to measure growth of cash flow, this is the tool. But it provides no explicit when-to-use versus alternatives like getCashFlowStatement, getCashFlowGrowthBulk, or getCashFlowStatementTTM, and no exclusion 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, the description carries the full burden of behavioral disclosure. It only mentions the high-level content categories and says 'wide range of companies' without specifying the actual behavior: what records are returned, whether it is all companies, pagination, response format, or any rate/scope limitations.

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 compact at two sentences, but there is redundancy: 'provides access to detailed cash flow reports' and 'enables users to retrieve bulk cash flow statement data' restate the same idea. It is not bloated, but it could be tighter and more direct.

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?

There is no output schema and no annotations, so the description needed to explain what a bulk response looks like and how year/period scope it. It only vaguely promises 'detailed cash flow reports' and does not clarify the company universe, response size, or data granularity, leaving the tool under-specified.

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%: both year and period have explicit descriptions with examples ('Year (e.g., 2023)', 'Period (Q1, Q2, Q3, Q4, FY)'). The description adds no parameter-level detail beyond the schema, so the baseline score of 3 applies.

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 retrieving bulk cash flow statement data and names the report content (operating, investing, financing activities). It is more specific than a tautology and the 'Bulk' scope distinguishes it from single-company cash flow siblings, though it does not exactly define the company universe.

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 'wide range of companies' and the name 'Bulk' imply this is for multi-company data, and the schema requiring only year/period reinforces that. However, the description does not explicitly state when to prefer this over getCashFlowStatement, getCashFlowStatementAsReported, or getCashFlowGrowthBulk, nor does it provide exclusions or alternative guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only offers generic marketing language about evaluating financial health. It does not disclose what the tool returns (e.g., a list of cash flow statements for a symbol), its read-only nature, defaults, or any side effects or limitations.

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 concise at two sentences, but the content is largely promotional and repetitive of the tool's name. It spends words on 'gain insights' and 'evaluate financial health' rather than providing concrete details, so the sentences do not fully earn their place.

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

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

Given the large number of sibling tools for cash flow statements, this description is incomplete. It does not explain the TTM distinction, which is critical for selecting this tool, nor does it specify the output format or typical use cases. The schema covers parameters, but the high-level context is missing.

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 already provides full descriptions for both parameters (symbol and limit) with 100% coverage. The description adds no parameter-specific information, so it earns 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 states that the tool provides insights into cash flow activities, but the verb 'analyze' is vague and does not clearly indicate that this tool returns cash flow statement data. It fails to mention the 'TTM' (trailing twelve months) scope that differentiates it from sibling tools like getCashFlowStatement, making its specific purpose 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?

No guidance is provided on when to use this tool versus alternatives such as getCashFlowStatement, getCashFlowStatementAsReported, or getCashFlowStatementGrowth. The description gives no context about use cases, prerequisites, or when TTM data would be preferred.

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 present, the description carries the full burden of behavioral disclosure. It only states that the tool provides access to CIK numbers, but does not explain what the response contains, whether results are paginated, how the 'limit' parameter affects behavior, or any other operational detail. This is a significant gap for a data retrieval tool.

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. The first sentence is informative, but the second sentence is promotional and adds no technical value. It is reasonably sized but includes unnecessary marketing language, preventing a high score.

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 one optional parameter and no output schema, the description should clarify what the endpoint returns and how the limit applies. It only gives a general overview of the data source, leaving the agent without essential information about the response structure or usage constraints. This is incomplete even for a simple 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 describes the 'limit' parameter with its default value, achieving 100% coverage. The description adds no parameter-specific information, but the schema already handles it, so a baseline of 3 is appropriate. The description does not enrich the meaning 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 accesses a database of CIK numbers for SEC-registered entities, with the resource named as the FMP CIK List API. It uses a specific verb ('Access') and resource, but does not explicitly distinguish itself from sibling tools like searchCIK or getCompanyProfileByCIK.

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 use case context (regulatory compliance, financial transactions, investment research) and identifies target users, but does not mention when NOT to use it or point to alternatives. This is clear context without exclusions, matching a score of 4.

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

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

With no annotations, the description carries the transparency burden. It notes the data is up-to-the-minute and includes prices, changes, and volumes, but does not disclose potential limitations such as API key requirements, rate limits, or that it returns a bulk list of all commodities.

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

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

The description is two sentences, front-loaded with the core purpose, and includes useful specifics without any fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description conveys what it does and what data it returns. It doesn't mention the 'short' parameter, but the schema covers that, so the overall context is sufficient.

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

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

The schema provides 100% coverage for the sole 'short' parameter. The description adds no extra context about this parameter, but since the schema already defines it, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves real-time commodity quotes, naming the API and specific commodity types (oil, gold, agricultural). It differentiates from sibling quote tools by explicitly focusing on commodities.

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

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

The description implies the tool is for commodity quotes but does not explicitly contrast with sibling tools like getCryptoQuotes or getForexQuotes. It lacks explicit guidance on when to prefer this tool or when not to use it.

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

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

The description indicates a read operation via the verb 'Retrieve' and provides context about the returned data fields. With no annotations provided, the description carries the transparency burden, but it does not mention potential errors, authentication requirements, or the behavior of the 'active' filter. However, for a simple read-only API, the disclosure is minimally adequate.

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

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

The description is two sentences, front-loaded with the action verb 'Retrieve', and includes relevant detail without redundancy. It efficiently conveys the tool's purpose and output 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 2-parameter read API without an output schema, the description covers the purpose, data fields, and general context. It lacks explicit sibling differentiation and does not elaborate on the 'active' parameter, but it provides enough information for an agent to select and invoke the tool correctly.

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

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

The input schema already documents both parameters with descriptions: 'symbol' as 'Stock symbol' and 'active' as 'Filter for active executives', giving 100% coverage. The description adds context about returned fields (compensation, demographics) but does not clarify expected values for 'active' (e.g., 'true'/'false' vs. arbitrary strings), so it adds only marginal value 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 detailed executive information via the FMP API and lists specific fields (name, title, compensation, demographic details). It is specific enough to identify the tool's focus, but it does not explicitly distinguish it from siblings like getExecutiveCompensation, which also deals with executive 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?

No explicit when-to-use or alternative guidance is provided. The description implies the tool is for retrieving executive details, but it does not mention when to prefer this tool over related ones like getExecutiveCompensation or getCompanyProfile, nor does it list any 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?

There are no annotations, and the description does not disclose behavioral traits beyond the operation itself. It does not mention whether this is read-only, any required permissions, rate limits, or output format/limitations, leaving the agent with limited safety or behavior context.

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

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

Two concise sentences: the first states the purpose and API, the second lists key returned fields. No redundant or unnecessary text, and it is front-loaded with the verb and resource.

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

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

For a simple one-parameter retrieval with no output schema, the description provides sufficient context by listing representative fields (CIK, symbol, note title, exchange). It does not detail output shape (single note vs array) or edge cases, but it covers the core essentials.

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 single parameter 'symbol' is already fully documented in the schema as 'Stock symbol', and the description adds no additional parameter semantics. With 100% schema description coverage, the baseline of 3 is appropriate; the description simply references stock symbol as part of the returned data.

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

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

The description clearly states the action ('Retrieve detailed information') and the resource ('company-issued notes'), with concrete data examples. It does not explicitly distinguish this from related FMP tools or mention alternatives, so it falls short of full differentiation.

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

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

No guidance is provided about when to use this tool versus the many sibling tools (e.g., getCompanyProfile, getCIKList). It only describes what the tool does, not the conditions or context for using it.

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

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

With no annotations available, the description must disclose behavioral traits. It lists a few output fields but does not mention data freshness, authentication requirements, rate limits, or the return format. The phrase 'and much more' is vague and leaves the agent unaware of what other data to expect.

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 short, but it is somewhat redundant: 'company profile' appears both in the tool name and the first sentence, and 'API' is mentioned twice. The phrase 'and much more' is filler that adds no concrete value.

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

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

For a simple one-parameter tool, the description gives a basic sense of what is returned (market cap, stock price, industry), which is helpful given no output schema. However, it lacks details about the response structure, error cases, or how this compares to the many other quote/profile-related siblings, leaving the agent slightly underinformed.

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

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

The input schema fully covers the single parameter with 'Stock symbol', so the baseline is 3. The description adds 'specific' but provides no additional syntax, case sensitivity, or format details beyond the schema, so it adds minimal extra value.

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

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

The description clearly states the tool retrieves detailed company profile data for a specific stock symbol, listing example fields like market cap, stock price, and industry. It does not explicitly name sibling tools for differentiation, but the emphasis on 'specific stock symbol' implies a single-symbol lookup, which distinguishes it from bulk or CIK-based variants.

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 usage guidance is provided. The description does not mention when to prefer this tool over alternatives like getCompanyProfileByCIK, getCompanyProfilesBulk, or getQuote, nor does it state any exclusions or prerequisites. It only implies that it is for fetching a profile, offering no actionable 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read/retrieve operation, but does not mention response format, pagination, error handling, rate limits, or any special requirements. The phrase 'full range of company data' is vague and fails to provide actionable detail beyond what the name itself implies.

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 concise at two sentences and front-loads the core purpose. However, the second sentence contains some redundancy ('This API allows users to search...') and vague phrasing ('and much more') that could be tightened. It earns a 4 for overall efficiency and clarity.

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

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

The tool has only one parameter and no output schema, so the description must convey what the response contains. It lists some example fields (stock price, market cap, industry) but does not guarantee completeness or describe the response structure. It also does not address edge cases like unknown CIKs. This is adequate but lacks full context.

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

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

The schema's parameter description is minimal ('CIK number'), but the tool description adds meaningful context by explaining that CIK is the Central Index Key and how it is used to search for companies. This helps the agent understand the parameter's purpose and format beyond the schema, despite the high schema coverage (100%).

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

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

The description clearly states the tool's function with a specific verb: 'Retrieve detailed company profile data by CIK'. It explicitly identifies the resource (company profile) and the unique identifier (CIK), distinguishing it from sibling tools like getCompanyProfile that likely use symbols. The inclusion of example data fields adds specificity.

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 this tool: when you have a CIK identifier and need a company profile. It says 'This API allows users to search for companies using their unique CIK identifier'. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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