insidergraph

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety profile is covered. The description adds useful behavioral context: filtering by code P, sorting by total value, and the derived nature of the signal. However, it does not mention return format, pagination, or default behavior, so it adds moderate but not deep 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 one concise, front-loaded sentence with no wasted words. It states the core action, criteria, unique value, and sorting in a clear structure.

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, the description should clarify return values, but it only says 'Find issuers' without specifying the exact output structure (e.g., list of issuers with total values, fields included). It also does not mention default parameter behavior, though the schema covers defaults. For a read-only aggregation tool, it is adequate but has gaps in return-value detail.

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 each parameter (window_days, min_value_usd, min_distinct_insiders) having a clear description. The tool description adds minimal extra parameter context (e.g., relating to total value and window), but the schema already carries the semantic weight, so a 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 uses a specific verb ('Find') and clearly identifies the resource (issuers with multiple distinct insiders independently buying with their own money, code P, within a window). It distinguishes itself from sibling tools like get_insider_trades by highlighting the cluster signal that raw EDGAR cannot answer and includes a sorting detail.

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 you need cluster signals of independent insider buys), and the phrase 'a signal raw EDGAR cannot answer' hints at its unique analytical role. It does not explicitly name alternative tools or state exclusions, but the context is sufficient for 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?

The description adds behavioral context beyond the readOnly/idempotent annotations: it explains that every row links to its SEC filing, and that navigation to deeper tools is provided via next_tools. This gives the agent useful information about return format and workflow without contradicting 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 a single, highly informative sentence that front-loads the main directive 'START HERE'. It packs content types, return format details, and navigation guidance without unnecessary fluff. Every clause earns its place.

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

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

Despite having no output schema, the description provides a complete picture for an aggregator tool: it lists all included data categories, mentions that rows link to filings, and provides a path to more detailed tools. The absence of an output schema is compensated by this rich description.

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

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

Schema coverage is 100% with descriptions for both query and window_days. The description's phrase 'ticker or company name' reinforces the query parameter but does not add new meaning beyond the schema. Therefore, baseline 3 is appropriate; no extra param semantics are provided.

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

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

The description clearly states the tool's purpose: 'START HERE for any company question: one call returns the full insider picture for a ticker or company name'. It enumerates the specific types of information (13D/13G, Form 4, Form 144, 8-K) and distinguishes itself from sibling tools by positioning as the aggregator and mentioning 'next_tools names the tool for each deeper question'.

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?

Explicit usage guidance is given: 'START HERE' indicates this is the first tool to use. The phrase 'next_tools names the tool for each deeper question' points to alternatives and signals when more specific tools are appropriate. This effectively communicates when to use this tool versus 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?

Annotations already mark readOnly and idempotent; the description adds dynamic context like 'RIGHT NOW' and 'coverage deepens daily toward the backfill horizon,' revealing that data evolves over time. It also discloses the access tier component, adding value 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?

Two sentences, front-loaded with 'Orientation,' and every clause adds value: scope, temporal dynamics, access tier, examples, and when to use. No redundancies 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?

For a zero-parameter orientation tool with no output schema, the description fully covers purpose, content, and usage context. It also indirectly orients the user to sibling tools via 'example question per tool.'

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

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

With zero parameters, the baseline is 4. The description compensates by explaining what the tool returns (date ranges, access tier, example questions), which is sufficient given no schema to elaborate on.

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 is an orientation that reports live per-feed date ranges, access tier, and example questions per tool. It uses a distinct verb 'describe' and positions itself as a first-call tool, differentiating it from the data-query 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?

Explicitly instructs 'Call this first when unsure what to ask or whether a date range is covered,' providing direct when-to-use guidance and implying it should precede sibling queries. This is clear and actionable.

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 adds that it returns ranked candidates with name, ticker, and CIK, and lists accepted identifier formats beyond the schema examples. With readOnlyHint and idempotentHint annotations already present, this provides useful extra behavioral context without contradicting them.

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

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

Three concise sentences front-load the core purpose and input types, follow with output details, and end with usage guidance. 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 one-parameter tool with good annotations, the description fully covers what input is accepted, what output to expect, and when to use it. No additional information is needed for an agent to invoke it correctly.

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

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

