regulatory-filings-mcp

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

Annotations declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context: it returns cluster strength and highlights the signal's premium value. No destructive actions disclosed; consistent with annotations.

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

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

The description is well-structured with a clear opening sentence followed by parameter details. It's moderately concise; the marketing phrase about hedge funds adds minor fluff but does not waste excessive space.

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

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

For a tool with 3 optional parameters and no output schema, the description adequately explains purpose and parameters. However, it omits details on cluster strength interpretation, time range coverage, and potential data limits, leaving some user uncertainty.

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

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

Schema has 0% parameter description coverage, but the description fully compensates by explaining each parameter with defaults and constraints (e.g., days_window supports 30/60/90). This adds critical meaning beyond the raw 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 detects insider buying clusters by multiple officers/directors buying the same stock within a window. It specifies the output format (one row per stock with cluster strength), distinguishing it from raw insider trade tools like get_form_4_insider_trades.

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 high-value signal but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or contrast with siblings like get_form_4_insider_trades for raw trades.

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

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

Annotations already indicate readOnlyHint=true, so no destructive behavior. The description adds value by detailing the output categories (new, increased, reduced, exit) and clarifying that results are per CUSIP. No contradictions.

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

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

The description is two paragraphs: first covering purpose and output, second covering parameters. It is clear and mostly efficient, though the line about WhaleWisdom Premium charges is slightly promotional and not essential.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the main return categories and parameter details. It does not mention pagination or limits, but for a delta computation tool this seems 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?

With 0% schema coverage, the description compensates by explaining filer_cik accepts CIK or fund name, and days_back is a lookback window (with default 90). Both params are given meaningful context beyond their types.

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

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

The description clearly states the tool computes the position delta between a 13F filer's two most recent filings and lists the specific output types (new positions, increased stakes, reduced stakes, full exits). This distinguishes it from sibling get_form_13f_holdings, which would provide raw holdings.

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 delta analysis but does not explicitly state when to use this tool over siblings like get_form_13f_holdings or get_short_interest. No exclusions or alternatives are mentioned, leaving the agent to infer context from sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat safety. However, it adds value by detailing the returned information (high, low, mean, latest changes by firm), providing behavioral context beyond annotations. No contradictions.

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

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

The description is exceptionally concise at two sentences, with the key purpose front-loaded. No redundant information, 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?

For a simple retrieval tool with one parameter and no output schema, the description covers core outputs but lacks details like typical update frequency, pagination, or date ranges. It is minimally viable but missing some context that could improve 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 description coverage is 0%, and the description only repeats that ticker is a required symbol, without adding format, constraints, or examples. The single parameter is minimally documented, leaving ambiguity about acceptable values.

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

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

The description clearly states it retrieves Wall Street analyst price targets, specifying the types of outputs (high, low, mean, latest changes by firm). The verb 'Retrieve' combined with the resource 'analyst targets' and the specific output details make the purpose unambiguous and distinct from sibling tools like get_earnings_estimates.

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 get_earnings_estimates or get_form_13f_holdings. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds limited behavioral transparency beyond that. It mentions the data source (S&P 500) but does not disclose pagination, rate limits, or result variability.

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: one sentence for purpose and one line for the parameter. No wasted words, and the main action is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, no output schema, distinct siblings), the description provides a complete overview. It could be improved by mentioning the return format or example values, but it is sufficient for correct selection and 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 parameter 'min_years' is explained with its purpose and default value, effectively compensating for the 0% schema description coverage. This adds meaningful guidance beyond the raw 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 S&P 500 Dividend Aristocrats, a specific resource, with a clear verb 'retrieve'. It distinguishes from sibling tools which cover other financial data (e.g., detect_insider_cluster, get_13f_delta).

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 fetching dividend aristocrats but lacks explicit guidance on when to use this tool versus alternatives or prerequisites. No when-not-to-use or context for selection among siblings is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds no additional behavioral traits beyond what annotations provide, which is adequate but not enhanced.

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

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

Description is concise with two lines plus args. Purpose is front-loaded, and every sentence is necessary 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?

Tool is simple with 2 optional params and no output schema. Description covers return contents and parameter details adequately. Small gap: no mention of pagination or limits, but not critical given the simplicity.

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

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

