insidergraph

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

Annotations indicate readOnly and idempotent behavior. The description adds that results are sorted by total value and filtered by code P (open market purchases), which is useful behavioral context 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 purpose, no filler. Efficient and scannable.

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

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

The description explains the core logic and sorting, which is adequate for a simple list tool. Lack of output schema is compensated by the clear purpose. Sibling differentiation could be stronger.

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 parameters are already described. The description adds context like 'with their own money (code P)' and 'multiple distinct insiders independently bought', which enhances semantic understanding 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 tool finds issuers with multiple distinct insiders making independent open market purchases within a window, distinguishing it from raw EDGAR data and sibling tools like search_insider_trades. It uses a specific verb and resource.

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

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

The description implies usage for detecting cluster buying signals and notes it's something EDGAR cannot provide, but doesn't explicitly state when to use versus alternatives or when not to use. Sibling tools like search_insider_trades serve different purposes but are not mentioned.

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

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

Annotations already provide readOnly and idempotent hints. Description adds context about the comprehensive output (SEC links, multiple filing types) 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?

Two sentences with no filler. First sentence delivers core purpose and outputs; second adds linking and navigation hints. Efficient and front-loaded.

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

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

Given the complex sibling ecosystem (11 tools), description adequately positions this as the starting point. Lists key outputs, which compensates for lack of output schema. No mention of pagination or limits, but likely not needed.

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 covers both parameters fully. Description adds value by specifying accepted identifier formats (e.g., $NVDA, BRK.B) and clarifying window_days default. Adds some context beyond 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?

Description uses 'START HERE' and 'full insider picture' to clearly state the tool's purpose. It lists specific resources (stakeholders, insider activity, events) and distinguishes itself from siblings by positioning as the 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?

Explicitly says 'START HERE for any company question', guiding when to use it. Notes that 'drill_down names the tool for each deeper question', providing clear alternatives among 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 declare readOnlyHint and idempotentHint true, so the tool is safe and idempotent. The description adds behavioral context by explaining that coverage deepens daily, which is dynamic, and that it provides an example question per tool. No contradictions 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 extremely concise, consisting of two sentences that are front-loaded with an 'Orientation:' label and an imperative call to action. Every word adds value, with no redundant or unnecessary information.

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 that the tool has no parameters and no output schema, the description is complete. It explains what the tool returns (per-feed date ranges, access tier, example question) and when to use it. No further context is needed for this simple introductory 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?

The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, and it correctly omits them.

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: to provide coverage information, access tier, and example questions for each tool. It uses specific language ('per-feed live date ranges', 'your access tier') and distinguishes itself from sibling tools by being an orientation tool to call first.

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 says 'Call this first when unsure what to ask or whether a date range is covered,' which provides clear guidance on when to use it. However, it does not explicitly state when not to use it or mention specific alternatives, though the sibling tools list indirectly provides context.

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 note readOnlyHint and idempotentHint. The description adds that it returns 'ranked candidates with name, ticker, and CIK', providing behavioral context. No contradictions 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 dense sentences: function, inputs, usage. No redundancy. Front-loaded with the core action. Every sentence adds 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 simple resolution tool with one parameter, high schema coverage, and annotations, the description fully explains input types, output structure (ranked candidates), and usage context. No output schema needed.

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

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

Schema coverage is 100% and the description enriches the parameter meaning by listing specific examples (e.g., 'AAPL', 'NASDAQ:AAPL', '1045810'), which goes beyond the schema's generic description.

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: 'Resolve any company identifier to its EDGAR identity'. It lists supported identifier formats (ticker, name, CIK, ISIN, CUSIP) and distinguishes from siblings by framing it as a preliminary step before search 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 explicitly advises when to use: 'Use it when unsure of the exact ticker before calling the search tools.' This implies when not to use (if ticker is known) and references sibling tools to differentiate.

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 declare readOnlyHint and idempotentHint, so description adds little behavioral context beyond mentioning acceptance timestamps and links. No mention of pagination behavior, rate limits, or data freshness. Scores baseline with annotations present.

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 key concept 'firehose', no filler. Efficient and well-structured.

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?