The description extensively enriches the single parameter 'query' by listing all accepted formats (e.g., $NVDA, BRK.B, US ISIN) and explaining the resolution goal, going well beyond the schema's brief example.

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 'resolves any company identifier to its EDGAR identity' and enumerates the supported input types (ticker, name, CIK, ISIN, CUSIP), differentiating it from sibling tools that fetch specific filing or trading 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 explicitly says to use this tool when unsure of the exact ticker and before calling search tools, providing clear when-to-use guidance. It does not explicitly state when not to use it or name specific alternative tools, but the context is strong.

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 idempotentHint, so the agent knows it's a safe read operation. The description adds useful context about the data being normalized, the pre-computed value_usd, and the quote-ready summary with the SEC filing link, which are behavioral details 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?

Two sentences, front-loaded with the main verb and resource, and includes crucial output details. 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 tool has 10 parameters and no output schema. The description explains the core behavior and highlights key output fields, but it doesn't fully describe pagination or the interaction of filters. However, the parameter schema fills in these details, and the description gives enough context for an agent to understand what the tool returns.

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 10 parameters are documented in the schema. The description does not add parameter-specific semantics beyond the schema, but it does mention output fields (value_usd, summary) which are not parameters. 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 it searches normalized insider transactions from SEC Forms 3/4/5, with a specific verb ('Search') and resource. It also notes the output includes value_usd and a quote-ready summary. However, it does not explicitly differentiate from sibling tools like get_stakes or get_planned_sales, though the scope 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?

The description provides clear context about what it does, but does not give any guidance on when to use this tool versus alternatives such as get_stakes, get_planned_sales, or cluster_buys. There are no exclusions or preferred use cases stated.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: results are normalized to item codes and include SEC filing links. It doesn't mention pagination or rate limits, but that's partially covered by 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?

A single, information-dense sentence that front-loads the core purpose and provides useful examples without redundancy. Every phrase 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 moderate complexity (7 params, no output schema), the description plus the detailed schema covers the essentials. The mention of SEC filing links and event categories gives a good sense of the return payload, though fuller output details are absent.

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

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

Schema coverage is 100%, so the baseline is 3. The description itself repeats some item-code mappings that are already in the schema's item_codes description, and it doesn't add further semantic detail beyond what the schema provides.

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

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

The description uses a specific verb ('Search') and resource ('SEC 8-K material corporate events') with concrete examples (bankruptcies, restatements, officer departures, etc.). It clearly differentiates from sibling tools like get_insider_trades or get_stakes.

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 this is the tool for searching 8-K material events, with event-type examples. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for a non-exclusionary use case.

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 idempotentHint, so the description adds valuable domain-specific context: the data represents proposed, not yet executed, sales and includes broker and approximate sale date. This goes beyond the safety annotations and helps the agent understand the nature of the results. No contradiction 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 only two sentences and every clause earns its place: the SEC form type, the proposed nature, the before-execution timing, the leading-indicator framing, and the included fields. It is dense but immediately readable, with no redundant phrases.

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 search tool with 7 parameters but no output schema, the description provides the essential conceptual model (Form 144 vs Form 4) and a practical use case ('leading indicator'). It also mentions the return components (broker, approximate sale date). It doesn't enumerate all possible filters, but the schema already covers them, so the description is sufficiently complete for correct tool selection.

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

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

Schema description coverage is 100%, so all seven parameters are fully documented in the schema. The description does implicitly connect the 'approximate sale date' language to the since/until parameters, but it doesn't introduce any new parameter semantics beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the burden.

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 'Search' and names the exact resource ('SEC Form 144 notices'). It clearly distinguishes this tool from siblings like get_insider_trades by explaining that these are proposed sales filed before execution, whereas Form 4 reports execution afterward. This makes the purpose immediate and 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 clear usage context by explaining the proposed-sale timing and labeling the data as a 'leading indicator.' It implicitly tells the user when to choose this tool over executed-sale tools, but it doesn't explicitly name alternative sibling tools or list exclusions. The context alone is enough to infer appropriate 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 and idempotentHint, so the read-only nature is covered. The description adds meaningful behavioral context beyond annotations: what 13D vs 13G means (active vs passive intent), that only the latest filing per issuer/holder is returned, and that superseded history remains in the archive. This enriches the agent's understanding of result semantics.

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 purpose. The first sentence states the core function; the second adds critical context about the 13D/13G distinction and deduplication. 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?

