SEC EDGAR Fundamentals

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

With no annotations provided, the description carries the full burden. It discloses the return fields and mentions pricing at /.well-known/x402, but does not describe error handling for invalid tickers, rate limits, authentication requirements, or any side effects. Useful context, but significant behavioral details remain uncovered.

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 somewhat long with a comprehensive list of use cases, but every sentence adds relevant information. It is front-loaded with the core action and return values, and the pricing note is a useful contextual detail. Minor redundancy in the list of return items, but overall 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?

For a single-parameter tool with no output schema, the description thoroughly covers the return values (CIK, registrant name, SIC code and description, exchanges, fiscal year end) and provides clear context for when to use it. It does not address invalid-ticker behavior or other edge cases, but the tool is simple enough that this is a minor gap.

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

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

Schema description coverage is 100%, and the schema already documents the ticker parameter format (case-insensitive, pattern, max length). The tool description adds no additional semantic meaning beyond what the schema provides, so the baseline of 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 clearly states the tool resolves an exchange ticker to its SEC filer and returns specific reference data (CIK, registrant name, SIC code and description, exchanges, fiscal year end). It uses a specific verb-resource pair and is easily distinguished from sibling tools like get_financials or list_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?

The description explicitly enumerates use cases ('confirm a ticker is a real SEC filer', 'resolve it to a CIK', 'establish industry or sector context', 'choose peers', 'learn a filer's fiscal calendar') and positions itself as 'reach for this first'. It lacks explicit exclusions or alternative tool references, so it does not fully meet the 'when-not' criterion.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It discloses the key alignment mechanism ('fiscal calendars end in different months still line up period by period'), the exact return shape ('one row per ticker carrying the aligned period values and the resolved XBRL tag'), and error behavior ('a per-row error for any ticker that fails to resolve or has never reported the metric'). It even points to pricing docs. This is comprehensive and exceeds the typical transparency level.

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 dense paragraph that front-loads the core purpose and follows with usage guidance, behavior, return format, and a pricing pointer. Every sentence adds value, and it avoids redundancy with the schema. The structure is efficient for its complexity.

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 (multi-company comparison with fiscal calendar alignment), the description fully compensates for the lack of an output schema by explaining the aligned periods, return row structure, and error handling. It also provides clear usage context and a pointer to pricing. Contextual completeness is high, and no important aspect seems 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?

The input schema provides 100% coverage with detailed descriptions for all parameters: limit, metric, period, and tickers. The tool description reinforces the 'one metric per call' rule but does not add new parameter-level semantics beyond what the schema already states. Thus, per the baseline for high schema coverage, a 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 clearly states the tool's function: 'Compares one normalized metric across several filers in a single call' with aligned reporting periods. It is specific about the resource (multiple filers), the action (compare one metric), and the scope (two to eight tickers), effectively distinguishing it from sibling tools like get_financials.

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 explicit usage context: 'Use it for peer, competitor or ranking questions' and 'where the same figure is wanted for two to eight tickers.' It also states a key constraint: 'Exactly one metric per call' and advises to 'ask again per metric if you need more.' However, it does not name specific alternative tools or explicitly state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses newest-first ordering, that results include the upstream tag and taxonomy actually resolved, and the caveat about comparing series across companies. It does not cover error behavior or rate limits, but the core behavioral traits are well explained.

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

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

The description is dense and well-structured: output description, usage guidance, behavioral nuance, and pricing link. It is slightly long with em-dash clauses, but every sentence contributes value 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?

Without an output schema, the description fully explains what is returned (value, unit, period start/end, filing, tag, taxonomy), the ordering, and the importance of the resolved tag. It also references pricing. This covers all essential context for an agent to decide and correctly invoke the tool.

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

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

Schema description coverage is 100% and the schema already fully documents parameters. The description adds examples like 'revenue, net_income or assets' and mentions 'limit' indirectly through history depth, but does not provide substantial parameter-level meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns a reported time series for a single normalized metric from one company's XBRL facts, with concrete examples (revenue, net_income, assets) and details on included fields. It distinguishes itself from siblings by emphasizing 'one figure rather than a whole statement'.

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 states when to use: 'when a question is about the history, trend or growth of one figure' or 'when you must reconcile a number against the filing it was tagged in.' It contrasts with 'a whole statement' but does not name specific alternative tools, 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?

Despite no annotations, the description discloses ordering ('newest first'), provenance ('upstream XBRL tag'), and handling of unreported metrics ('list of metrics this filer never reported'). It also mentions pricing. This is ample behavioral context for a read-only data tool.

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

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

The description is a single long sentence with many clauses, including an extraneous pricing pointer at the end. Although informative, it is less concise than it could be; it could be split into shorter sentences. It is not structured with bullets.

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 covers the returned record structure, metric list, ordering, traceability to XBRL, and unreported metrics, which is substantial given no output schema. It also includes usage context. It is missing explicit error handling or examples, but overall is quite complete for a retrieval 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 descriptions cover all parameters fully (100% coverage). The description adds little beyond naming some metrics, but the schema already explains ticker, period, limit, and metrics with defaults and constraints. Thus the description provides marginal additional semantic value, so score 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?

The description clearly states it provides 'normalized financial statement view for one company across recent fiscal periods' and enumerates the metrics and derived ratios included. It explicitly contrasts with 'the history of one figure,' distinguishing it from the get_concept sibling.

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 instructs: 'Reach for this by default when a question is about a company's performance, profitability or margins over annual or quarterly periods rather than the history of one figure.' This provides clear when-to-use guidance and references an alternative type of tool.

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

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

With no annotations, the description carries full disclosure burden and succeeds: it states the realized ledger counts open-market sales only, itemizes exclusions, says no market data/estimated wealth is provided, reports share counts as filed, and explains that candidate CIKs are never merged.

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?

Long but dense and front-loaded with the core promise. Most sentences add distinct value, though some stylistic elaborations and the pricing link are not strictly necessary for tool invocation.

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

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

There is no output schema, but the description compensates well by enumerating the return domains and exclusions. It stops short of describing exact response structure/field names, which would be needed for a perfect score.

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 baseline is 3. The description reinforces parameter meanings but adds little beyond the already-rich schema descriptions for owner_cik, name, and window_days; schema text for window_days, for example, is actually more specific about liquidity signals and lifetime ledger behavior.

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 opens with a concrete function: returning everything the corpus holds about one person. It enumerates content (name spellings, issuers, roles, position series, realized ledger) and explicitly contrasts 'returns one person, not a list of transactions', distinguishing it from sibling list/activity 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?

Gives explicit when-to-use guidance: 'Reach for it when the subject of the question is an individual' and explains the name-vs-cik decision path. It does not name sibling alternatives directly, but the individual-vs-issuer/company framing makes the intended scope 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key traits: one row per filed row, direction read from the filing's own flag rather than inferred from the code, inclusion of filing-stated values and Rule 10b5-1 status, newest-first ordering, and the lag between trades and filings. This goes well beyond a simple read/write label.

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

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

The description is dense but every sentence earns its place: main behavior, return-row semantics, example use cases, sibling routing, data-latency caveat, and pricing pointer. Despite its length, it front-loads the most decision-relevant facts and avoids repetition 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?

With no output schema, the description explains what each returned row carries: transaction code with plain-language meaning, direction, shares, value, position after, and 10b5-1 status. It also covers ordering, filing lag, filter options, and pricing, leaving no major gap an agent would need to guess about when selecting or invoking the tool.

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

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

Schema description coverage is 100%, so the schema already fully documents each parameter's meaning, defaults, and constraints. The description adds contextual framing about narrowing the read 'before it is paid for' and the distinction between transaction date and filing date, but it does not add new parameter-level meaning beyond the schema's own detailed descriptions.

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 starts with a clear, specific statement: 'Every Form 3, 4 and 5 row filed against one company — identified by ticker — by its directors, officers and ten-percent owners.' It explicitly names the resource (one company's insider transactions), conveys the verb (returns/list), and distinguishes itself from siblings like screen_insider_transactions and screen_insiders.

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 usage guidance: 'Reach for this when the question is about one company' and names the alternatives with conditions: 'For the same question across every issuer at once use screen_insider_transactions; for one row per person with the totals already rolled up use screen_insiders.' It also explains when filters are appropriate and that rows trail trades due to filing deadlines.

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

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

With no annotations, the description carries the full burden and handles it well: no arguments, no filtering, fixed cap, ordering, and data-freshness semantics ('a Form 4 is filed within two business days of its transaction'). It also discloses the pricing pointer, which is useful context beyond the schema.

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

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

The description is dense but every sentence earns its place: scope, ordering, cap, no-args rationale, sibling routing, filing-latency context, and pricing. It is front-loaded with the core behavior and contains no filler.

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

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

For a zero-argument tool with no annotations and no output schema, the description covers what it does, why it exists, when to use alternatives, the response cap, and freshness semantics. An agent has enough to select and invoke it correctly without further context.

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

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

The input schema already documents zero parameters, and the description reinforces that this is deliberate: 'no filter, no paging, no way to ask for more'. For a 0-parameter tool, this exceeds the baseline by explaining why the absence of arguments is intentional.

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 exactly what the tool returns: 'most recently filed Form 3, 4 and 5 rows in the corpus... newest filing first, capped'. It also explicitly distinguishes itself from filtered sibling tools by saying 'Every filter is on another tool' and naming them.

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 that the tool has 'no filter, no paging, no way to ask for more', establishing it as a quick live-corpus probe rather than a query tool. It explicitly routes filtered needs to alternatives like issuer_insider_activity and screen_insider_transactions, giving clear when-to-use and when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It states the ordering ('newest first'), the specific data elements returned (form type, filing date, period end, accession number, direct link), and mentions pricing at /.well-known/x402. It does not mention rate limits or authentication, but the read-only nature is evident.

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 three sentences: the first defines the output, the second gives usage context, the third gives form-filter guidance. Every sentence contributes; no filler.

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

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

Without an output schema, the description enumerates the return fields and ordering, explains why to use the tool, and points to pricing. This is sufficient for an agent to decide when to call it and what to expect, covering the tool's 3-parameter API.

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 covers all three parameters (ticker, form, limit) with descriptions, so the baseline is 3. The description's only parameter guidance is a redundant 'Pass `form` to narrow; omit it for every type,' which adds no new semantics beyond the schema's existing note that narrowing is cheaper. Therefore a 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 opens with 'Recent EDGAR filing history for one company, newest first' and enumerates the returned fields (form type, filing date, period end, accession number, link), clearly differentiating it from financial metrics and company profile tools. The verb 'list' and resource 'filings' make the operation unambiguous.

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

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

It explicitly states use cases: 'Use it to establish what a company has filed and when' with concrete examples (annual report, fiscal quarter, 8-K activity), and it notes to pass `form` to narrow or omit for all types. It subtly hints that this is a precursor to pulling numbers, but it doesn't name alternative tools directly.

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?

No annotations exist, so description carries full burden. It discloses that there are 'No parameters, no upstream lookup,' returns 'the full metric table plus the derived ratios,' and specifies the table's schema. This covers operational behavior, though it doesn't explicitly state read-only semantics or auth requirements.

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 paragraph with front-loaded purpose. Every clause adds detail—metric fields, usage, ratios, pricing—without redundancy. Slightly longer than minimal, but each 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?

With no output schema, the description fully specifies the return shape (metric keys, labels, statements, units, tag candidates, and derived ratios with numerator/denominator) and even provides pricing reference, making it a complete guide for a parameterless 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?

Zero parameters; the schema alone covers 100% via its description. The tool description reinforces with 'No parameters' and adds 'no upstream lookup,' clarifying why no input is needed.

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 'Publishes the canonical metric vocabulary' with specific fields and explicitly ties to sibling tools' accepted keys, clearly differentiating from company_profile, list_filings, etc.

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

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

Explicitly instructs to 'Reach for this before any other paid call' and lists the exact scenarios (knowing which keys get_concept/get_financials/compare_companies accept, identifying XBRL tags behind figures), providing clear when-to-use guidance.

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

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

With no annotations, the description carries the burden and it does well: it discloses the tool is non-data-reading ('reads no data'), takes no arguments, and points to current pricing. It does not discuss latency, errors, or access constraints, but none appear material for a read-only vocabulary tool.

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

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

The text is longer than average but each section earns its place: purpose, warning about code misinterpretation, key examples, no-argument/no-data behavior, and pricing link. It is front-loaded with the core purpose; only minor trimming could tighten the lengthy first sentence.

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

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

Despite no output schema or annotations, the description explains what will be returned (form types plus codes with meaning, category, and open-market flag), when to use it, behavior, and pricing. An agent has enough to decide whether and how to invoke it.

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 documents this; the baseline for no-parameter tools is 4. The description reinforces that there is nothing to pass ('takes no arguments'), which is sufficient.

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 ('publishes a vocabulary') and an exact resource: SEC ownership form types and Form 3/4/5 transaction codes. It also differentiates itself from sibling data tools by explicitly stating it takes no arguments and reads no data.

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

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

It gives an explicit trigger condition: read this before drawing any conclusion from an insider row, and explains the reference can answer when no data is available. It does not name sibling tools or state exact when-not-to-use cases, so it falls just short of full routing guidance.

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

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

With no annotations provided, the description carries full behavioral burden and does so thoroughly. It discloses that totals count only open-market sales, that option exercises and tax withholdings are excluded, that share counts are as filed, that there is no market data feed or wealth estimate, and even explains Form 4/5 filing timing.

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

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

The description is long but dense: it front-loads the core distinction and result shape, then adds behavioral caveats and routing hints. A few sentences like the Form 4/5 timing and pricing link are peripheral to invoking the tool, but they still serve transparency without bloating the essential message.

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 optional parameters, no annotations, and no output schema, the description fully covers what an agent needs: what the result contains, key exclusions, how to get more detail per person, and important data caveats. The rich per-parameter schema handles the remaining invocation details.

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 high-level context that filters are 'the same as screen_insider_transactions' and that code filtering affects realized proceeds, but it does not substantially elaborate individual parameters beyond what the schema already says.

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 and resource ('screen insiders'), states the aggregation unit ('one row per person'), and defines the ranking metric ('cash they realized from open-market sales'). It also explicitly contrasts itself with screen_insider_transactions, so an agent can distinguish sibling tools immediately.

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 is explicit about when to choose this tool: 'This is the tool for a question about people rather than trades' and contrasts it with returning transactions to aggregate yourself. It also mentions passing owner CIK to insider_profile, providing routing guidance beyond mere selection.

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

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

No annotations are provided, so the description carries the full burden, and it delivers: it discloses page limits, one-row-per-transaction granularity, that results are paged, that the page ceiling is published in the response, the Form 4/5 filing lag, and how to find pricing. It also notes rows link to insider_profile via issuer and owner CIK, giving the agent follow-up behavior.

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

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

The description is well-front-loaded with the core capability and output unit, followed by guidance, alternatives, pagination, and caveats. The example list is long but useful; all information earns its place, though a slightly tighter version could convey the same guidance more economically.

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 9-parameter tool with no output schema and no annotations, the description covers the essential context: row granularity, follow-up tool, pagination behavior, filing-delay caveat, and pricing location. It does not enumerate all response fields beyond issuer and owner CIK, but the examples and filter list make the row contents reasonably inferable.

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 parameter descriptions already explain each option in detail, so the description adds little param-specific semantic value beyond restating the filter categories at a high level. The baseline of 3 is appropriate because 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?

The description states a precise verb-resource pair: it screens insider transactions across every issuer and returns one row per transaction. It distinguishes itself from sibling tools by clarifying the unit of analysis (transactions, not people) and gives a concrete list of filters. An agent can tell exactly what this tool offers without inspecting 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?

The description explicitly says to use this when the question is about trades rather than about the people making them, and it names direct alternatives: screen_insiders for one row per person and issuer_insider_activity for a single company. It also warns that Form 4/5 timing means this screens filings rather than real-time trades, which helps avoid misuse.

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