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 several behavioral traits: newest-first ordering with intent-strength tiebreaker, default limit of 25, pagination via offset, total_matched count reporting, and the data-quality rule that filings without a source filing_url are dropped. This is strong behavioral disclosure for a read-only query 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?

Four sentences, all informative, with the core purpose front-loaded and no redundant filler. Every sentence earns its place by adding sorting, pagination, filtering, or data-quality context.

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

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

Given the tool's moderate complexity, full parameter schema coverage, and absence of an output schema, the description is complete enough to invoke correctly. It covers ordering, default limit, pagination, all optional filters, the count field, and the source-link requirement, leaving no critical operational 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%, so the schema already documents all five parameters. The description adds little beyond restating limit/offset/total_matched behavior already present in the schema, so it does not significantly enhance parameter-level 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 states a specific resource ('Recent activist Schedule 13D / 13D-A filings on US-listed companies') and a clear operation ('Returns the newest 25 by default'), with distinctive sorting by stated-intent strength. This makes the tool clearly distinguishable from siblings like verify_activist_13d and insider_signals_today.

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 context for when to use the tool: when you need recent activist Schedule 13D/13D-A filings, with optional filtering by ticker, percent, and days. It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous enough to infer appropriate use.

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 behavioral disclosure. It proactively reveals a non-obvious behavior: awards without a source link are dropped and never returned. It also clarifies ordering, pagination behavior, and the total_matched field. This goes beyond a generic 'returns awards' statement and helps an agent set 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?

Three dense sentences: purpose and ordering first, pagination and defaults second, filters and a key behavioral caveat third. Every sentence contributes distinct information and there is no filler or repetition of the schema field names.

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 listing tool with no output schema and no annotations, the description covers the necessary operational details: default page size, pagination, filtering, full count, and the dropped-award behavior. It does not enumerate award fields beyond award_url, but an agent can still call the tool correctly; the missing return schema is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it specifies the default limit (25), the 'newest first' ordering, the use of total_matched for full count, and interprets min_amount as a 'USD floor' and days as a 'last-N-days window'. This helps an agent compose correct queries without opening 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 opens with a specific verb and resource: 'Returns the newest U.S. federal new awards from USAspending.gov', and explicitly states ordering ('newest first'). It clearly distinguishes itself from the sibling tools, which are all about insider trading and 13F filings, by naming its unique data source and subject.

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 gives clear operational context: default limit of 25, pagination via offset, total_matched for full count, min_amount and days as optional filters. It does not explicitly name alternatives or exclusions, but none of the sibling tools are relevant substitutes, so the guidance is sufficient for an agent to know when to invoke 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 full burden and excels: it discloses data staleness (~45 days), ticker null policy, 'first_filing_on_record' state, CIK vs brand coverage, re-ranking, active/passive non-tagging, and the nature as a convenience view. This is exemplary transparency beyond what any schema could encode.

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 long but every sentence carries substantive information—no filler. It front-loads the core purpose and then layers caveats logically. While a bit dense, the structure is efficient for the tool's complexity, earning a 4 rather than 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?

For a tool with no output schema, the description enumerates all returned fields (as_of_quarter_end, filed_date, lag_days, value_usd, cusip, issuer_name, filing_url, ticker) and covers pagination, defaults, filtering, and edge cases. An agent has everything needed to call it correctly and 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% and each parameter already has a descriptive schema entry (e.g., 'filer' substring/CIK, 'change_type' enum, 'min_value_usd' in whole dollars). The description adds marginal semantic value, mostly reinforcing pagination defaults. It meets the baseline 3 without adding new meaning.

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 opens with a clear verb+resource: 'What large institutional filers CHANGED quarter-over-quarter in their SEC 13F-HR holdings'. It explicitly contrasts the delta product vs raw snapshot, and distinguishes from siblings like verify_13f_holding by focusing on changes, not static 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 by clarifying what it covers (LONG US 13(f)-listed positions, top 50 filers) and what it doesn't (shorts, non-US, options). It also warns 'NOT a trading edge' and explains that changes reflect index rebalancing, guiding an agent on interpretation. It does not name specific sibling tools, but the context is sufficient.

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

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

