Conduit — Filings & Fundamentals

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds genuinely useful context beyond them: the underlying data source is the latest 10-K per ticker, implying annual-cadence, potentially stale figures rather than real-time data, and that comparison is capped at 5 companies.

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 sentence that front-loads the operation, enumerates the returned metrics, and closes with the scope limit. Every clause earns its place with 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?

With one required parameter, full schema coverage, and no output schema, the description does the remaining work by enumerating the returned fields (revenue, net income, EPS, assets, equity) and the data source. Only minor gaps remain, such as units/currency or behavior when fewer than 5 or invalid tickers are supplied.

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 'tickers' parameter is fully documented with format and the max-5 constraint in the schema itself. The description's 'up to 5 tickers' merely echoes the schema, and the metric list describes outputs rather than adding parameter meaning, 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?

States a concrete verb (side-by-side comparison), the resource (key financial facts), the exact metrics returned, and the scope limit of up to 5 tickers sourced from the latest 10-K. It is specific enough for an agent to recognize the operation, though it does not distinguish itself from the sibling get_peer_comparison.

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?

Usage is only implied: an agent can infer this is for comparing multiple companies at once from 'side-by-side ... for up to 5 tickers.' There is no explicit when-to-use, when-not, or routing to near neighbors such as get_peer_comparison, get_company_facts, or get_financial_statement, all of which could plausibly be chosen instead.

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

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

Annotations already establish it as a safe, read-only, open-world operation, so the safety burden is lifted. The description adds the useful scope signal that the data comes from the 'latest' 10-Q, but does not disclose freshness semantics, error behavior for non-10-Q issuers, or that it is limited to key facts rather than the full statement.

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 compact sentence with zero filler, front-loading the source ('latest 10-Q') followed by the returned fields. Nothing redundant with the title or schema.

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

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

For a one-parameter read tool whose annotations cover safety and whose schema is fully documented, the description supplies what the agent needs: the data source and the facts returned. Minor gaps remain around when the tool is appropriate versus related financial tools and behavior when no 10-Q is filed.

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 a single ticker parameter with 100% schema description coverage ('Stock ticker, e.g. AAPL'), so the schema does the explaining. The description contributes no additional parameter meaning, which is the correct baseline 3 for full coverage.

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 ('get ... facts') and pins the scope to the latest 10-Q with an enumerated list of facts (revenue, profits, EPS, assets, cash, debt). This clearly separates it from the broader get_company_facts or generic get_financial_statement, but it never names a sibling to draw the boundary 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?

The description only says what the tool returns. It gives no condition for when to prefer it over get_company_facts, get_financial_statement, or get_quarterly_trend, no prerequisites (e.g. US-listed filers only), and no note on what happens if no 10-Q exists.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), so the description's burden is lower. It usefully discloses that Item heading extraction is 'best-effort' — a real caveat about data quality — but says nothing about ordering, pagination, or what happens when no 8-Ks 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 efficient sentence with the resource front-loaded and the qualifier ('best-effort') trailing appropriately. No waste, though it is arguably under-specified rather than optimally concise.

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 must carry more of the return-value burden, and it only gestures at the shape ('filings with Item headings'). It omits the date range covered by 'recent', the fields returned, and the limit ceiling's effect, leaving an agent with 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 description coverage is 100%, so both parameters (ticker, limit) are already fully documented in the schema, and the description adds no format or semantic detail beyond what is there. 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 (recent 8-K filings) and a specific transformation (Item headings extracted from document text), which distinguishes it from generic siblings like list_filings and get_filing_text. It does not, however, explicitly name or contrast with any 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 word 'Recent' implies a default time scope, but there is no statement of when to choose this tool over list_filings, get_filing_text, or get_filing_amendments. 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral detail — the figures are derived from 10-K history — but says nothing about how many periods are returned, currency/adjustment conventions, or response structure.

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 tight sentence with the metric list and source front-loaded; no filler or redundancy. Every clause carries 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 one-parameter, read-only tool with annotations covering the safety profile, this is nearly sufficient, and it helpfully enumerates the returned metrics in the absence of an output schema. It stops short of describing period count, formatting, or error behavior for unknown tickers.

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 single ticker parameter is fully documented including an example. The description adds no meaning beyond the schema, so the baseline of 3 applies rather than a higher score.

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 (year-over-year growth rates) and enumerates the exact metrics returned (revenue, net income, diluted EPS, total assets) plus the data source (10-K history). An agent can distinguish it from get_financial_statement or get_quarterly_trend by the growth-rate framing, though it never explicitly contrasts itself with those siblings.

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 such as get_financial_ratios, get_quarterly_trend, or get_financial_statement, and no prerequisites or exclusions are given. The 'from 10-K history' phrase hints at the data source but does not constitute usage 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that the result is a full time series; it says nothing about pagination, limit truncation behavior, or data ordering beyond what the schema states.

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 compact sentences with the core resource description front-loaded. The second sentence about form filtering is slightly redundant with the schema but still earns its place as a quick scoping cue.

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

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