No output schema, so description should cover response format. It mentions timestamps and links but not full fields. Pagination is implied via cursor param but not explained. Adequate for a simple list but could be more complete.

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

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

Schema coverage is 100% with full parameter descriptions. The description only paraphrases the feeds parameter as 'across ALL feeds'. Baseline 3 when schema already documents parameters well.

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

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

Description clearly states it is a firehose for recently ingested filings across all feeds with acceptance timestamps and SEC filing links, ordered newest first. It distinguishes from sibling tools like search_insider_trades by being a broad, unfiltered stream.

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?

Says 'Use to see what just came in.' Gives no explicit when-not-to-use or alternatives. For an AI agent, this is adequate but lacks guidance on choosing this over more specific search tools.

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 declare readOnlyHint=true and idempotentHint=true. The description adds meaningful behavioral context: it describes the matching logic (same person, CIK, 90-day window) and outputs (execution ratios, announced-but-never-executed sales). This goes beyond the annotations without 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?

The description is a single concise paragraph that front-loads the main purpose. It contains no redundant information and every sentence adds value. However, it could be slightly better structured for readability, but overall it is efficient.

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

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

Given the tool's complexity (8 parameters, no output schema), the description provides the core concept and hints at output (execution ratios, announced-but-never-executed sales). However, it lacks details on pagination, default ordering, or the structure of the response. This leaves gaps for an agent to fully understand the output format.

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 does not add additional meaning to the parameters beyond what the schema already provides. Each parameter is well-documented in the schema with clear descriptions, and the tool description focuses on the overall function rather than parameter 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 states the tool's purpose: 'pair each Form 144 notice ... with the seller's actual Form 4 sale executions'. It specifies the resource (insider sales notifications vs executions), the verb (pair/match), and unique value (surfaces execution ratios and announced-but-never-executed sales). Differentiates from siblings by noting '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 provides clear context on what the tool does (matching notices to executions) and implies usage for checking if planned sales were executed. However, it does not explicitly state when to use this tool versus alternatives like search_planned_sales or search_insider_trades, nor does it include exclusions or when-not scenarios.

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 value by disclosing the return format (pre-computed value_usd and a quote-ready summary with SEC link). It does not contradict annotations and provides behavioral context beyond 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?

The description is two sentences with no wasted words. It is front-loaded with the purpose and then the output details. Every sentence serves a clear function.

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 10 parameters, no output schema, and a variety of sibling tools, the description omits important context like pagination behavior, default sorting, and differentiation from similar tools. The schema descriptions are thorough, but the description could be more complete in guiding use.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add further parameter semantics beyond what the schema already provides (e.g., txn_type enum, insider substring match). It does not need to repeat schema details, but it also doesn't enhance understanding of parameters.

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, specifying the data source and output format (value_usd and summary with link). It avoids tautology and is specific about the resource and action, though it does not explicitly distinguish from sibling 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 provides no guidance on when to use this tool versus its siblings (e.g., cluster_buys, planned_vs_executed). It only states what it does, leaving the agent to infer when it's appropriate. This is a significant gap given the presence of multiple similarly named tools.

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 safety is clear. Description adds value by specifying that events are normalized to item codes and that results include SEC filing links. It discloses the scope of event types but could mention pagination behavior or data freshness.

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

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

Description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose, scope, and key features (normalized to item codes, SEC filing links).

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 (all covered by schema) and no output schema, the description is mostly adequate. It mentions SEC filing links but does not describe the full response structure. Pagination via cursor is documented in schema but not in description. Overall, sufficiently complete for typical use.

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

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

Schema description coverage is 100%, so each parameter already has clear documentation. The tool description lists event types but those are also detailed in the schema for 'item_codes'. It does not add new meaning beyond what the schema provides, hence baseline 3.

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

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