With no annotations, the description carries the full behavioral-disclosure burden. It explains the uniform_price_cluster flag, the Form-4 code P ambiguity, the ranking of genuine clusters above uniform-price ones, default limit and pagination, total_matched, and filing_url. This is far more transparency than a typical 'returns cluster buys' statement.

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 dense and organized: scope, flag caveat, ranking, pagination, and source URL. No sentence is filler; the Form-4 note is essential to interpreting uniform_price_cluster correctly. It is somewhat long and packed into one paragraph, so it is not maximally 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?

Despite lacking an output schema, it tells the agent the key returned fields (uniform_price_cluster, total_matched, filing_url) and the exact collection semantics: newest 25 by default, limit/offset pagination, optional days/ticker filters, and ordering/ranking. Nothing critical is missing for a read-only filtered 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 coverage is 100%, so the baseline is 3, but the description adds semantic guidance: 'set limit; page with offset; optional days/ticker; total_matched reports the full count' and reiterates default 25 newest-first. This is a modest but real addition over the 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?

Opens with 'Rule-2 cluster buys only (>=2 insiders buying the same issuer in-window)' and later 'Returns the newest 25' – a specific resource and filtering rule. This clearly identifies it as the focused cluster-buy subset and distinguishes it from broader insider-signal siblings without needing to inspect their schemas.

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 'Rule-2 cluster buys only' plus 'highest-signal subset' tells an agent to use this endpoint for high-conviction cluster signals, not general single-insider signals. It also explains the uniform-price distinction and ranking, but it does not name sibling tools or state explicit when-not conditions, so it stops 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.

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

With no annotations, the description carries the full behavioral burden and does disclose the return item (single Rule-2 record + filing_url) and an error on no gated match. It does not, however, mention read-only/safety status, access restrictions, or any other operational constraints beyond the brief 'gated' hint.

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

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

Two sentences with no filler; the resource and scope are front-loaded and the error condition adds useful information. 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 one-parameter tool with no output schema, the description provides the lookup key, the returned object (including filing_url), and the failure condition. It is complete enough to invoke correctly, though the full Rule-2 record shape is not enumerated.

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 the only parameter (accession) with an example, so the description adds no new parameter-level meaning. 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 identifies a specific resource: the single Rule-2 SEC filing record for one accession, and states that it includes the filing_url. This accession-keyed lookup is clearly distinguished from sibling signal/date/ticker tools, so an agent can tell what it does.

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 one SEC filing accession' implies that the tool is for resolving a single known filing ID, but the description never explicitly says when to prefer it over the sibling signal/cluster tools or when not to use it. Usage is inferable rather than spelled out.

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 burden and does well: it discloses the default limit of 25, pagination via offset, the total_matched count, and the filing_url on each record. It does not cover error behavior or the interaction between days and start/end, but the core query behavior is transparent.

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 dense, well-structured sentences that front-load the core purpose and then compactly cover defaults, pagination, filtering, and response context. There is no filler or redundant repetition of schema 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 read-only query tool with no output schema and no annotations, this description is largely complete: it explains default behavior, pagination, full count, and a key response field. Minor gaps include the undefined meaning of 'Rule-2' and the ambiguous interplay of days with start/end, but these do not block correct 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?

Schema coverage is 100%, and each parameter already has a meaningful description. The tool description restates limit/offset/days/ticker behavior and mentions total_matched, but adds little semantic meaning beyond what the input 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 states a specific verb ('Returns'), a concrete resource ('Rule-2 insider-buy signals'), and a clear scope (filed within an inclusive ISO date range). This distinguishes it from siblings like insider_signals_by_ticker and insider_signals_today.

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 date-range focus is clear, and optional filters like ticker and days signal when this tool is appropriate. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to select it for date-based insider-buy signal queries.

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

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

With no annotations, the description carries the behavioral burden, and it discloses the default limit of 25 newest-first, pagination via offset, optional days filtering, the total_matched count behavior, and filing_url on each record. It could add details about invalid-ticker handling or what Rule-2 means, but the main behavioral surface is covered.

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 and front-loaded: scope first, then defaults and pagination, then response highlights. Every clause adds operational value and there is no 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 one-required-parameter listing endpoint, the description is complete: it explains the default behavior, how to paginate, the optional time filter, the full count field, and the source URL on each record. Nothing an agent needs to call it correctly 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?