For a read-only, five-parameter lookup with full schema coverage and no output schema, the description covers purpose, scope, and the key filter. What it lacks is any signal about result volume or ordering, which would help an agent interpret the 'time series' return.

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 five parameters are already documented, including defaults, the limit cap of 60, and the form filter. The description's example tag format adds marginal value but does not extend parameter meaning beyond 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?

States a specific verb (full time series retrieval) and resource (one XBRL concept across any taxonomy/tag), with a concrete example (us-gaap:Revenues). It implicitly distinguishes itself from broader fact/statement siblings by scoping to a single concept, though it never names an alternative.

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 form filter hint ('10-K or 10-Q') implies a usage context, but there is no explicit when-to-use guidance and no routing to siblings like get_company_facts or get_financial_statement. An agent must infer the boundary itself.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful data-fidelity context ("Values as reported", "USD unless noted"), which is genuine value beyond the annotations, but says nothing about period coverage or freshness beyond "Latest".

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 a parenthetical qualifier; the scope ("Latest 10-K") is front-loaded and there is no wasted phrasing. Slightly overlaps with the title but remains tight.

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 usefully enumerates the returned financial concepts and notes the reporting/currency basis. For a one-parameter read-only tool this is nearly complete; only the fiscal period/date range is left unspecified.

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, with an example (AAPL) provided in the schema itself. The description adds only the implicit notion that ticker selects the company; no format or edge-case detail is contributed 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?

States a specific verb and resource ("Latest 10-K XBRL facts for a company") and enumerates the concepts returned (revenue, profits, EPS, assets, etc.). The "Latest 10-K" scoping distinguishes it from the quarterly sibling get_10q_facts, but it doesn't differentiate from closer siblings like get_company_concept or get_financial_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 explicit when-to-use statement, no prerequisites, and no named alternative among the many siblings (get_10q_facts, get_company_concept, get_financial_statement). Usage is only weakly implied by the title's "Latest 10-K" framing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful provenance detail that data comes from SEC EDGAR and that output is a holistic identity record rather than a subset, but says nothing about caching, rate limits, or error behavior for unknown tickers.

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 compact sentence with the source system and payload contents front-loaded; every clause carries information and nothing is padded.

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

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

No output schema exists, so the description's field enumeration is what tells the agent what it will receive, and it does so adequately for a single-parameter read tool. Minor gaps remain around response shape (flat vs. nested) and behavior on invalid tickers.

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?

With a single parameter and 100% schema description coverage (the schema already gives the 'AAPL'-style ticker example), the schema does the heavy lifting. The description adds no naming conventions or format nuances beyond it, so the baseline 3 applies.

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

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

States a specific verb (get) and resource (company profile) and enumerates the concrete fields returned: addresses, phone, website, filer category, former names, tickers/exchanges. This clearly separates it from financial-statement or filing siblings like get_filing_text or get_company_facts, though it never explicitly contrasts with lookup_company or get_ticker_search, which sound adjacent.

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 choose this tool over the similarly-named lookup_company or get_ticker_search siblings, nor any stated prerequisites beyond the required ticker. Usage is only implied by the listed fields.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral constraint — the data is limited to the latest 10-K period, not quarterly — but says nothing about fallback behavior when a company has no debt or about return 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 that leads with the resource and immediately scopes the period, with zero filler. Every element earns its place.

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

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

For a one-parameter read-only tool with full annotation coverage and no output schema, the description is close to sufficient: it sets the period scope, which is the main ambiguity. A brief note on what happens when debt components are absent would complete 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?