Schema description coverage is 0%, but description adds meaning: 'Calendar horizon in days' for days_forward and 'Optional ticker filter (post-filtered)' for ticker. This compensates for missing schema descriptions.

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

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

Description clearly states 'Retrieve upcoming earnings calendar' with specific contents: report dates, EPS estimates, revenue estimates. It is distinct from sibling tools which focus on other financial 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?

Description provides parameter details (days_forward, ticker) but does not explicitly state when to use this tool over alternatives like get_earnings_estimates. Guidance is implied but not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it retrieves revisions over a lookback window, but the mapping of days_back to 30d/60d/90d is vague and potentially contradicts the schema which accepts any integer with default 14. It does not explain pagination or output 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 very concise: two short sentences plus a simple args list. It is front-loaded with the purpose, with no unnecessary words.

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

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

The tool has 2 parameters and no output schema. The description does not describe the return value format or mention pagination despite the openWorldHint annotation. It is adequate for a simple tool but lacks details that an agent might need for integration.

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

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

Schema coverage is 0%, so the description must compensate. It explains ticker as required and days_back as 'Lookback window — maps to 30d / 60d / 90d'. However, the default of 14 is inconsistent with the mapping, and no details are given for other possible values. This adds some meaning but is incomplete and slightly misleading.

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') and the resource ('analyst earnings estimate revisions — EPS upgrades/downgrades over the lookback window'). It distinguishes from siblings like get_analyst_targets (price targets) and get_earnings_calendar (dates).

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 get_analyst_targets or get_earnings_calendar. It does not mention when not to use it or any prerequisites.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds only examples of filers and input format, but does not disclose behavioral traits like what happens if filer not found, rate limits, or auth requirements. With annotations, the bar is lower, but the description adds 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 concise: a lead sentence stating purpose, followed by examples, then a clear Args section. Every sentence adds value with no redundancy.

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

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

For a simple read tool with two parameters, the description covers purpose and parameter semantics well. However, it lacks output format description and explicit guidance on tool selection among many siblings. Given no output schema, some completeness 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 schema has 0% description coverage, so the description compensates well by explaining both parameters: filer_cik can be CIK or fund name, quarter format is YYYY-QN. This adds significant meaning beyond the bare schema types and defaults.

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 SEC Form 13F-HR holdings for institutional investors, providing specific verb and resource. It gives concrete examples (e.g., Berkshire Hathaway) but does not explicitly differentiate from sibling tools like get_13f_delta.

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 examples of use but offers no guidance on when to use this tool versus alternatives such as get_13f_delta or get_schedule_13d_activist. No when-not-to-use or exclusion criteria are mentioned.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds return field details and filtering behavior ('post-filtered'), which is useful but not extensive. No mention of rate limits 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 concise, with a single paragraph that front-loads the purpose, then covers replacement, return fields, and parameters. No redundant sentences.

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

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

Given no output schema, the description adequately states the return values (transaction date, insider name/role, shares, price, value). All three parameters are optional and described, and the tool is well-contextualized among siblings.

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

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

With 0% schema description coverage, the description compensates by listing all three parameters with clear meanings, defaults (e.g., days_back default 30), and examples (e.g., ticker 'NVDA'). It could be more precise about format but is sufficient.

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

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

The description clearly states it retrieves SEC Form 4 insider trades for officers and directors, using the verb 'Retrieve' and specifying the resource. It distinguishes itself from siblings like detect_insider_cluster and get_13f_delta by focusing on raw insider transactions.

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

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

The description implies usage as a replacement for a WhaleWisdom feed but does not explicitly provide when to use vs. alternatives like detect_insider_cluster. No exclusions or context-sensitive guidance is given.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds context about real-time monitoring but does not disclose behavioral details like rate limits, pagination, or data freshness beyond the annotations.

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

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

The description is front-loaded with purpose, followed by a contextual statement and a clear, concise listing of arguments. Every sentence adds value with no redundancy.

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

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

The description covers purpose and parameters but lacks details on return format or pagination. Given no output schema, the agent would benefit from knowing what the tool returns (e.g., list of filing objects with fields).

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

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