All four parameters are already documented in the schema (100% coverage), so the baseline is 3. The description mostly restates the schema's default, pagination, and days behavior without adding genuinely new semantics.

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 opening phrase 'All Rule-2 insider-buy signals for one ticker' names a specific resource and scope, and the title reinforces the ticker focus. The case-insensitive note and pagination details make the tool's job unambiguous and distinguish it from date-range or cluster siblings.

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 states that the tool is scoped to a single ticker and explains how to page and filter, so an agent can infer when it is the right choice for a known-ticker signal query. It does not explicitly name alternatives or say when not to use it, but the ticker scope implicitly separates it from insider_signals_by_date_range and insider_signals_today.

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 pagination via limit/offset, the total_matched count, and that each record has a filing_url. It does not mention rate limits or auth, but as a read-only query tool, the key behaviors are covered. The default of 25 and the limit<=0 no-cap behavior are also noted.

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

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

Two sentences with no filler. The main purpose is stated first, followed by key behavioral details and parameter hints. Every clause adds information, and the structure 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?

There is no output schema, so the description should clarify the response shape. It mentions total_matched and filing_url, giving some idea of the structure. However, it does not list all fields returned or describe error scenarios. Given the simplicity of the tool (4 optional params, no nesting), this is 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 100% and each parameter already has a description. The tool description adds value by explaining how the parameters work together (e.g., default limit of 25, pagination with offset, and total_matched for full count). It also highlights the optional days/ticker filters, which helps an agent understand the intended usage context.

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 returns insider-buy signals that meet a specific rule (Rule-2, SEC code P open-market purchases) and are filed today by default. It explicitly names the resource and the action, and the detail about the default behavior (newest 25) distinguishes it from sibling tools like insider_signals_by_date_range or insider_signals_by_ticker.

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 'today' with optional days/ticker filters, but it does not explicitly compare to sibling tools or state when not to use it. The context is clear enough for an agent to infer that for arbitrary date ranges or specific tickers, other tools might be more appropriate, but this is not spelled out.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses distinct negative outcomes (not_held as a filed 'no' vs not_found), the coverage-window concept, staleness ('up to ~45 days stale'), and the guarantee that 'Every response states the coverage window checked.' These are behavioral traits an agent cannot infer from 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 dense but every clause earns its place: core action in the first sentence, outcome vocabulary immediately after, and a compact 'Rule-2' for limitations. No filler or restatement of the title.

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 and no annotations, it is remarkably complete: the possible return statuses, source link, coverage window, match key rules, and staleness are all stated. An agent can predict both the input requirements and the likely response variants before invoking 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains why ticker is never accepted, ties values to quarter-end as-of dates, and explains start/end as a span when the claim crosses quarters. One inconsistency remains: the schema's required array is empty while the filer property is marked REQUIRED, though the description itself at least identifies filer as the key lookup input.

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 opens with a specific check verb and resource ('Check whether a fund (filer name/CIK) HELD an issuer ... against the filed 13F-HR record') and enumerates distinct return statuses (held, not_held, not_found, out_of_coverage), making the tool's purpose unmistakable. This is clearly separated from sibling verification tools by the 13F-specific scope and status vocabulary.

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 sets the context: verifying a historical 13F holding claim by quarter, and even gives exclusions ('LONG US 13(f) positions only', 'ticker is never accepted'). It does not explicitly name sibling tools or state when another verification tool would be preferred, so it stops short of full when/when-not routing.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the matching tolerance (±3 filing days), the partial-match semantics (same registrant/filing but item/date mismatch), the out_of_scope boundary (no paraphrasing of filing meaning), the out_of_coverage case, and the invariant that every response states the coverage window. It also states Rule-2, that item codes are parsed from the filing, never inferred from prose. This is rich behavioral disclosure 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 dense but well-organized: it front-loads the core verification purpose, then enumerates return statuses, then states the coverage-window invariant and Rule-2. Every sentence earns its place, though the status enumeration is long and could arguably be tightened. It is appropriately sized for a tool with 7 parameters and no annotations.

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 verification tool with 7 optional parameters, no output schema, and no annotations, the description is quite complete: it explains the return statuses, the matching tolerance, the coverage window, and the item-code parsing rule. It does not explicitly explain how the optional parameters combine (e.g., whether cik/company/accession are alternatives or all required), but the schema's 100% coverage and the description's status semantics make the tool usable. A small gap remains around parameter combination logic.

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 7 parameters. The description adds context about how the parameters are used together (e.g., 'in a timeframe', 'claimed item(s)'), and the ±3 filing-day tolerance for the date parameter, but it does not need to restate each parameter. Baseline 3 is appropriate because the schema does the heavy lifting and the description adds only marginal semantic 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 ('Check'), a precise resource ('a claim that a registrant ... filed an 8-K carrying specific SEC item code(s) in a timeframe'), and the exact verification target. It clearly distinguishes itself from sibling tools by focusing on 8-K item-code verification, not activist stakes, insider purchases, or fund positions.

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

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