Schema description coverage is 100% and the single ticker parameter is fully documented with an example (AAPL), so the schema carries the load. The description adds no parameter-level detail beyond what is already structured, making the baseline 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 names a specific resource (debt components) and enumerates the concrete line items returned (short-term borrowings, current debt, long-term debt), which separates it from generic siblings like get_financial_statement. It stops short of explicitly naming which sibling to use for other debt-related needs, so sibling differentiation is only implicit.

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 statement, no exclusions, and no named alternative such as get_financial_statement or get_quarterly_trend. The only usage signal is the implicit 'latest 10-K period' scoping, which the agent must infer.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond them: the XBRL cash-flow source, newest-first ordering, and the sign convention (negative = cash outflow), which prevents misreading the values.

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 fragments that are entirely front-loaded with the resource and the most decision-relevant facts (source, order, sign). Zero filler; every clause carries information the caller needs.

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

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

For a read-only tool with no output schema, the description covers scope, source, ordering, and value sign, which is nearly everything needed to call it correctly. Minor omissions remain, such as currency/units and whether amounts are total cash paid rather than per-share, but the core is 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%, so both ticker and periods are fully documented in the schema and the baseline is 3. The description adds nothing about parameter syntax or format (e.g., how periods interacts with the annual granularity), so no credit above baseline is warranted.

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 (annual cash dividends paid) and adds the data provenance (XBRL cash-flow tags) and ordering (newest first), so the agent knows exactly what is returned. No sibling covers dividends, so there is effectively no competing tool, but the description never names or contrasts 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?

The definition of scope implies when the tool applies (annual dividend history), but there is no explicit when-to-use or when-not guidance and no reference to any sibling tool. With 23 sibling financial tools, a routing hint would have been valuable; usage is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful traits of scope (amendments only) and ordering (reverse chronological), but says nothing about pagination, result format, or how many results to expect.

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 that front-loads the resource and the defining examples. No wasted words and nothing redundant.

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 read-only list tool with full parameter coverage and safety annotations, the essentials are present. However, it omits any hint about pagination or what a returned item contains, which would help an agent chain into get_filing_documents or get_filing_text.

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 ticker and limit are already documented with defaults and bounds. The description adds no parameter detail beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource (amended filings) and qualifies it with concrete form examples (/A forms: 10-K/A, 10-Q/A, 8-K/A). This clearly separates it from generic siblings like list_filings or search_filings, 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 explicit when-to-use guidance and no comparison against list_filings, search_filings, or get_filing_documents. The scope is implied by the word 'amended', but an agent must infer that this is the amendment-specific counterpart to list_filings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful scope context ('full filing history'), but says nothing about whether counts include amendments, how many years are returned, or any pagination/limits — so it adds only modest value beyond annotations.

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

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

A single economical sentence with the resource and grouping dimensions front-loaded. It is a noun fragment rather than a full sentence, 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?

For a one-parameter, read-only aggregate tool with no output schema, the description effectively sketches the return shape (counts bucketed by form and year) and the data scope. Only the treatment of amendments and the breadth of the year range remain unspecified.

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?

With a single parameter at 100% schema description coverage, the schema already documents the ticker fully. The description adds no format or constraint detail (e.g. case sensitivity, exchange prefixes), so the baseline 3 applies.

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

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

The description names the specific resource (filing counts) and its two grouping dimensions (SEC form, year) across the full filing history, which is more informative than the bare name. It does not explicitly distinguish itself from aggregation-free siblings like list_filings or search_filings, so it stops 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?

There is no when-to-use guidance: nothing says to pick this over list_filings when you only need totals rather than individual filings, and no prerequisites or exclusions are stated. Usage must be inferred entirely from the word 'counts'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value by disclosing that results are parsed from the EDGAR index page, hinting the list reflects the index rather than a guaranteed complete archive, but it says nothing about ordering, completeness, or error behavior when the accession number is unknown.

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, scope, and data source with zero filler. Nothing can be trimmed without losing meaning.

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

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

For a read-only list tool with full parameter coverage and annotations, the essentials are present, but with no output schema the description never hints at what a document entry contains (name, type, exhibit, URL) or whether pagination applies. 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?

Schema description coverage is 100%, so both parameters are already documented with examples (AAPL, 0000320193-25-000001). The description's phrase 'one filing' reinforces that the two identifiers jointly select a single filing, but adds no format or edge-case detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (List) and resource (documents inside one filing), and 'parsed from the filing's EDGAR index page' clarifies the source of truth. It implicitly separates itself from list_filings (filings themselves) and get_filing_text (text content), but never names those siblings to make the distinction 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?