Description clearly states the verb 'Search' and resource 'SEC 8-K material corporate events', listing specific event types (bankruptcies, restatements, etc.). It distinguishes from siblings like 'list_recent_filings' and 'search_insider_trades' by focusing on 8-K material events with normalized item codes and SEC filing links.

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

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

Description implies usage for searching 8-K material events but does not explicitly state when to use this tool vs alternatives like 'list_recent_filings' or 'planned_vs_executed'. No exclusions or context-specific recommendations are provided.

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

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

Annotations mark it as read-only and idempotent. The description adds that it searches Form 144 (filed before execution) and describes the data as a leading indicator. It does not contradict annotations and provides useful behavioral context, though it could mention 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?

The description is two concise sentences with no redundant information. The first sentence clearly defines the tool's purpose, and the second adds important context about its leading indicator nature.

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 7 optional parameters and no output schema, the description explains the data source and nature well. It lacks details on returned fields, which the output schema would provide, but overall it is sufficiently complete for a 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?

Schema coverage is 100%, so the description adds no additional parameter meaning. The description mentions 'broker and approximate sale date' but these are not explicit parameters, nor does it clarify parameter usage beyond the schema. 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?

The description specifies searching SEC Form 144 notices for proposed insider sales, clearly distinguishing it from Form 4 filings for executed sales. The verb 'search' and resource 'SEC Form 144 notices' are specific, and the context implies it differs from sibling tools like 'search_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 states it covers proposed sales before execution, making it appropriate for leading indicator analysis. It does not explicitly mention when not to use it or name alternatives, but the context of planned versus executed sales is clear.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral details: the deduplication logic (latest filing per issuer-holder pair) and that superseded history stays in the archive. This goes 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 extremely concise: two sentences with no unnecessary words. The first sentence states the core purpose, and the second provides critical behavioral context. Every sentence earns its place.

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

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

Given the 8 optional parameters, no output schema, and high schema coverage, the description sufficiently explains the core functionality and deduplication. It could mention pagination briefly, but the cursor parameter is well-described in the schema. Overall, it provides enough context for effective use.

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

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

All 8 parameters have descriptions in the input schema (100% coverage). The description adds context for the schedule_type parameter, clarifying that 'activist' corresponds to 13D family and 'passive' to 13G family, which adds value beyond the schema's enum values.

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

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

The description clearly states the tool searches for 5%+ beneficial-ownership stakes from Schedules 13D/13G, distinguishing between active (13D) and passive (13G) intent. This purpose is distinct from sibling tools like search_insider_trades or search_material_events, making it easy for an agent to select the right tool.

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

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

The description explains the difference between 13D and 13G and mentions that the latest filing per issuer-holder pair wins, providing context on when to use each. However, it does not explicitly state when not to use this tool or directly compare it to alternatives, though the sibling tool names imply other use cases.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by disclosing that it joins two feeds and that raw EDGAR cannot perform this in one query, providing behavioral context beyond the annotations.

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

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

The description is two sentences with no fluff. The first sentence focuses on purpose and examples, the second adds technical context (feed join, limitation). Every sentence serves a purpose.

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

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

Given the tool has 6 optional parameters, no output schema, and annotations, the description is fairly complete. It explains the cross-feed nature, use case, and limitation. It could mention the return format (insider transactions) but already says 'show SEC Form 4 insider transactions'.

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 references the days_before parameter ('N days BEFORE') but does not significantly elaborate beyond the schema descriptions. No parameter-specific details are added that the schema already lacks.

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 ('show') and resource ('SEC Form 4 insider transactions before material 8-K events'). It distinguishes itself from siblings by being a cross-feed signal that raw EDGAR cannot answer in one query, and provides concrete examples (bankruptcy, restatement, delisting).

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 (before events like bankruptcy) and implies it is for joining insider trades and events, but does not explicitly state when not to use or list alternative sibling tools such as search_insider_trades or search_material_events.

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