The description explains the verification workflow and enumerates all possible return statuses (confirmed, not_found, partial, out_of_scope, out_of_coverage), which tells an agent what to expect. It does not explicitly name sibling alternatives or state when not to use this tool, but the status semantics and Rule-2 boundary provide clear context for when it applies.

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 behavioral disclosure burden, and it does so strongly. It reveals the status taxonomy, explains what 'partial' means, promises that every response states the coverage window, and explicitly states the no-estimates rule: absence is reported as absence, never guessed.

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 dense but efficient: each sentence contributes either scope, return behavior, coverage disclosure, or the no-guessing rule. There is no filler, and the most important purpose statement 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?

The description is richly complete for a verification tool with no output schema: it defines all response statuses and coverage behavior. However, all nine schema parameters are optional and the description never states the minimum required claim information, such as at least one identifying field, nor what happens if the agent calls it with no claim details at all.

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 nine parameters, including tolerances like ±3 filing days and ±0.5 percentage points. The description adds framing about claim components but does not materially extend parameter 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 states a specific verb and resource: 'Check a claim ... against the filed Schedule 13D/13D-A record.' It goes beyond a generic verify action by enumerating the exact statuses returned and explicitly excluding passive 13G coverage, which differentiates it from related verification 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 gives clear context for when the tool applies: activist 13D/13D-A claims only, with out_of_scope as the result for passive 13G filings and out_of_coverage outside the collected window. It does not explicitly name sibling alternatives such as verify_insider_purchase or activist_stakes_recent, so it stops short of a full when-to-use vs. alternatives statement.

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 and does so thoroughly. It discloses the exact response statuses (confirmed, not_found, partial, out_of_scope, out_of_coverage), the coverage-window behavior, the itemisation of partial matches, and the 'no estimates' rule, giving the agent an accurate mental model of the tool's 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 front-loaded with the core action, then efficiently lists statuses and key rules without fluff. Every sentence earns its place: purpose, response variants, coverage-window guarantee, and the critical no-guessing policy.

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 9 optional parameters and no output schema, the description unusually well explains what the tool returns and how it behaves across matching outcomes. It only marginally misses guidance on minimum required inputs (e.g., whether ticker/issuer or person alone suffices), but the schema and claim-components list make it 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 100%, so the schema already documents each parameter meaning and format, and the description does not add substantive semantic detail beyond grouping them as 'ticker/issuer, person, amount, timeframe'. The mention of value/date matching tolerances is already present in the schema, so the description adds only limited value here.

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 opens with a specific verb and resource: 'Check a claim about an insider open-market buy ... against the filed record.' It clearly defines the tool's scope by naming the claim components and explicitly listing what is not covered (sales/options/grants), distinguishing it from the sibling signal and lookup 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 first sentence establishes the clear use case: verifying a factual claim against SEC Form 4, which differentiates it from the sibling discovery tools like insider_signals_by_ticker or insider_cluster_buys. It also states an exclusion ('sales/options/grants aren't covered') but does not explicitly name alternative tools for those cases, so it stops 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.