There is no when-to-use guidance and no routing to alternatives such as list_filings or get_filing_text. The required ticker + accession_number pair implies you must already know the filing, but this precondition is left to inference from the schema.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond them – 'cleaned' and 'head-only, capped' disclose that output is processed and truncated. It stops short of saying whether truncation is silent or how to retrieve the rest, which matters for a text-fetch 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 waste, and the most decision-relevant fact (it is a truncated excerpt, not the full document) is front-loaded.

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

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

With no output schema, the description carries some burden for describing the return value, and it does say it is cleaned, head-only, and capped. But it omits how to obtain content beyond the head/character cap and does not relate the cap to max_chars, leaving a gap for a fetch 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 all four parameters are already documented, including the default-document behavior of 'document'. The description's 'primary document' phrasing merely echoes that schema note. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific resource and output form: cleaned text excerpt from a filing's primary document. An agent knows it fetches raw text content. However, it never contrasts itself with siblings like get_filing_documents or list_filings, so the reader must infer that this returns content rather than metadata.

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 prerequisites, and no alternative named. With many filing-adjacent siblings (get_filing_documents, list_filings, get_filing_amendments), the description does nothing to route the agent to the right one.

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

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

Annotations already cover the read-only, non-destructive, open-world safety profile, so the bar is lower. The description adds genuine behavioral context beyond them: the data derives from the latest 10-K XBRL and values are null where inputs are missing, warning the agent about annual staleness and sparse results.

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

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

Two tight sentences: the payload (what is computed and from where) is front-loaded, and the caveat about nulls is a compact trailing clause. No filler or repetition of the tool name.

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

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

With no output schema, the description compensates by enumerating the exact metrics returned and disclosing null behavior for missing inputs. For a single-parameter read tool this gives the agent everything needed to call it and interpret the result.

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 (ticker) with 100% schema description coverage and an example (AAPL), so the schema fully carries the semantics. The description adds nothing further about the parameter; 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 precise resource (financial ratios) plus the exact ratios returned (gross/operating/net margins, ROE, ROA, debt-to-equity, FCF) and the data source (latest 10-K XBRL). This enumeration clearly separates it from sibling tools like get_financial_statement or get_annual_growth, which return raw statements or growth series rather than computed ratios.

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?

Usage is only implied: pass a ticker to get ratios for that company. The description never says when to prefer this over get_financial_statement, nor flags that 'latest 10-K' means annual-only data (no quarterly), which is an implicit exclusion left for the agent to infer.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds that results are structured and span multiple periods, but says nothing about data source (presumably SEC filings), currency/units, or any limits, so added behavioral value is modest.

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 fragment with no filler; the most decisive information (what the payload contains) comes first. It is written as a noun phrase rather than an action sentence, which is slightly less crisp for a 'get' 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 read-only lookup with fully documented parameters and no output schema, the description covers the essentials. It nevertheless omits the data source, whether values are normalized or as-reported, and any indication of return shape, leaving the agent with inference to do.

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 every parameter is documented (annual, ticker, periods with max 12, statement). The description merely echoes those options ('annual or quarterly, multiple periods') without adding constraints or accepted value formats, 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?

The description names the resource precisely and enumerates the three statement types (income, balance, cash-flow) plus the time granularities, so an agent knows exactly what corpus it returns. It lacks an explicit verb and never distinguishes itself from overlapping siblings such as get_quarterly_trend or get_annual_growth, so it stops 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?

There is no when-to-use statement, no prerequisites, and no routing to alternatives despite several adjacent tools (get_financial_ratios, get_quarterly_trend, get_company_facts) that plausibly overlap. Usage must be inferred entirely from the parameter options.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful caveat beyond that: reporting-owner names are parsed best-effort, warning the agent the data may be imperfect. It says nothing about ordering, pagination, or latency.

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 the resource front-loaded and the best-effort caveat appended. Nothing is wasted, though the extreme brevity leaves the tool under-explained 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?

For a simple two-parameter read tool with no output schema and full annotation coverage, the description is minimally adequate. It omits what a filing record contains and whether returned data is scoped to the ticker's issuer, which would help an agent interpret 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% for both parameters (ticker example AAPL, limit default 10 / max 25), so the schema carries the semantics fully. The description adds no parameter detail, making the baseline 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?

Names a specific resource (insider ownership filings, Forms 3/4/5) with an implicit retrieval verb via the get_ prefix, so an agent knows what it returns. It does not explicitly distinguish itself from siblings, though the resource is narrow enough that sibling confusion is unlikely.

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 (e.g., list_filings or search_filings), and no note on scope such as whether results are limited to one issuer or span all reporting owners. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that it uses the frames API and defaults to the company's own current XBRL tag unless overridden, but says nothing about the shape or comparability of the ranked result.

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

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

