SecFeed: SEC EDGAR filings

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

With no annotations, the description carries the full burden. It usefully scopes behavior by naming the source ('latest annual report'), which implies a read-only lookup and a recency constraint, but it discloses nothing about failure modes, missing-data behavior, or output format.

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 tightly scoped sentence with the resource and source front-loaded and zero filler. Nothing could be removed without losing 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?

For a simple one-parameter read tool with no output schema, the description covers what is returned and from where, but says nothing about what happens when no annual report exists or how the ticker maps to a filing. Adequate but with a clear 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?

The single ticker parameter is fully documented in the schema (100% coverage), so the schema already does the work. The description adds no format or edge-case guidance (e.g., ticker vs. CIK handling),

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 the specific resource (auditor name, location, PCAOB ID) and the data source (latest annual report), which clearly distinguishes it from siblings like directors or executive_compensation. Lacks an explicit verb but the retrieval purpose is 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?

No indication of when to use this tool versus alternatives, and no mention of prerequisites (e.g., whether a ticker is required to get meaningful results). Usage is only implied by the resource name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful scope ('full text', 'one' report) implying a complete-document retrieval rather than a summary, but it says nothing about response size, truncation/pagination, output format (HTML vs plain text), or access restrictions. Adequate but thin for a no-annotation 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?