With 8 parameters and no output schema, the description does not describe return format or pagination behavior. However, it explains the key behavioral semantics (dedup, filing types) that an agent needs to reason about results. The cursor parameter is self-documented in the schema, and the annotations cover safety. Slightly incomplete without output details, but adequate for a read-only search tool.

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

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

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by explaining the real-world meaning of the schedule_type enum values (13D=ACTIVE intent, 13G=passive), which clarifies how 'activist' and 'passive' map to filing types. This goes beyond the schema's enum labels.

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: searching 5%+ beneficial-ownership stakes from Schedules 13D/13G. It uses a specific verb ('Search') and resource ('ownership stakes'), and distinguishes itself from siblings by focusing on 13D/13G filings. This is a specific and well-scoped 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 description provides valuable context about the 13D/13G distinction and the 'latest filing wins' deduplication rule, implying when this tool is appropriate. However, it does not explicitly compare to alternative tools like get_insider_trades or list_recent_filings, nor state exclusions. The 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 and idempotentHint, so the bar is lower. The description adds genuinely useful behavioral context: output includes acceptance timestamps and SEC filing links, results are newest-first, and the scope is 'ALL feeds' – no filtering beyond what params specify. This goes beyond the baseline safety disclosure.

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 a compelling metaphor ('firehose'), and no filler. Every word contributes to understanding the tool's purpose, scope, and output.

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 no output schema, so the description must stand in for return expectations. It does: it names the key fields (acceptance timestamps, SEC links) and ordering. Combined with 100% parameter schema coverage and safety annotations, this is sufficiently complete for an agent to invoke correctly, though pagination semantics are only implied via the cursor parameter.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level semantics beyond the schema; phrases like 'ALL feeds' echo the feeds param default but add no new syntax, formats, or behavioral details.

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

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

The description clearly identifies a specific verb, resource, and scope: lists recently ingested filings across ALL feeds (Forms 3/4/5, 8-K, 144, Schedules 13D/13G) with acceptance timestamps and SEC filing links, newest first. It differentiates itself from sibling tools by using 'the firehose' and emphasizing 'ALL feeds'.

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?

Directly states 'Use to see what just came in', giving a clear situational trigger. It doesn't explicitly list alternatives or exclusions, but the implied contrast with more specific sibling tools (e.g., get_insider_trades) is evident from the emphasis on 'ALL feeds'.

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 read-only and idempotent behavior. The description goes further by disclosing the exact matching criteria (same CIK, 90-day window), the meaning of the status categories, and the key insight about expired notices with no sale. This is rich behavioral context beyond what annotations provide, and there is no contradiction.

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 dense, information-packed sentences. The opening phrase 'Cross-feed signal' immediately sets the tool apart. Every clause earns its place, 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?

For a complex cross-feed tool with no output schema, the description gives a solid conceptual overview, including what it surfaces (execution ratios, never-executed sales) and the matching logic. However, it does not describe the response structure or pagination details beyond the schema, and given the tool's complexity, a bit more about return format would complete the picture.

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 reinforces concepts like 'not_executed' and 'unverifiable', but it does not add syntax or format details beyond what the schema already provides. It adds narrative context but not parameter-specific 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 description uses a specific verb ('pair'), names the exact resources (Form 144 notices, Form 4 executions), and clearly states the output (execution ratios, announced-but-never-executed sales). It distinguishes itself from sibling tools by emphasizing the 'cross-feed' nature and that raw EDGAR cannot answer this in one query.

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 comparing planned vs executed insider sales) and provides context about the matching logic. However, it does not explicitly name alternative tools such as get_planned_sales or get_insider_trades, nor does it state 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.

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

Annotations already mark the tool as read-only and idempotent, so the description does not need to re-state safety. It adds meaningful context about the cross-feed join mechanics ('joins two feeds through the shared entity graph') and the limitation of raw EDGAR, giving insight into how the tool behaves 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 two sentences with no wasted words. The first sentence states the core purpose with a concrete example, and the second sentence explains the unique cross-feed advantage. 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?

The tool has 6 parameters (all optional) and no output schema. The description clearly explains the input context (material 8-K events and prior insider trades) and the output type (SEC Form 4 transactions), but it does not explicitly state the result structure (e.g., whether it returns event details alongside trades), which would have been helpful given no output schema. Still, it is largely complete for a filtering 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 all six parameters are well-documented in the schema. The description does not add any additional parameter-level semantics; it merely mentions the lookback window concept ('N days BEFORE') which is already captured by the 'days_before' parameter. This meets the baseline for schema-heavy tools.

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: show SEC Form 4 insider transactions before material 8-K events. It provides concrete examples (bankruptcy, restatement, delisting) and distinguishes itself from siblings by explicitly noting it joins two feeds, which raw EDGAR cannot do in one query.

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 this tool (for cross-feed insider-trades-before-events analysis) and implies it is the right choice over raw EDGAR for this specific query. However, it does not explicitly state when NOT to use it or name alternative sibling tools, so it lacks formal exclusions.

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