insidergraph

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 meaningful behavioral detail: eligibility is restricted to code P, insiders must be distinct, there is a lookback window, and results are sorted by total value. This is useful context beyond what annotations provide.

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 tight sentence that front-loads the core action and criteria, and it wastes no words. It clearly states what the tool does, why it matters, and how results are ordered.

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 tool with moderate complexity and fully documented optional parameters, the description covers the essential behavior and output ordering. The absence of an output schema leaves the return shape somewhat unspecified, but this does not prevent 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?

All three parameters are already documented in the schema with 100% coverage, so the baseline applies. The description echoes the concepts of window, distinct insiders, and total value but adds no new parameter-level meaning beyond the schema.

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

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

The description clearly states the verb and resource: find issuers where multiple distinct insiders independently bought with code P in a window. It also distinguishes itself from raw EDGAR trade data by framing the output as an analytical signal, which separates it from sibling tools 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 implies this tool is for cluster-buy signal detection rather than raw trade lookup, but it never explicitly names an alternative or states when not to use it. The 'raw EDGAR cannot answer' phrase provides context but leaves routing to 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 and idempotentHint, so no safety concern needs repeating. The description adds valuable behavioral context beyond annotations: it aggregates multiple filing types, returns rows that link to SEC filings, and provides next_tools for follow-up. This helps an agent know what to expect from the call.

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 with 'START HERE,' then efficiently lists the contained data categories and the row-link behavior. No sentence is wasted; each adds selection or invocation value.

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

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

For a 2-parameter read-only aggregation tool with no output schema, the description is complete enough. It tells the agent what data comes back, that rows link to filings, and how to proceed for deeper questions. The schema covers input parameters, so nothing essential 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 description coverage is 100%, so the schema fully documents query and window_days. The description adds little parameter-level meaning beyond mentioning 'ticker or company name,' which is already in the schema. The baseline of 3 applies because structured fields carry the parameter 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 clearly states a specific verb and resource: one call returns the full insider picture for a ticker or company name, enumerating 13D/13G, Form 4, Form 144, and 8-K data. It also distinguishes itself from sibling tools by explicitly presenting itself as the starting point and noting that deeper questions are routed via next_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 routing guidance: use this as the START HERE tool for any company question and follow next_tools for deeper dives. It does not explicitly name alternatives or state when not to use it, but the entry-point framing is a strong usage signal.

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 already mark the tool read-only and idempotent, so the description does not need to restate safety. It adds useful behavioral detail about normalized data, pre-computed value_usd, a quote-ready summary string, and the SEC filing link, which goes beyond the structured 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 carry the essential information with no filler. The primary action is front-loaded, and the additional return-value detail is concise and directly useful.

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 supplies a reasonable summary of return content, including value_usd and the quote-ready string with filing link. It does not enumerate all returned fields or mention default ordering, but the complete parameter schema and read-only annotations cover most invocation needs.

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 coverage is 100%, so every parameter is already documented with descriptions and enums. The description adds no parameter-specific meaning beyond mentioning value_usd, but it does not need to compensate because the schema is complete.

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 searches normalized insider transactions from SEC Forms 3/4/5, which is a specific verb and resource. It does not explicitly contrast itself with sibling tools like get_planned_sales or cluster_buys, but the resource is specific enough for most agents to distinguish it.

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

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

The description provides no guidance on when to prefer this tool over alternatives such as get_planned_sales or trades_before_events. There is no mention of exclusions, complementary tools, or context where this search is the right choice, leaving selection entirely to 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 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 description does not need to restate safety. It adds useful behavioral context beyond annotations: the tool joins two feeds through the shared entity graph and performs a temporal before-event lookup. This is transparent about the underlying mechanism without contradicting the annotations.

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

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

The description is two sentences with no filler. The main purpose and unique value proposition are front-loaded in the first sentence, and the second sentence clarifies why this tool is distinct from a raw EDGAR query. Every part 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 cross-feed query tool with no output schema, the description explains the core behavior and the key limitation (raw EDGAR cannot answer it). It could mention return shape or coverage dependencies, but for selection and invocation the schema and annotations cover the necessary details. Slight gap regarding output expectations keeps it from a 5.

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

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

The schema provides 100% description coverage for all six parameters, so the description does not need to explain each parameter. It does reinforce the meaning of key concepts like 'N days BEFORE' and 'material 8-K event', but adds no semantic detail beyond what the schema already provides. 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 ('show') and resource (SEC Form 4 insider transactions before material 8-K events), with concrete examples like bankruptcy, restatement, and delisting. It also clearly distinguishes itself from sibling tools by emphasizing the cross-feed join that raw EDGAR cannot answer 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: when the user needs insider transactions occurring shortly before a company files a material 8-K event. It does not explicitly name alternatives or state when not to use it, but the cross-feed framing and siblings list make the intended use fairly evident.

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