One front-loaded sentence with no filler; the return value and the keying parameter are stated immediately. The trailing clause is slightly awkward but costs almost nothing.

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 one-parameter read tool with full schema coverage and no output schema, the description covers the essentials (what is returned, how to address it). It is however silent on output format and on which sibling supplies the id, which a caller in a 27-tool server would benefit from.

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 there is a single parameter, so baseline is 3. The description adds only a slight hint about the id's provenance ('from the audit-reports datasets') beyond the schema's 'audit report id', with no syntax or format detail.

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+resource: it returns the 'full text of one auditor's report', scoped to a single document by id. That is clear and distinct enough from the other report-related siblings, though it never names a sibling or dataset-listing tool the id would come from.

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 phrase 'by the id from the audit-reports datasets' implies the precondition (you must already hold an id) and hints at the source dataset, which is implicit usage guidance. It still offers no when-to-use versus alternatives, no when-not-to-use, and does not point to a sibling that produces the id (e.g. a listing or search 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?

No annotations are provided, so the description carries the full burden. '(large)' is a genuinely useful disclosure about payload size and performance cost that goes beyond the schema, but nothing is said about rate limits, permissions, result format, or whether filtering by period/concept is possible.

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 tight sentence with no filler, and the key caveat '(large)' is placed immediately at the end. It is efficient, though terse enough that it borders on under-specification rather than pure conciseness.

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 one-parameter read tool with no output schema, this is minimally adequate: it says what is returned and that it is large. It omits any indication of structure (facts per period/concept), whether the response is paginated, or how to avoid pulling an unmanageable result set.

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?

There is one parameter, and schema description coverage is 100% ('ticker or CIK' already documented in the schema). The description's 'a company' adds no syntax or format detail beyond that, 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 names a specific verb+resource: retrieving every XBRL fact a company has reported. It is unambiguous about what the tool returns, distinguishing it from generic filing tools. However, it does not differentiate itself from siblings like xbrl_to_json, which an agent could reasonably confuse with a raw XBRL fact dump.

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?

There is no guidance on when to use this versus xbrl_to_json, financial_statements, or full_text_search, nor any stated prerequisites. The parenthetical '(large)' is the only signal, hinting that this is a heavyweight call, but it is not framed as a usage condition.

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 behavioral burden; listing the returned fields gives useful insight into the response shape. However, it never states that this is a read-only lookup, nor mentions error behavior for an unknown ticker/CIK, so disclosure is partial.

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 compact sentence with zero padding and the resource named first. The only weakness is the verbless noun-phrase style, which slightly reduces front-loaded actionability.

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

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

For a simple one-parameter lookup, the description adequately signals the returned content in place of an output schema. It is still thin on routing context and behavioral caveats, leaving gaps an agent must fill from siblings' names alone.

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 single 'cik' parameter already documents that it accepts a ticker or CIK. The description adds no syntax or format detail beyond the schema, which matches the baseline 3 for a fully documented parameter.

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 the resource (EDGAR entity profile) and enumerates the data it exposes (name, SIC, addresses, fiscal year end, former names), which distinguishes it from siblings like company_facts or directors. It lacks an explicit verb such as 'retrieve', so the agent must infer that this fetches rather than writes.

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?

There is no statement of when to use this versus alternatives such as company_facts, directors, or subsidiaries, and no mention of lookup-by-CIK prerequisites. Usage is only implied by the fields listed.

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 behavioral burden, and it discloses nothing beyond the field list. It does not say whether the ticker parameter is required in practice, what happens if it is omitted, or whether the result covers one company or all issuers. For a data-retrieval tool with zero annotation coverage this is a real gap.

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 eight-word fragment with zero filler and the resource front-loaded. It is efficient, though the fragmentary form gives the agent nothing to anchor structure around.

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 one-parameter read tool with full schema coverage this is minimally adequate: the agent knows what data comes back. With no output schema and no annotations, the description should still cover the ticker's practical role and result scope, and it does not.

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 the single parameter documented as 'ticker or CIK', so the baseline is 3. The description adds no formatting, resolution, or default behavior information beyond what the schema already states.

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 fragment names the resource (board members / directors) and the data it carries (compensation, age, tenure), which separates it from siblings like executive_compensation and governance_dataset. It is a noun phrase rather than a verb+resource, but an agent can still tell what it returns. No explicit differentiation from the closest siblings is offered.

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?

There is no statement of when to use this tool versus executive_compensation, governance_dataset, company_profile, or audit_report_text, all of which sit adjacent in the sibling list. The agent must infer usage from the resource name alone.

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 of behavioral disclosure, and it says nothing about whether this is a read-only listing, how results are ordered, pagination limits, or what a release contains. It only restates the resource name plus subtype labels.

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 short, front-loaded sentences with no filler; the resource is stated first and the subtype list follows. It is terse to the point of omitting the operation verb, but nothing is wasted.

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 three params, no annotations, and no output schema, the description covers the resource and kind values but leaves the 'details' flag semantics and pagination behavior entirely to the schema. Adequate to call the tool, thin on behavioral 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?

Schema description coverage is 100%, so baseline is 3, but the description adds the actual allowed values for 'kind' (litigation-releases, administrative-proceedings, aaer, press-releases), which the schema lacks entirely (no enums, kind documented only as 'release list'). That is genuine 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?

Names a specific resource ('SEC enforcement releases') and enumerates its four subtypes, which makes it distinguishable from siblings like audit_report_text or sro_filings. However, no verb is given (list vs. fetch vs. search), so the operation is inferred rather than stated.

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

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

No when-to-use guidance, no conditions or exclusions, and no named alternatives. The kind values hint at scope but never tell the agent when this tool is the right choice versus search_filings or full_text_search.

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 and no output schema, the description carries the full behavioral burden, yet it only implies a time series via 'over time'. It says nothing about granularity (quarterly/annual), units, data source, or whether the ticker is required or optional — all things an agent would need for a single-param lookup 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?

A single tight sentence with no filler and the core content front-loaded. It is efficient, though arguably under-specified rather than genuinely concise given what it omits.

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

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

For a simple one-parameter tool with no output schema, the description conveys the topical scope of the data, which is the minimum needed to route a query. However, the missing verb, return granularity, and distinction from shares_outstanding leave clear gaps.

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 single parameter carries its own description ('ticker or CIK'), so the schema already does the work. The tool description adds no parameter meaning beyond that, which matches the baseline 3 for high-coverage single-param schemas.

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 the data domain (share counts, dilution, stock comp, buybacks) but is a bare noun phrase with no verb, so it never says what the tool actually does with them (retrieve? compute? chart over a period?). It also does not differentiate itself from the close sibling shares_outstanding, which overlaps on the share-count dimension.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternatives (e.g. shares_outstanding for a point-in-time count vs. this tool for the trend). The agent must infer usage entirely from the topic phrase.

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 behavioral burden, yet it only discloses one trait: text=true adds the item text. It says nothing about default behavior when no parameters are supplied (all four are optional), pagination, response size when text=true, or any rate/permission constraints on this retrieval.

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 short, front-loaded sentences with zero filler; the resource comes first and the behavioral modifier second. Nothing could be cut without losing 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?

For a four-parameter retrieval tool with no output schema and no annotations, the description is thin: it does not describe the return shape, what happens when all-optional parameters are omitted, or how results are ordered or paged. The ambiguous 'text' type (string "true/false" rather than boolean) is also left unflagged.

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 3 would be the baseline, but the description genuinely adds meaning: it enumerates real item codes accepted by 'item' and clarifies that 'text' returns item text, which the schema reduces to the opaque 'true/false'. CIK and startDate are left to the schema, which already documents them adequately.

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 resource (8-K filings) and an organizing dimension (item), with concrete item codes that make the scope unambiguous. It does not, however, differentiate itself from siblings like search_filings or structured_form, so an agent must infer why this tool exists alongside 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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternative among the ~27 sibling filing tools. Usage is only implied by the phrase '8-K filings by item', which is the bare minimum context an agent needs.

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 behavioral burden, and it discloses almost nothing: no read-only indication, no note on whether data is paginated or limited to the most recent proxy year, no coverage caveats, and no sense of what the response contains. The 'by executive and year' phrasing is the only structural hint.

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 short fragment with zero filler and the resource named up front. It is efficient, though the terseness crosses into under-specification rather than true conciseness.

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 tool with no annotations and no output schema, the description should compensate by explaining what the table returns and how the optional ticker is used, but it does not. An agent cannot tell which years or executives are covered, whether results are truncated, or whether the optional parameter has a default behavior.

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% for the single 'ticker' parameter ('ticker or CIK'), so the schema already documents it fully. The description adds no parameter-level meaning — 'by executive and year' describes output columns, not the input. Baseline 3 applies when the schema does the work.

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 resource (the SEC Summary Compensation Table) and its dimensions (by executive and year), which tells an agent what data comes back. But it is a noun phrase with no verb, so it never states the operation (fetch/list/lookup), and it does not distinguish itself from the sibling 'pay_vs_performance' or 'directors'. Purpose is inferable rather than stated.

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?

There is no when-to-use guidance, no indication of prerequisites (e.g., needing a ticker or CIK), and no mention of alternative tools. With 'pay_vs_performance' and 'governance_dataset' among the siblings, an agent has no basis from the description for choosing between them.

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. It discloses the return format ('clean text') and the unit of extraction ('one item'), which is genuinely useful. However, it says nothing about permissions, whether the URL must be an index vs primary document, rate limits, or failure 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?

A single front-loaded sentence that states the action, resource, and output with zero filler. The parenthetical examples earn their place by clarifying the item-id format.

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 two-parameter extraction tool with no output schema and no annotations, the description covers purpose, scope, and return format adequately. It stops short of addressing the oddly optional url parameter or error conditions, but nothing critical to a correct call 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, but the description adds real value beyond the schema's bare 'item id' by giving concrete item-id examples per form type (1A, 7A, part2item1a, 2-2, 5-2). That syntax guidance helps the agent construct valid calls.

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 gives a specific verb ('Return') and resource ('one item of a 10-K/10-Q/8-K') plus the output format ('clean text'), so an agent immediately understands the operation. It does not explicitly differentiate itself from siblings like financial_statements or full_text_search, but the resource is narrow enough to be distinguishable.

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?

There is no when-to-use or when-not-to-use guidance and no named alternatives among the many siblings. The item-id examples hint at usage but describe formats, not the conditions that select this tool over full_text_search or financial_statements.

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 behavioral burden, and it does disclose one important trait: results are aggregated ('totals only') and reflect the latest filing. It does not say how many periods are returned, whether ticker resolution is required, or any auth/rate-limit behavior, leaving meaningful gaps for a no-annotation 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?

A single front-loaded sentence with zero filler. The scope limitation is embedded inline rather than padded with extra clauses.

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 tool with no annotations and no output schema, the description covers what is returned at a high level. However, with zero required parameters it never explains default behavior (what company/period is assumed when ticker and formType are omitted), which is a real gap 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?

Schema description coverage is 100%, so both parameters (ticker/CIK, formType 10-K or 10-Q) are already documented in the schema. The description adds no parameter-level meaning — it never explains the effect of formType or the ticker-vs-CIK choice — so baseline 3 applies.

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

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

States a specific resource (income statement, balance sheet, cash flow) with a clear scope qualifier ('Latest', 'totals only'), so an agent knows it returns the three primary statements in aggregate form. It does not name or contrast any sibling (e.g., structured_form, xbrl_to_json, company_facts), so differentiation is left to inference.

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?

There is no explicit when-to-use statement and no alternative tool named. The '(totals only)' phrase weakly implies that line-item detail lives elsewhere, but an agent gets no positive routing rule for choosing this over structured_form or xbrl_to_json.

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 behavioral burden, yet it discloses nothing about pagination, result volume, permissions, or what a period filter does to results. 'Rows' hints at a tabular return but the scope and limits are unstated.

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 compact sentence with no filler; the resource and keys are front-loaded. It is arguably too terse for the tool's complexity, but there is no wasted wording.

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?

All three parameters are optional, so an agent needs to know what happens when cik, cusip, or period are omitted, and how large the returned row set can be. With no annotations and no output schema, the description should cover these gaps and does not.

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% (cik, cusip, period all documented in-schema), so the baseline is 3. The description confirms cik and cusip are the selection keys but adds no format or precedence detail 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?

Identifies the resource ('13F holdings rows') and the two lookup keys (CUSIP, filer CIK), which lets an agent place it among filing-related siblings. However, there is no verb and no indication of whether it returns a list, a summary, or a single record, so the purpose is only partially pinned down.

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 names the two query keys but never states when to use this tool versus related siblings like structured_form, search_filings, or company_facts. No prerequisites, no exclusions, no alternative 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?

With no annotations, the description carries the full behavioral burden. It does disclose corpus coverage (every filing and exhibit since 2001), which is useful, but says nothing about result limits, pagination, ranking, rate limits, or auth requirements for what is likely a high-volume query endpoint.

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 short sentences, zero filler, with the corpus scope front-loaded before the syntax tip. Appropriately sized for a simple search tool.

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 4-parameter search tool with no annotations and no output schema, the description omits return-shape and pagination behavior and never mentions the date-range or form-type filtering capabilities. An agent gets the gist but not enough to call it confidently in edge cases.

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

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

Schema description coverage is 100%, so all four parameters (query, startDate, endDate, formTypes) are already documented in the schema. The description's quote-syntax remark duplicates the schema's own 'words or "exact phrase"' wording, adding no meaning beyond it; baseline 3 applies.

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

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

States a specific verb (search) and resource (full text of every filing and exhibit) plus a temporal scope (since 2001). It is clear what the tool does, though it never names the obvious sibling search_filings to explain how full-text search differs from a metadata search.

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 a query-syntax hint ("Use quotes for exact phrases") but no when-to-use guidance, no exclusions, and no routing against siblings like search_filings or extract_section. The agent must infer when full-text search is preferable to structured filing search.

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 it does disclose useful behavior: results are ordered 'newest filings first' and come from specific filing types. However, it says nothing about pagination, the 50-record cap interacting with paging, authentication needs, or the shape of returned records.

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 front-loaded with source and scope, followed by a necessary dataset list that compensates for the absence of an enum in the schema. The list is long but each entry earns its place; only the closing sort note could be tightened.

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 5-parameter, no-annotation, no-output-schema retrieval tool, the description covers sources and valid datasets but omits what each dataset actually returns, how ticker and date filters combine, and any result-shape expectations. Adequate but with clear gaps.

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, but the description adds real value by enumerating the valid dataset paths that the schema only illustrates with a single example ('e.g. board-oversight'). It does not clarify ticker-vs-CIK handling or date-range semantics beyond what the schema states.

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 the resource (structured governance data) and its provenance (proxy statements, auditor's reports, SEC enforcement releases) plus the full list of datasets, which lets an agent distinguish it from siblings like executive_compensation or audit_report_text. It lacks an explicit verb such as 'retrieve/list', so the action is inferred rather than stated.

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 dataset enumeration hints at what can be queried, but there is no statement of when to use this tool versus the numerous siblings (directors, executive_compensation, audit_report_text, enforcement) that overlap heavily. No prerequisites or exclusions are given.

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 behavioral burden. It discloses the data contents (owners, prices, footnotes) but says nothing about pagination, row limits (despite a 'size' param), default result volume, auth requirements, or output format.

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 front-loaded sentence with no filler. It is arguably too terse for a six-parameter tool, but every word is load-bearing and nothing is wasted.

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 six-parameter, zero-required, no-output-schema, no-annotation retrieval tool, the description is thin. It does not explain result volume, ordering, pagination, or what happens when filters are omitted, all of which an agent needs to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description's mention of owners, prices, and footnotes loosely echoes the owner and minValue concepts but adds no syntax, default, or format detail 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 names a specific resource — insider transactions and holdings sourced from SEC Forms 3/4/5 — and lists the returned entities (owners, prices, footnotes). It implicitly differentiates from siblings like form_13f_holdings and executive_compensation via the Form 3/4/5 scope, though it uses a bare noun phrase with no verb such as 'list' or 'retrieve'.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of any sibling tool. The agent must infer from the resource name alone that this is the insider-filing lookup rather than, say, form_13f_holdings.

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 behavioral burden, and it discloses almost nothing beyond the two modes. It does not say whether results are a list or single record, whether pagination or rate limits apply, or whether any authentication/data source constraints exist.

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 compact sentence with the resource front-loaded and the two modes stated economically. Nothing is wasted, though the telegraphic phrasing is slightly terse for a two-mode tool.

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 annotations and no output schema, the description should do more to explain the return shape (single firm vs. list of matches) and any constraints on the lookup. It covers the invocation surface adequately but leaves the agent guessing about results.

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% ('CRD number', 'firm name'), so the schema already documents both parameters. The description adds only the mapping of each parameter to its retrieval mode, which is marginal value over the schema baseline.

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 resource (Form ADV adviser firms) and two distinct operations (search by name, retrieve by CRD), so an agent knows exactly what it returns. No sibling tool covers investment advisers, so differentiation is implicit rather than stated, which keeps it just short of a 5.

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 phrase 'search by name or get one by CRD' implies the branching condition for each parameter, giving usable but inferential guidance. There is no explicit when-not-to-use statement or mention of alternatives among the sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It says nothing about read-only behavior, pagination, authentication, rate limits, return format, or any other operational trait, leaving the agent with no behavioral context.

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 very short and front-loaded, but it is a sentence fragment rather than a structured statement of purpose. It avoids waste but is too thin to earn its place as a complete tool description.

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 tool with no annotations, no output schema, and many sibling filing tools, the description is incomplete. It does not explain the relationship between the parameters and the returned IPO/offering data, nor does it help the agent choose this tool over similar filing tools.

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 both parameters (formType, startDate) are already documented in the schema. The description adds no meaning beyond repeating '424B4', which the schema already lists; this meets the baseline of 3 when the schema does the heavy lifting.

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

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

The description names a filing domain (IPO registrations) and a form type (424B4 offering terms), but supplies no verb and does not differentiate this tool from sibling filing tools such as search_filings or form_13f_holdings. It is more informative than a tautology, but it remains a vague content label rather than a clear action 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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The phrase 'Registrations and 424B4 offering terms' implies a subject area but offers no actionable usage 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing but discloses nothing about permissions, pagination, response size, or what happens when cik/accessionNo are omitted (both are optional).

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 compact sentence with the resource front-loaded and no wasted words. It is efficient, though the terseness borders on under-specification.

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 an unannotated, output-schema-less tool, the definition is minimal but workable: the purpose is clear even if return format, optionality behavior, and required identifiers are left unexplained.

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 3 applies. The description adds nothing beyond the schema about cik or accessionNo, and does not clarify that these identify the target filing.

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 clear verb-and-resource pair ('list' + 'files in a filing') and enumerates the file categories (documents, exhibits, XBRL). This differentiates it reasonably from siblings like extract_section or xbrl_to_json, though it never names an alternative explicitly.

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?

There is no guidance on when to use this tool versus alternatives such as extract_section, structured_form, or xbrl_to_json, and no mention of prerequisites. The agent must infer usage from the name alone.

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 behavioral burden. It implies a read-only lookup but says nothing about behavior on an unknown/unrecognized CUSIP, required CUSIP format, caching, 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 content is a single fragment with no wasted words, but it is so terse that it omits basic orientation (whether it returns a result or an error). Appropriate length, insufficient substance.

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 and no annotations, the description does at least state the return values qualitatively (issuer name and ticker). However, it omits error/not-found behavior and any constraints on the CUSIP input, leaving the definition only minimally 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 description coverage is 100% and there is a single parameter, so the schema already documents the input. The description adds no format or validity detail beyond restating that the input is a CUSIP; 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 fragment 'CUSIP to issuer name and ticker' names a specific input (CUSIP) and the concrete outputs (issuer name, ticker), so the agent can tell what the tool produces. It does not explicitly differentiate itself from the sibling map_ticker, though the inverse direction is easily inferred.

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?

There is no statement of when to use this tool, when not to, or which alternative (e.g. map_ticker) to prefer. The agent must infer usage purely from the one-line mapping.

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 of behavioral disclosure. It lists the returned fields (CIK, name, exchange) but says nothing about read-only safety, auth needs, rate limits, or failure behavior for an unknown ticker.

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 short and front-loaded with no wasted words, but it is a sentence fragment rather than a structured statement, and its brevity comes at the cost of necessary detail.

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

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

For a simple one-parameter lookup with no output schema, listing the return fields (CIK, name, exchange) is helpful and partially compensates for the missing output schema. However, error handling, data freshness, and format details are absent.

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

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

Schema coverage is 100%, so the baseline is 3. The single parameter's schema description is just "ticker", adding no real semantics, and the tool description merely implies the input is a ticker symbol without format or case guidance.

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 mapping operation from a ticker to CIK, name, and exchange, which is clear and actionable. It does not, however, differentiate itself from the sibling map_cusip, which is the obvious alternative for identifier mapping.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The agent can infer it is a lookup, but nothing tells it when to prefer this over map_cusip or how to handle a missing ticker.

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 behavioral burden, and it discloses almost nothing: whether results are a filing list or document text, what happens when ticker is omitted (both parameters are optional), whether results are paginated, or what date semantics startDate has. It is a content label, not a behavioral spec.

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?

It is a single short fragment with zero waste and the most informative content is front-loaded. However, it is under-specified rather than genuinely concise, omitting the action verb that would make the sentence self-contained.

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 retrieval tool with no annotations and no output schema, the description should at least say it returns a list of M&A filings (and in what form). As written, an agent cannot predict the response shape or the effect of omitting both optional parameters.

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% (ticker/CIK and YYYY-MM-DD are documented in the schema), so the baseline is 3. The description adds no parameter meaning beyond the schema, but none is required.

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 resource class (M&A filings) and enumerates the covered form types (merger proxies, tender offers, 425, S-4), which lets an agent distinguish it from siblings like ipo_filings or sro_filings. It stops short of an explicit verb such as 'retrieve/list', but the noun-phrase scope is concrete rather than tautological.

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?

There is no when-to-use guidance, no mention of alternatives among the many sibling filing tools, and no statement of preconditions. The agent must infer the retrieval intent from the name and contents list alone.

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. It discloses only the source ('the proxy's XBRL') and the yearly granularity; it says nothing about whether the data is read-only, whether the proxy filing is auto-located, or what the return shape is.

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 front-loaded clause with zero filler. Every word carries information about resource, granularity, or source.

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

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

For a simple one-parameter read tool with no output schema this is roughly adequate, but it omits default behavior when ticker is absent and gives no hint of the returned structure, which the missing output schema would otherwise require.

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 there is a single optional parameter, so the baseline is 3. The description adds nothing about the ticker/CIK parameter, such as format or what happens when it is omitted.

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 resource ('Pay versus performance table') and scopes it ('by year from the proxy's XBRL'), so an agent knows exactly what data comes back. It does not, however, distinguish itself from close siblings like executive_compensation or xbrl_to_json, leaving the agent to infer the boundary.

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?

There is no when-to-use guidance and no alternative named. An agent choosing between this and executive_compensation or xbrl_to_json gets no routing help at all.

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 behavioral burden, yet it only states scope ('every EDGAR filing'). It says nothing about pagination semantics, result ordering, rate limits, or cost of an unbounded query — notable for a search endpoint with from/size controls.

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 front-loaded sentence; the example earns its place by showing syntax rather than restating the schema. 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?

Adequate for a search tool with no output schema: scope and query grammar are covered. It remains incomplete on pagination behavior and how results are returned/ordered, which matters given the from/size parameters.

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, but the embedded example query raises this above baseline: it concretely demonstrates field syntax (ticker:, formType:, filedAt:[... TO ...]) and range format that the schema's bare 'Lucene-style query' description does not convey.

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?

Specific verb (search) + resource (every EDGAR filing) with the query dialect named (Lucene-style). It does not distinguish itself from sibling full_text_search, which an agent might reasonably confuse it with, so it falls short of a 5.

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 no when-to-use guidance and never names alternatives such as full_text_search, form_13f_holdings, or structured_form, despite a crowded sibling list. Usage is only implied by the tool's existence.

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 of behavioral disclosure, and it discloses almost nothing. It never states that this is a read-only lookup, what source it draws from, the granularity of the history (quarterly, annual, point-in-time), or what the return looks like. Only the word 'history' hints at temporal scope.

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?

It is a single short noun phrase with no filler, but it is a fragment rather than a front-loaded structured statement of purpose. Brevity here reflects under-specification as much as conciseness.

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

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

For a simple one-parameter lookup with no output schema, an agent still needs to know the data source, the reporting frequency, and whether a time series or a current value is returned. None of that is present, leaving real gaps for correct invocation and result interpretation.

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 single parameter (ticker) is documented as accepting a ticker or CIK, so the schema does the work. The description adds no additional meaning about the parameter, which matches the baseline of 3 when coverage is high.

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 the resource (shares outstanding and public float) but supplies no verb, so it reads as a label rather than a stated action. An agent can infer it retrieves data, and it is distinguishable from siblings like equity_dilution or company_facts, but the purpose is only implied.

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?

There is no indication of when to use this tool versus alternatives such as company_facts, equity_dilution, or financial_statements. No prerequisites, exclusions, or selection conditions are given.

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 must carry behavioral disclosure, but it only notes that omitting org changes the output to a list of organizations. It does not describe permissions, rate limits, return format, pagination, or whether providing org returns filings. Behavioral transparency is low.

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 short sentences, front-loaded with the resource and examples, then the usage rule. No wasted words.

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

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

For a tool with one optional parameter, no annotations, and no output schema, the description is under-specified. It does not explain the return format, whether results are paginated, or what filing details are included, leaving an agent with gaps 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?

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: omitting org triggers an organization list, while providing org presumably retrieves filings for that org. This clarifies the optional parameter's effect, earning a 4.

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 identifies the resource (SRO rule filings) and gives examples of organizations, but does not state an explicit action verb and does not differentiate from sibling filing tools like search_filings. An agent can infer it retrieves filings, but the purpose is not fully explicit.

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

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

It provides one usage rule: omit org to list organizations. However, it does not say when to use this tool versus alternatives such as search_filings or list_filing_files, nor does it describe prerequisites. The guidance is minimal but present.

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 behavioral burden and discloses almost nothing: no auth requirements, no rate limits, no pagination behavior, no indication of what 'every data point' actually means in the response. The only implicit signal is that this is a read/retrieval operation, which is minimal.

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 short sentences with no filler, and the core capability is stated first. It is compact to the point of under-specification rather than bloated, so it earns credit for tightness but not a 5.

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?

A four-parameter retrieval tool with no output schema and no annotations should explain what is returned and how size/startDate shape the result set, and it does none of that. Given the complexity signals and the absence of structured support, the description leaves significant gaps.

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, and the description genuinely adds value by enumerating the valid family values (form-144, form-13f, form-13d-13g, form-d, form-c, reg-a, n-port, n-cen, n-px), which the schema's bare 'form family' field lacks. It does not elaborate on cik, size, or startDate, but the enum addition lifts it above baseline.

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 conveys the resource (parsed XML form data with 'every data point') and scopes it to a set of form families, but it is a noun phrase with no verb, and it never distinguishes itself from close siblings like form_13f_holdings, xbrl_to_json, or search_filings. An agent can guess it retrieves structured form content but cannot confidently separate it from those alternatives.

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?

There is no when-to-use, when-not-to-use, or alternative-routing guidance at all. The listed form families function as allowed parameter values, not as usage conditions, so the agent gets no help deciding between this and the many sibling filing 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?

With no annotations, the description carries full behavioral burden. It discloses the data source (Exhibit 21), which is useful, but says nothing about read-only nature, return format, pagination, or whether the operation is safe to repeat. A simple retrieval tool still needs more context than this.

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 front-loaded phrase with no wasted words. While it is arguably under-specified, the conciseness dimension rewards efficiency, and there is no structural clutter.

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, so the description should explain what a caller gets back (e.g., a list of subsidiary names, structure, filing references). It also does not clarify whether the ticker/CIK parameter is required or optional, leaving key invocation details unstated.

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 single 'ticker' parameter is fully documented in the schema. The description adds no further meaning, such as whether the parameter is optional or how CIK vs ticker is resolved, making the baseline of 3 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 identifies a specific resource (subsidiaries) and a precise source (Exhibit 21), making the tool's data domain clear. It lacks an explicit verb and does not differentiate itself from siblings like extract_section or structured_form that might also retrieve exhibit content, so it falls short of a 5.

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 offers no guidance on when to use this tool versus alternatives such as extract_section or structured_form. The source hint ('Exhibit 21') implies a context, but no explicit when-to-use or exclusions 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?

With no annotations, the description carries the full behavioral burden, and it says only what is returned ('all financial statements and cover page ... as JSON'). It does not disclose which identifiers are required, error behavior when a filing has no XBRL, or any auth/rate considerations. The output-content statement adds some value, but most behavioral context is missing.

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 front-loaded sentence with no wasted words. The trailing 'from its XBRL' is slightly awkward but the core scope is stated immediately. Appropriate size for the amount of information conveyed.

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, so the description must convey return values, and it does so at a high level ('all financial statements and cover page as JSON'). Yet it omits the relationship between the three optional identity parameters and any failure modes, leaving meaningful gaps for a zero-required-param extraction tool.

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

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

Schema description coverage is 100%, so the schema already documents cik, htmUrl, and accessionNo, establishing the baseline of 3. The description adds nothing about how the parameters relate (they appear to be alternative filing identifiers) or which to prefer, so no credit above baseline.

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 conversion: extracting all financial statements and the cover page of one filing from XBRL into JSON. This is a clear verb+resource pairing that distinguishes it from generic siblings like financial_statements. However, it never names or contrasts with those siblings explicitly, leaving the agent to infer the differentiation.

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?

There is no guidance on when to use this tool versus financial_statements, structured_form, or extract_section. No prerequisites, no mention that the three parameters are alternative ways to identify the same filing, and no exclusions are given.

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