With 0% schema description coverage, the description compensates by explaining each parameter (ticker filter, event_type with examples, days_back with default). It adds meaning beyond the schema types, though examples are limited.

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 'Retrieve SEC Form 8-K material event filings' with specific verb and resource, and lists example event types (M&A, executive changes, bankruptcy, earnings, going concerns). It distinguishes from siblings like get_form_13f_holdings by specifying form type and use case.

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 real-time material event monitoring and states it replaces an 8-K Push subscription, providing clear context. However, it does not explicitly compare to sibling tools or specify 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool retrieves data and mentions filtering via parameters, but does not elaborate on behavioral traits like result limits, pagination, or data freshness beyond the annotations.

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

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

The description is concise: one sentence for purpose, one for context, then structured Args block. It is front-loaded and every sentence adds value. Minor improvement could be merging the context sentence for brevity.

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

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

Given 3 optional parameters, no output schema, and sibling tools, the description provides sufficient context to select and invoke the tool. It explains what the tool returns and parameter behavior. The lack of output format is acceptable without 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?

Despite 0% schema description coverage, the description thoroughly documents each of the 3 parameters: state (optional filter), days_back (lookback window, default 30), and min_amount (optional post-filtered amount). This adds essential meaning beyond type/default in the schema.

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

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

The description starts with a clear verb-resource pair: 'Retrieve SEC Form D private offerings'. It specifies the types (private rounds, hedge fund launches, exempt securities filings) and distinguishes itself from sibling tools like 'get_ipo_calendar' or 'get_13f_delta' by focusing solely on Form D filings.

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 ('VC and private equity intel') but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks exclusion criteria or comparative guidance, relying on the tool's unique name to imply use cases.

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

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

The description is consistent with the annotations (readOnlyHint: true, openWorldHint: true) by using 'retrieve' to indicate a safe read operation. It adds that the tool returns specific fields like pricing date and lead underwriters, which provides useful behavioral context beyond the abstract annotations.

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

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

The description is extremely concise: two sentences that first state purpose with specific outputs, then document the parameter. No wasted words, and the critical information is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, no output schema, clear annotations), the description covers the main aspects. It could mention the return format or date range validation, but for a basic read-only calendar tool it is sufficiently informative.

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

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

With schema description coverage at 0%, the description fully compensates by explaining the single parameter 'days_forward' as 'Calendar horizon in days (default 30)' and mentions it is passed via an upstream 'date_range enum', adding semantic meaning absent from the schema.

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

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

The description starts with 'Retrieve upcoming IPO calendar' using a specific verb ('retrieve') and resource ('IPO calendar'), and lists the specific data points returned (pricing date, shares offered, price range, lead underwriters). This clearly distinguishes it from sibling tools like 'get_earnings_calendar' or 'get_form_4_insider_trades'.

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 retrieving IPO events but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Without context on when not to use it, the guidance 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?

Annotations already declare readOnlyHint and openWorldHint. Description adds behavioral context about what constitutes unusual activity but no additional constraints or side effects.

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

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

Two sentences plus parameter list, front-loaded with purpose, no redundant content.

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

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

For a simple read-only tool with two optional parameters and no output schema, the description fully covers what it does and how to use both parameters.

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

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

Schema has 0% coverage, but description explains ticker as optional filter and min_volume_ratio as minimum ratio with default 2.0, adding meaning beyond type/default alone.

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

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

Clearly states the tool retrieves unusual options activity with specific types like volume vs open-interest spikes and smart-money positioning. Distinguishes from sibling tools covering different financial 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?

Implies usage for options unusual activity with filter parameters. No explicit when-not or alternatives, but context is clear given sibling diversity.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it retrieves prices from specific platforms, but does not elaborate on return format, pagination, or data recency. Additional behavioral context beyond annotations is minimal.

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 wasted words. The main purpose is front-loaded, and the parameter explanation is appended efficiently. Every sentence earns its place.

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

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