Two tight sentences, front-loaded with the core action and scope, with no filler. Every clause (frames API, default tag) carries 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?

With readOnly annotations covering safety, fully documented params, and no output schema requiring explanation, the description is nearly self-sufficient. It could be stronger by contrasting with compare_companies, but nothing essential for 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 schema already documents all six parameters, establishing a baseline of 3. The description adds a modest value by clarifying the default tag behavior ('company's own current XBRL tag unless overridden'), which the schema's tag field does not state, but adds no other parameter 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 (Rank) plus resource (a company against ALL SEC filers) and the mechanism (frames API) for one metric and period. It is clear what the tool does, but it never names its closest sibling compare_companies, so the agent must infer the distinction.

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

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

The description implies the use case (cross-filer ranking for a single metric/period via the frames API) but offers no explicit when-to-use vs when-not, and does not route the agent to compare_companies for multi-company comparisons. The 'unless overridden' clause hints at default behavior but is not framed as 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety and scope are covered structurally. The description adds useful provenance (data comes from 10-Q filings), but says nothing about return ordering, fiscal-quarter labeling, or how missing quarters are handled.

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; the resource and scope lead. It is efficiently sized, though the terse phrasing borders on under-specification rather than being a model of clarity.

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 read-only tool with 100% schema coverage and no output schema, the definition is adequate but thin: it never indicates the shape of the returned trend series (quarter labels plus values) or the ordering, which an agent would want since no output schema exists to fall back on.

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%, with the metric enum-like list, ticker format, and periods default/max all documented in the schema. The description's metric examples merely restate what the schema already provides, so the baseline 3 applies.

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

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

States a specific retrieval ('quarterly trend for a key metric') plus the data source ('from 10-Q filings'), which implicitly separates it from annual-oriented siblings like get_annual_growth and from raw-fact tools like get_10q_facts. It does not explicitly name any alternative, so it stops 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?

There is no when-to-use guidance, no prerequisites, and no mention of which sibling to pick for related needs (e.g. annual trends, full statements, or peer comparison). The only hint is the '10-Q filings' source phrase, which is implied rather than stated as a selection 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety behavior is covered. The description adds provenance and a real constraint (data comes only from the latest 10-K, segment dimensions are absent from companyfacts), but says nothing about what happens when a company reports no segments or when parsing fails.

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 sentence, front-loaded with what is returned, with provenance and the sibling distinction packed into a tight parenthetical. 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 read-only retrieval tool with no output schema, the description covers what data comes back and where it comes from, but not the shape of the result (per-period vs latest-only, segment-level rows) or empty-result behavior. 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 description coverage is 100%, so ticker, metric (default revenue), and periods (default 3, max 5) are already documented in the schema. The description adds no syntax, valid metric keys, or period-format guidance beyond that 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?

States the resource precisely (metric broken down by business segment, product line, or geography) and names its data origin (latest 10-K XBRL instance). It also explicitly distinguishes itself from the companyfacts-based siblings by noting those carry no segment dimensions, so an agent can route correctly.

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 parenthetical that companyfacts carries no segment dimensions is an implicit routing rule: use this tool when segment/product/geography breakouts are needed, not get_company_facts. It stops short of an explicit 'use X when Y' statement, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description usefully adds the source concept and newest-first ordering, but says nothing about return shape, units (shares vs. millions), 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?

A single tight sentence, front-loaded with the resource and followed by the concept source and ordering. Nothing is wasted or redundant.

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 read-only retrieval tool with a fully documented two-parameter schema and no output schema, the description covers what is needed. The only gap is the absence of any note on returned units or field shape, which is a minor omission.

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%, with both ticker and periods (default 8, max 40) documented in the schema. The description adds no parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (get shares outstanding) and adds the XBRL concept tag dei:EntityCommonStockSharesOutstanding and ordering ('latest first'). It is clearly differentiable from siblings like get_dividend_payments or get_company_facts, though it does not explicitly name an alternative.

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 prerequisites, and no reference to alternatives among the 20+ sibling tools. The only hint is 'latest first', which implies recency ordering but not selection context.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful scope fact that it searches ALL SEC filers (open world) and names the returned fields, but says nothing about ordering, matching algorithm tolerance, or truncation 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 identifies the operation, its scope, and its return shape with 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 simple two-parameter read-only search with no output schema, the description covers purpose, scope, and returned fields adequately. The one meaningful gap is disambiguation from lookup_company, the sibling most likely to be confused with 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?

Schema coverage is 100%, so both parameters (query, limit) are already documented in the schema, including the 'apple'/'berkshire' examples and the max-25 cap. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (fuzzy search) and resource (company-name across all SEC filers) and previews the return fields (tickers, CIKs, exchanges). It does not, however, distinguish itself from the close sibling lookup_company, which an agent must choose between.

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?

Usage is only implied: the word 'fuzzy' hints at partial-name/ticker lookups, but the description never says when to prefer this over lookup_company or search_filings. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the shape of the payload (filing dates, descriptions, EDGAR archive URLs), which matters because no output schema exists, but says nothing about pagination limits, ordering, or empty-result behavior.

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

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

Two sentences, zero filler, with the resource and its scope front-loaded before the filter and return details. Every clause carries information the agent can act on.

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 read-only list tool with no output schema, the description covers what is returned and how to narrow results, which is the essential information. It falls just short of complete because pagination/ordering behavior and the distinction from search_filings are left 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 all three parameters are documented in the schema, making 3 the baseline. The description's enumeration of form types (10-K, 10-Q, 8-K, 4) modestly extends the schema's single 10-K example but adds no semantics for ticker or limit.

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?

Clear verb+resource: lists recent SEC filings for a company, with the scope narrowed to 'recent' and a stated filter dimension (form type) plus the returned fields. It does not name or distinguish itself from close siblings such as search_filings, get_filing_counts, or get_filing_documents, so an agent must 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?

Usage is only implied: 'Recent filings for a company' plus 'filterable by form type' sketches the use case, but there is no explicit when-to-use/when-not or pointer to an alternative like search_filings for keyword or historical queries. The agent gets context but no routing logic.

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

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

Annotations already declare readOnly=true, destructive=false, and openWorld=true (external network call), so the safety profile is covered. The description adds genuinely new behavioral context: it identifies SEC EDGAR as the upstream source (a public, rate-limited, external registry) and enumerates what comes back, which matters since there is no output schema. It stops short of noting failure modes for invalid or non-US tickers.

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 sentence with zero filler: verb first, source second, return fields last. The colon-delimited field list is compact and front-loaded. 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?

With one parameter at full schema coverage and no output schema, the description compensates well by enumerating the returned identity fields and naming the data source. What remains unaddressed is how this differs from the profile/ticker-search siblings and what happens on a miss (e.g., non-US or unlisted ticker).

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 ticker parameter is fully documented with an example (AAPL), so the schema does the heavy lifting. The description adds only the constraint that the ticker must belong to a US public company. 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?

States a specific verb ('look up'), a bounded resource ('a US public company's identity'), the data source (SEC EDGAR), and the exact fields returned (CIK, legal name, exchange, SIC, state of incorporation, fiscal year end). This makes the tool's scope immediately legible. It does not, however, distinguish itself from siblings like get_company_profile or get_ticker_search, which plausibly overlap.

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 alternative, despite a crowded sibling set that includes get_company_profile, get_ticker_search, and get_company_facts. The agent must infer that this is the identity-resolution entry point. Usage is implied only by the phrase 'identity'.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine behavioral context the annotations don't: the fallback to a recent-filing listing when the search index is unreachable, which materially changes what the agent will receive. It omits ranking/pagination behavior, keeping it short of a 5.

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

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

Two tight sentences with zero filler. The primary capability is front-loaded and the fallback caveat follows, making it easy to scan.

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 read-only search with no output schema, the description covers purpose, scope, and the important degraded-mode behavior. Return-shape details (result fields, ordering) are absent but are the only notable 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%, so the schema already documents query, ticker, form, and limit (including defaults and the max-40 cap). The description adds no parameter-level detail beyond the general search scope, so the baseline 3 applies.

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

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

States a specific verb (full-text search) and resource (SEC filings), plus the content types covered (risk factors, MD&A, disclosures). An agent can distinguish it from get_filing_text or list_filings by the 'across filings' scope, though no sibling is named 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?

No when-to-use guidance: it never says to prefer this over get_filing_text (single filing) or list_filings (enumerate filings), nor does it mention prerequisites or exclusions. The only conditional statement concerns internal fallback behavior, not tool selection.

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