insidergraph

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

Annotations already establish readOnlyHint and idempotentHint, so the safety profile is covered. The description still adds substantive behavioral detail beyond the annotations: the precise buy filter (code P, acquisition, non-derivative, price > 0, not offset by same shares at same price) and the sort order (total value), which meaningfully define what the result set contains.

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

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

A single dense sentence with the tool's core purpose front-loaded and the parenthetical filter conditions compactly packed. Slightly heavy in one breath, but every clause earns its place by narrowing the result set.

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 describe what comes back; it only says results are 'sorted by total value' without naming returned fields (issuer, insider count, combined value, dates). Acceptable for a read-only filter tool but leaves a real gap on the return shape.

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 baseline is 3. The description's phrasing clarifies that the window operates on transaction dates and that insiders must be distinct, modestly reinforcing window_days and min_distinct_insiders, but it adds no format or range guidance beyond the schema.

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

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

The description states a precise verb+resource (find issuers with clustered insider open-market buys) and enumerates the exact qualifying conditions, making it clearly distinguishable from siblings like get_insider_trades or get_stakes. An agent can tell what output population this returns without opening the schema.

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

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

It supplies clear context for when this is the right tool: a derived signal ('a signal raw EDGAR cannot answer') that raw filing lookups cannot produce. However, it never names an alternative sibling or states an explicit when-not-to-use condition, so routing is inferred 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?

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. Beyond that, the description discloses the concrete response shape: filing-linked rows and a next_tools field that routes deeper questions — useful context an agent cannot get from the schema. It stops short of describing result limits or row-cap behavior.

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

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

Two dense sentences, front-loaded with the imperative 'START HERE', then the payload inventory. Every clause carries information; no filler or restatement of the name.

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

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

With no output schema, the description carries the return-value burden and does so: it names the four data categories and the filing-link/next_tools structure. Combined with annotations covering safety and a fully documented parameter schema, an agent has everything needed to call 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?

Schema description coverage is 100%, and the schema itself fully documents both parameters, including the precise definition of an open-market buy. The description only restates 'ticker or company name', which is narrower than the schema's broader identifier formats, so it adds little beyond the structured data. 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 states a specific verb and resource ('one call returns the full insider picture for a ticker or company name') and enumerates exactly what is aggregated: 13D/13G stakeholders, Form 4 activity, Form 144 sales, and 8-K events. It clearly distinguishes itself from the focused siblings (get_stakes, get_insider_trades, get_planned_sales, get_material_events) as the aggregating entry point.

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

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