Given the low complexity (1 optional param, no output schema), the description covers the essential information: what the tool does and how to filter. It does not describe the return structure, but without an output schema, this is acceptable. A minor gap is lack of explanation about data recency or sources beyond naming.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the single parameter as an 'optional company name filter' with examples, which adds meaning beyond the schema's declaration of a string with default. This is helpful but could be more precise (e.g., mention exact matching vs fuzzy).

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 pre-IPO secondary market valuations, names specific sources (Forge, EquityZen, Hiive) and example companies (SpaceX, Stripe, OpenAI). This is a specific verb+resource combination that distinguishes it from all sibling tools which deal with public market 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 pre-IPO secondary valuations and provides an optional company filter, but does not explicitly state when to use vs alternatives or when not to use. However, given the distinct domain (pre-IPO vs public markets), the context is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds no contradiction. It adds context about the >5% stake threshold and activist focus, but does not detail rate limits, pagination, or data freshness. With annotations covering safety, a 3 is appropriate.

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 distinct sections: a purpose line and an Args list. It front-loads the main action and provides examples. Slightly promotional language ('the activist signal') adds minimal value but does not detract significantly.

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 3 optional parameters, no output schema, and annotations providing safety hints, the description covers core functionality. It specifies default lookback and explains each parameter. It lacks explanation of output format or error handling, but these are not critical for a read-only query 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 0%, but the 'Args' section in the description adds meaningful explanations for all three parameters: target_ticker, filer, and days_back (with default 90). The note that filer is 'post-filtered' provides additional nuance. This compensates for the schema's lack of descriptions.

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

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

The description explicitly states it retrieves SEC Schedule 13D/13G activist filings for >5% stakes, and gives specific activist examples (Carl Icahn, Elliott Management). This clearly differentiates it from siblings like get_form_4_insider_trades or get_analyst_targets.

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 activist filings, but it does not explicitly state when to use this tool over alternatives (e.g., get_form_4_insider_trades for insider trades) or when not to use it. No exclusion or context cues.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds context that days_back is 'informational' and the actor returns the latest snapshot, clarifying parameter behavior. No contradictions.

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

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

The description is relatively concise, with a clear main sentence and a structured arg list. However, the arg list could be integrated into the main sentence for better flow. Still, no wasted words.

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

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

The description lists output fields but does not specify format, structure, or whether all fields are always present. Given no output schema, more detail is needed for completeness. It is minimally 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?

Schema coverage is 0%, so the description must explain parameters. It briefly explains ticker as an optional filter and days_back as informational, but lacks detail on how days_back affects results or what 'informational' means. Marginal 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 it retrieves short interest data and lists specific metrics (short ratio, days-to-cover, % of float short, changes vs prior period). This distinguishes it from sibling tools like get_earnings_calendar or get_13f_delta.

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 does not provide guidance on when to use this tool versus alternatives. It lacks any mention of use cases, prerequisites, or when not to use it. With many sibling tools, this omission hinders 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?

Annotations already indicate readOnlyHint=true. The description adds the time horizon parameter but does not disclose data freshness, rate limits, or response structure beyond the basic purpose. With annotations, the bar is lower, and the description provides minimal additional 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 with two sentences, front-loading the purpose and parameter explanation. No extraneous words.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is adequate but lacks detail on return format or data structure. It could be more complete by specifying what is returned.

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

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

Schema description coverage is 0%, so the description compensates by explaining the 'days_forward' parameter as a calendar horizon with a default of 60 days. This adds meaning beyond the schema's default 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 upcoming corporate actions like stock splits, spinoffs, mergers, and special dividends. However, it does not differentiate from sibling tools that also retrieve financial events, though the domain is distinct enough.

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 alternative tools. There is no mention of 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?

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by explaining that the tool 'tracks position changes' and that the quarter parameter is informational (the actor returns the most recently reported quarter per fund). This clarifies behavior beyond annotations.

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

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

The description is extremely concise: a single-sentence purpose followed by a sentence on behavior, then a bulleted args list. Every sentence adds value with no redundancy. Front-loaded with the core purpose.

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

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

Given 2 simple optional parameters, no output schema, and annotations present, the description covers the main purpose, the specific funds, and parameter behavior. It could mention the return format or fields, but for a straightforward retrieval tool with readOnlyHint, it is largely complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the fund parameter as an optional filter with examples (e.g., 'Norway', 'GIC') and clarifies that the quarter parameter is informational—meaning the tool returns the latest available data per fund. This adds meaning absent from the bare schema.

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

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

The description clearly states the verb 'retrieve' and the resource 'sovereign wealth fund (SWF) US equity holdings', naming specific funds (Norway GPFG, GIC, ADIA, PIF). It distinguishes from siblings like get_form_13f_holdings (which covers hedge fund 13F filings) by focusing exclusively on major SWFs.

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 that the tool filters by fund using an optional parameter and that the quarter parameter is informational. However, it does not explicitly state when to use this tool over alternatives or when not to use it, so guidance is implicit but not thorough.

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