'START HERE for any company question' gives an explicit, unambiguous invocation rule and frames the tool as the entry point before drilling down. It does not name the sibling alternatives directly (it delegates that to the response's next_tools field), so the routing is directional rather than enumerated.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: the data reflects live, changing coverage ('RIGHT NOW', 'coverage deepens daily toward the backfill horizon') and includes access-tier information. This helps the agent understand the dynamic nature of the response.

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

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

The description is two sentences with no filler. The first sentence front-loads the tool's purpose and what it returns; the second gives direct invocation guidance. 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?

For a zero-parameter orientation tool with no output schema, the description sufficiently covers what the agent will receive: per-feed live date ranges, access tier, and example questions per tool. It also tells the agent when to call it, making the description complete for 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?

The tool has zero parameters and the schema already describes an empty object. No parameter-level documentation is needed, so the description correctly focuses on output content and usage context rather than input 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 states a clear verb-resource pair: 'describe coverage' of the server's per-feed date ranges, access tier, and example questions per tool. It also positions itself as an orientation tool distinct from the domain-specific sibling tools, so an agent can easily tell them apart.

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 explicit guidance: 'Call this first when unsure what to ask or whether a date range is covered.' This establishes clear usage context, though it does not enumerate when-not-to-use alternatives.

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

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

Annotations already indicate readOnlyHint and idempotentHint, so safety is covered. The description adds value by explaining the output behavior: it returns 'ranked candidates with name, ticker, and CIK,' which tells the agent to expect potential ambiguity and ranked resolution.

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

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

The description is two sentences, front-loaded with the primary action and scope, and every sentence earns its place. The usage guidance is appended naturally 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?

With only one parameter, clear annotations, and no output schema, the description covers the essential context: what the tool does, what inputs it accepts, and what the return looks like. An agent has enough information to select and 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?

Schema description coverage is 100% and the schema already gives examples, but the description adds meaningful context by listing the full range of accepted formats: ticker variants, company name, CIK, ISIN, and CUSIP. This helps the agent understand what kinds of strings are valid inputs.

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

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

The description names a specific verb ('Resolve'), a specific resource ('any company identifier to its EDGAR identity'), and enumerates the accepted input formats. This clearly distinguishes the tool from its siblings and leaves no doubt about its core function.

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

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

The description explicitly tells the agent when to use the tool: 'when unsure of the exact ticker before calling the search tools.' It provides clear context and timing, though it does not name specific sibling tools or state 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 cover safety (readOnlyHint, idempotentHint), and the description goes further by disclosing the return shape: value_usd is pre-computed and summary is quote-ready with the filing link. The footnote_level explanation ('transaction' vs 'filing') is genuinely useful behavioral context that exists nowhere else since there is no output schema.

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

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

Front-loaded with the core purpose in the first clause, then return-value context, then the footnote semantics. Three sentences with no filler. The final footnote_level sentence is dense and slightly harder to parse but earns its place given no output schema.

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

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

For a 12-parameter search tool with full schema coverage and no output schema, the description covers the operation, key derived return fields, and a non-obvious response field's semantics. It omits pagination behavior and a fuller return-shape description, but is adequate overall.

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 12 parameters including the non-obvious txn_type/txn_codes interaction and the exclude_10b5_1 default. The description adds essentially no parameter meaning beyond that, which is the correct baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Search normalized insider transactions from SEC Forms 3/4/5 (US public companies)'. This is clearly the raw-filing search tool in a cluster of derived-analysis siblings (cluster_buys, planned_vs_executed, trades_before_events), but the description never names those siblings to make the boundary explicit.

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 when-to-use or when-not-to-use guidance is provided. With ten siblings including several that analyze the same underlying trades (trades_before_events, cluster_buys, get_planned_sales), the description gives an agent nothing to route on beyond the operation name.

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 about normalization to item codes and SEC filing links, but it does not disclose result shape, coverage limits, or pagination behavior beyond what the cursor schema implies.

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

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

One dense sentence that front-loads the core purpose, lists representative event types, and notes the two key output characteristics (normalization and SEC links). There is no wasted text.

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

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

Given the detailed input schema, read-only annotations, and mention of SEC filing links, the description is largely sufficient for invoking the tool correctly. The main gap is the lack of an explicit return-structure description, though the cursor parameter's schema hints at a page.next_cursor response field.

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 input schema already documents all seven parameters and their meanings. The description's mention of item codes aligns with the item_codes parameter but adds little beyond the schema's existing enum explanations.

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

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

The description uses a specific verb and resource ('Search SEC 8-K material corporate events') and enriches it with concrete examples (bankruptcies, restatements, officer departures, cyber incidents). It does not explicitly contrast against siblings like list_recent_filings or get_insider_trades, but the scope is specific enough that an agent can infer the domain.

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

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

No guidance is given about when to use this tool versus alternatives, nor are exclusions or preferred conditions stated. The sibling tools cover related data like insider trades and filings, so an explicit routing hint would materially help; without it, the agent must rely on inference.

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 idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it explains the filing timing (before execution), the regulatory source (SEC Form 144), and the interpretation as a leading indicator. This is substantive and helps the agent understand what the data represents 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 two sentences with no filler. The core action and key differentiator ('filed BEFORE the sale executes') are front-loaded, and the leading-indicator framing adds value without redundancy. 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 read-only search tool with 7 optional, well-documented parameters and no output schema, the description covers the domain concept and expected output hints (broker, approximate sale date). It does not explain pagination or return shape, but the schema documents the cursor and the annotations cover safety. Minor gaps remain around result ordering and field availability, but overall it is complete enough for 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?

The input schema already provides full descriptions for all 7 parameters (100% coverage), including the approximate sale date semantics for 'since' and 'until.' The description does not add additional parameter-specific details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Search SEC Form 144 notices') and identifies the exact resource and filing type. It clearly distinguishes this tool from Form 4-based insider trade tools by emphasizing 'PROPOSED sales... filed BEFORE the sale executes' and calling it a 'leading indicator.' This is unambiguous and differentiated from siblings like get_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 gives clear context for when to use this tool: for announced-but-not-yet-executed insider selling, as opposed to Form 4 execution data. It does not explicitly name alternative sibling tools, but the contrast with Form 4 implicitly guides the agent away from executed-trade tools. No explicit when-not-to-use list is provided, 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?

Annotations already declare readOnlyHint and idempotentHint, and the description adds significant behavioral context: 'Latest filing per (issuer, holder) wins, so results are current stakes; superseded history stays in the archive.' It also flags 13D as potentially market-moving, which helps interpret 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?

Three terse sentences front-load the core purpose and then deliver the two most decision-relevant behavioral facts. Every clause earns its place with no filler or 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 search tool with a fully self-documenting schema and no required parameters, the description covers the domain-specific meaning that structured fields cannot: the 13D vs 13G distinction, the 5% threshold, and latest-filing-wins semantics. It could be slightly richer about output shape or explicit alternatives, but nothing essential for invoking the tool 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by decoding 13D vs 13G in terms of activist/passive intent and by clarifying that results reflect the latest filing per (issuer, holder). This enriches schedule_type and the overall result interpretation.

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

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

States a specific verb ('Search'), a concrete resource ('5%+ beneficial-ownership stakes'), and a precise source ('Schedules 13D/13G'). The 13D/13G distinction and latest-filing-wins rule clearly differentiate it from siblings like get_insider_trades and list_recent_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?

Provides clear context by explaining that 13D represents active/activist intent and 13G represents passive ownership, which directly informs schedule_type usage. It does not explicitly name sibling alternatives or give 'use this instead of X' guidance, so it stops short of full routing support.

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

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

With readOnlyHint and idempotentHint already present, the description adds ordering ('newest first'), content ('acceptance timestamps and SEC filing links'), and recency semantics ('recently ingested'). It does not discuss pagination or response shape in depth, but the schema already documents cursor-based 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?

Two tight sentences: the core scope, content, and ordering are front-loaded, and the usage hint is one short clause. There is 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 read-only listing with fully documented optional parameters, the description provides sufficient return expectations by mentioning timestamps, links, and newest-first ordering. No output schema exists, so this description-level return info is valuable; pagination mechanics are handled by the cursor parameter schema.

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

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

Schema description coverage is 100%, so the schema already explains feeds, limit, since, and cursor with defaults and format hints. The description adds no parameter semantics, but the baseline of 3 is appropriate when the schema carries full parameter documentation.

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

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

States it lists recently ingested filings across all feeds with acceptance timestamps and SEC filing links, newest first. The verb 'list' and resource are explicit, and the firehose framing plus enumeration of form types separates it from type-specific siblings like get_insider_trades or get_material_events.

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 closing sentence 'Use to see what just came in' gives clear context: this is for recency monitoring across all feeds. It does not explicitly name alternatives or exclusions, but the 'ALL feeds' scope implies more targeted tools exist for specific feeds or filing types.

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 idempotentHint, so safety is covered. The description adds meaningful behavioral context: exact-CIK identity matching, the 90-day Rule 144 validity window, and the treatment of unverifiable sellers via trusts/foundations. It does not describe output shape, but the matching semantics are 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?

Three dense sentences lead with the core cross-feed signal, then explain the matching logic, and end with a differentiating, value-adding remark. No filler; 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 8 fully documented parameters and read-only/idempotent annotations, the description covers the key operational logic and the main analytical use case. It does not specify exact response fields, but no output schema exists and the description still conveys what results will surface (execution ratios and non-executed notices), which is sufficient for selection and 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 description coverage is 100%, so the baseline is 3 and the description does not need to compensate. It reinforces the status concept by explaining the not_executed signal, but it does not add parameter-level syntax, formatting, or constraints beyond what the schema already provides.

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

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

The description names a concrete analytic operation: pairing Form 144 notices with Form 4 executions by exact CIK identity inside the 90-day Rule 144 window. It also highlights the distinctive 'announced-but-never-executed' signal, making it easy to differentiate from siblings like get_planned_sales or get_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?

It clearly implies when to use the tool: when the agent needs execution ratios or expired-notice/no-sale residue, and it notes that raw EDGAR cannot answer this in a single query. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe-read profile is covered. The description adds that it joins two feeds via a shared entity graph and that raw EDGAR cannot replicate it in one query, which is useful context, but it says nothing about return format, pagination, or rate limits.

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

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

Two sentences, front-loaded with the core mechanism, followed by a concrete example and the differentiator. 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?

For a cross-feed join tool with read-only annotations and full schema coverage, the description conveys the concept and result type well. No output schema exists, and it does not describe the shape of returned rows, which is a minor gap for a join tool.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the txn_type logic and item-code defaults. The description only loosely maps 'N days BEFORE the event' to days_before and 'insider selling' to the default txn_type, adding little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (show), resource (SEC Form 4 insider transactions), and scope (in the N days BEFORE an issuer's material 8-K event). This clearly distinguishes it from siblings like get_insider_trades or get_material_events, which cover only one feed each.

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?

Gives a clear use context with concrete examples ('insider selling before a bankruptcy, restatement, or delisting') and notes raw EDGAR cannot answer this in one query, implying when the cross-feed join is warranted. It does not explicitly name sibling alternatives to steer away from, 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.