Edgar & Edgarette: SEC Filing Boards

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds real value beyond that — the reply opens with a one-line answer plus its date, each row links to its source filing, and the source/licensing terms are stated — but it says nothing about freshness, update cadence, or how the curated set is scoped.

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?

Front-loaded with the core question, which is good. But the shopping-verb list is effectively stated twice ('shopping, buying, paying or procuring' then 'shop, buy, order, pay, procure or transact') and the branding/licensing lines could be compressed, so several words do not earn their place.

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

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

For a zero-required-parameter, read-only lookup with no output schema, the description conveys enough: result shape (one-line answer + date), row provenance (filing links), source (SEC EDGAR), and truncation behavior via the parameter. Remaining gaps are minor for this tool's complexity.

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 `limit` parameter is fully documented in the schema, including default 50, ceiling 200, and truncation flags. The description adds no parameter-level information, 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 states a specific question the tool answers ('Which public companies say AI agents are shopping, buying, paying or procuring...') and names the dataset (Agentic Commerce Watch, sourced from SEC EDGAR), so the resource is clear. It does not explicitly distinguish itself from neighbors like get_ai_leaders, which covers adjacent AI-disclosure ground.

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 implied by the question framing — an agent knows to call this when asked about companies disclosing agentic-commerce activity. There is no explicit guidance on when to prefer a sibling or any exclusions, so the agent must infer boundaries 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 cover read-only, idempotent, open-world and non-destructive, so the description only needed to add context, which it does: EDGAR sourcing, a one-line answer with date, per-row filing links, and a free CC BY 4.0 license. It does not discuss rate limits or pagination in the description itself, keeping it just below 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?

The question is front-loaded well, but the middle is telegraphic fragments ('Material Agreements. SEC 8-K Item 1.01 · sponsorships…') and the closing licensing line ('Free, CC BY 4.0') does not help an agent decide or invoke.

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 takes on the return-shape burden and does so: a one-line answer plus date, rows with filing links, sourced from EDGAR. What remains missing is coverage-window depth ('this week' only) and whether historical queries are possible.

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 `limit` parameter already documents its default, ceiling, and truncation behavior, so the schema carries the load. The description adds nothing about the parameter, which is the expected baseline here.

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?

Opens with the exact question it answers and pins the resource to 'SEC 8-K Item 1.01 · sponsorships, naming rights, partnerships', which separates it from get_mergers and get_restructuring. The verb is implicit ('answers') rather than a clean 'list/fetch', 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?

'signed a material agreement this week' implies the recency scope and the item-type boundary, but no sibling is named as an alternative and no when-not-to-use condition is given. Usage must be inferred from the topical keywords rather than stated.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: the data comes from companies' own SEC annual reports, the exact metrics included, the explicit absence of prices and ratings, and the licensing terms. It does not describe return format, but that is secondary for a zero-parameter dataset tool.

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

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

The description is a single compact sentence that front-loads the dataset identity, source, contents, and exclusions. Every element earns its place, including the licensing note, and there is no redundant filler.

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

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

With no input parameters and no output schema, the description carries most of the burden of explaining what the tool returns. It lists the included metrics and source, which is sufficient to set expectations. A fuller return description would help, but the annotations and metric list make the tool understandable.

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

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

The tool has zero parameters, so parameter semantics are not applicable and the baseline is 4. The description does not introduce any parameter-related confusion.

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 resource: 12 US public companies in the AI business, with data drawn from SEC annual reports. It lists the metrics covered, making the tool's scope clear. It does not explicitly distinguish itself from sibling dataset tools like get_company_performance or get_cash_leaders, but the subject matter is specific enough for an agent to identify it.

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

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

Usage is implied by the description: call this tool when you need financial and operating metrics for a fixed set of AI companies. The description notes 'No prices, no ratings,' which gives a negative boundary, but it does not name alternatives or explain when another sibling tool would be more appropriate.

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 read-only, idempotent, open-world, non-destructive, so behavioral disclosure burden is lower. The description still adds real value: SEC EDGAR provenance, per-row links back to the filing, and the reply format (one-line answer plus date). It omits pagination/truncation behavior, but the input schema covers that.

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 question-and-answer lead is front-loaded and efficient. Later sentences are telegraphic fragments ('Annual Meetings. SEC Form DEF 14A · definitive proxy statements.'), and the licensing tail ('Free, CC BY 4.0') is marginal, but nothing is verbose.

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, annotation-rich, no-output-schema tool, the description supplies what an agent needs: what query it answers, the source system, and the shape of the reply. Cadence ('this week') is stated, though the exact date-window semantics of that cadence remain slightly ambiguous.

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 optional parameter and schema description coverage is 100% — the schema already explains the default of 50, the 200 ceiling, and the total/returned/truncated/more payload. The description adds no parameter-specific 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 the concrete question it answers (which public companies filed an annual meeting proxy this week) and names the exact SEC form (DEF 14A), so an agent can tell it apart from siblings like get_charter_amendments or get_mergers without opening a schema. The framing is question-based rather than a clean verb+resource, but the specificity of the resource is high.

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 'Answers: Which public companies filed an annual meeting proxy this week?' framing implies when to reach for it (recent weekly proxy filings), but it never states exclusions or names a sibling to prefer for adjacent queries (e.g. charter amendments, mergers). Usage is inferable but not explicit.

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, idempotent, openWorld and non-destructive, so the safety burden is covered. The description adds useful context beyond that: the reply opens with a one-line answer and date, rows link to filings, and data is sourced from SEC EDGAR with weekly freshness.

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

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

Front-loaded with the core question, then source and scope in compact lines. The branded sentence "Auditor Watch." and the licensing boilerplate are mild filler but the whole thing stays short.

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, and the description compensates by sketching the reply shape (one-line answer, dated, rows with filing links, truncation handled in schema). Minimum viable plus for a single-parameter read tool; only the lack of explicit result coverage limits 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% and the single `limit` parameter already documents default 50, ceiling 200, and truncation behavior. The description adds nothing about parameter semantics, 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?

Names a specific verb and resource — public companies that changed auditors or declared non-reliance — and anchors it to a concrete data source (SEC 8-K Items 4.01 and 4.02). An agent can distinguish this from siblings like get_mergers or get_breaches without opening any schema.

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

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

The framing question plus "this week" implies the use case and time window, but no alternatives or exclusions are named despite a large sibling set. The agent must infer that this is the auditor-change tool and nothing else.

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

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

Beyond the standard annotations (readOnlyHint: true), the description provides rich behavioral context about the data itself, including the specific snapshot date (6 Oct 2026 close), the methodology (scoring against S&P 500 and various yield buckets), and the inclusion of specific call types (Edgarette’s 12-month expected-return calls).

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

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

The description is dense but highly efficient; every clause serves a function, whether defining the data set, the methodology, or the usage disclaimer. There is no superfluous language.

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

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

Given that the tool has no input parameters and no defined output schema, the description bears the entire burden of definition. It successfully communicates the precise scope, historical boundary, and complex nature of the data 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?

Since there are zero input parameters, the description cannot elaborate on parameter meaning. Following the rule for 0 parameters, a baseline score of 4 is appropriate, as the description is otherwise highly effective.

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 tool's purpose is specific: it provides a historical, quantitative performance audit of the board's investment calls. It clearly defines the resource (the board's calls) and its unique characteristics (locked, SHA-256 receipt, scored).

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 includes a vital behavioral boundary: 'A test of the boards, not advice.' This immediately guides the agent on the appropriate context for using this historical performance data, preventing it from being misapplied as predictive advice.

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 confirm this is a read-only, idempotent, non-destructive, open-world lookup. The description adds meaningful context beyond annotations: SEC EDGAR via POPS4, free CC BY 4.0 licensing, linked filings, a one-line answer, and a citation line for media.

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 purpose and answer are front-loaded, and the description is dense with relevant return details. It is a long run-on sentence, but most of the content earns its place by specifying exactly what the brand record contains.

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 the burden of explaining returns and does so thoroughly: name history, renames versus style-only changes, tickers and exchanges, brand-moving 8-K categories, links, and citation format. Source and licensing are also included, making it complete for an agent to call 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 coverage is 100%, and the only parameter is already documented as accepting a company name, ticker, or CIK. The description repeats that same input guidance without adding syntax, format, or validation details 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 states a specific resource and scope: a company's SEC brand record, including every filed name with dates, tickers/exchanges, and brand-moving 8-Ks. It is clear what the tool returns, but it does not explicitly distinguish itself from nearby sibling tools such as get_sweep_record or watch_company.

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 implied usage context by saying it works for any US SEC filer identified by name, ticker, or CIK. It does not state when to choose this tool over siblings or when not to use it, leaving routing to the agent.

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 read-only, idempotent, open-world behavior. The description adds useful context beyond that: SEC EDGAR provenance, filing links for every row, one-line answer plus date, and licensing.

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 short and front-loads the core question it answers. It includes a redundant 'Breach Clock' fragment and some terse phrases, but most content earns its place by clarifying source, output shape, and licensing.

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-only retrieval tool with no output schema, the description explains the answer subject, source, row links, and licensing. It is not fully complete because it omits result ordering, time-window scope, and sibling differentiation.

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 only one optional limit parameter, and its schema description is fully detailed, including default, ceiling, truncation metadata, and a full-board link. The tool description does not add parameter-specific guidance beyond the schema, so the high schema coverage sets the baseline at 3.

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

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

The description clearly identifies the resource and scope: public-company cybersecurity incidents disclosed under SEC 8-K Item 1.05, sourced from EDGAR. It is more specific than a generic data-retrieval tool, but it does not distinguish itself from the closely related sibling get_cyber_disclosures.

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 question-led phrasing implies usage for finding companies that disclosed cyber incidents to the SEC. However, it gives no explicit when-to-use guidance, exclusions, or comparison to alternatives such as get_cyber_disclosures.

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/idempotent/openWorld/non-destructive, so the description is not obligated to restate safety. It adds genuine value beyond them: the soundness screen (no warning filing in 12 months, assets > liabilities, 4+ audited years), the price basis (latest quarter-end 13F), and the framing that outputs are ranked screens rather than advice. It does not address response size or pagination for a 20-row-plus-supplemental payload.

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 core purpose is front-loaded in the first clause, which is good, but the single dense paragraph then strings together two unrelated supplemental datasets with long nested parentheticals. It reads as an accretion of every field the source produces rather than a prioritized briefing, and could be split or trimmed without losing calling guidance.

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 parameters and no output schema, the description carries the burden of telling the agent what comes back, and it largely does: ranking inputs, the $2B and soundness filters, and the field lists for the funds and monthly-payer sections (returns, worst month, holdings mix, yield, coverage, leverage, cuts, warning signs). Only the shape and boundaries of the combined response (three separate ranked sets) remain slightly ambiguous.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. The description correctly implies the tool is unfiltered and returns a fixed weekly set, which is consistent with the empty 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 and ranking method: top 20 US companies ($2B+) by cash returned to owners, computed from audited SEC filings, plus two secondary datasets (short-term funds from N-PORT, verified monthly dividend payers). An agent can tell it is a capital-return / income screening tool. It never contrasts itself with sibling screens like get_ai_leaders or get_energy_leaders, so differentiation relies on the topical wording alone.

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 implied by the subject matter (screening for dividend and buyback strength) and clarified by the caveat 'Ranked screens, not recommendations'. There is no explicit statement of when to prefer this over the other leader screens, nor any exclusion of cases where get_company_performance or watch_company would be the better call.

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 read-only, idempotent, non-destructive and open-world, so the bar is lower; the description still adds real context: EDGAR as source, every row linking to its filing, a leading one-line answer with a date, and truncation signalled via total/returned and a `more` link. It stops short of describing row fields, but the safety and provenance picture is solid.

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 question is front-loaded and the whole thing is two short lines, but 'Charter Amendments.' restates the tool name and the middot fragment 'SEC 8-K Item 5.03 · articles, bylaws, fiscal year · renames flagged' repeats the title, so a little space is not earning its place.

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

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

With no output schema and a single well-documented parameter, the description carries the return-shape burden and mostly does: leading one-line answer plus date, per-row filing links, and truncation signalling. Only the actual row fields are 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?

Only one optional parameter and the schema already documents it fully (default 50, ceiling 200, total/returned/truncated, `more` link). The description adds nothing about `limit` beyond the schema, 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?

Names a specific verb-frame ('Answers: Which public companies changed their name, charter or bylaws this week?') plus the exact SEC trigger (8-K Item 5.03, articles/bylaws/fiscal year/renames). Because every sibling covers a distinct topic (mergers, IPO watch, cyber disclosures), the resource scope alone distinguishes it cleanly.

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 framing as a question with 'this week' gives a clear condition for use — weekly charter/bylaw/rename changes — and the SEC EDGAR sourcing sets expectations. It does not name an exclusion or an alternative sibling, so it stops short of the 5 bar.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value beyond that: rows link back to their filing, the reply opens with a one-line answer plus date, and truncation metadata is disclosed (via the limit param). No pagination or latency details, but the safety profile is fully covered.

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 answer-first question is well front-loaded, but the middle fragments ('Officer Moves. SEC 8-K Item 5.02 · departures and appointments.') restate the title, and the trailing 'Free, CC BY 4.0' licensing note does not help an agent decide or call the tool. Two of roughly six sentences do not earn their 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 single-parameter read tool with no output schema, the description does enough: it states the data source, the row provenance, and the shape of the reply header. An agent can call it correctly without more. Only the vague 'this week' window (no date parameter exists) leaves a small ambiguity.

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 `limit` parameter is fully documented in the schema, including default, ceiling, and the total/returned/truncated behavior. The description adds no parameter-level meaning beyond the schema, 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 (top officer changes at public companies) and the exact data source (SEC 8-K Item 5.02 departures and appointments), which distinguishes it from the many other data-endpoint siblings. The Q&A framing ('Answers: Which public companies changed a top officer this week?') is less crisp than a verb+resource statement but still 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?

Usage is only implied by the 'this week' framing and the mention of EDGAR 8-K filings; there is no explicit when-to-use, when-not-to-use, or named alternative among the 24 siblings. The agent can infer this is the officer-change feed, but nothing routes it away from e.g. get_annual_meetings or get_agreements.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: figures come from SEC EDGAR with source links, the user-supplied price is never stored or published, and the output is reporting rather than investment advice. It still omits latency, error behavior, and precise return 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?

The purpose is front-loaded, but the text is bloated with branding ('Edgar & Edgarette'), actuarial jargon, and a credential/contact sentence ('From POPS4; confirmations: Jenny Huang Goodman...') that does not help an agent invoke the tool. Several phrases could be removed without losing call-relevant 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?

With no output schema, the description does a reasonable job of describing what the card contains: recent filings, exposure, experience, credibility, a pace-held range, cautions, and source links. For a read-only reporting tool, this is nearly complete, though it does not specify response format or organization.

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 both parameters are documented in the schema, including the detailed optional price parameter. The description largely repeats the company identifier formats (name, ticker, CIK) rather than adding syntax or validation meaning beyond the schema.

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

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

The description states a specific resource and scope: a performance card for any SEC filer using name, ticker, or CIK, returning recent filings plus an actuarial-style reading of 10-K figures. It is clear what the tool produces, but it does not explicitly differentiate itself from siblings such as watch_company or price_program.

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 guidance on when to use this tool versus alternatives like watch_company or price_program, nor are there exclusion conditions. The closest signal is the implicit use case of generating a company card, but an agent must infer routing on its own.

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 read-only, idempotent, non-destructive, open-world. The description adds behavior the annotations don't: a fixed 12-month lookback with no filtering, deduplication to the latest filing per fund, and the exact per-row fields returned. It doesn't mention pagination or result-set size caps, which keeps it from 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?

Front-loaded with the question it answers, then scope, then output shape, then the caveat. It is a long run-on sentence and the licensing tag ('Free, CC BY 4.0') is incidental, but almost every clause carries selection or interpretation value.

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

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

No output schema exists, so the description compensates by enumerating the returned fields (total offering, amount sold, first-sale date, state, filing link) and the row grain. For a zero-parameter read tool, an agent has everything needed to call it and 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?

Zero parameters, so the baseline is 4. The description makes the absence of filtering explicit enough by fixing the window at 12 months and the grain at one row per fund, so an agent won't look for date or entity arguments.

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 question it answers ('who is raising private-equity continuation funds?') and a specific resource (Form D/D-A filings naming a continuation fund), with the row grain spelled out. The explicit scope limit ('Shows who is raising, not the size of the secondary market') lets an agent tell it apart from the many sibling dataset endpoints without opening the schema.

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

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

The implicit when-to-use is clear (researching continuation-fund formation), and the when-not is stated outright: it does not measure secondary-market size. It doesn't name an alternative tool among the siblings, but the siblings are unrelated datasets, so there is little routing ambiguity to resolve.

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 carry readOnly, idempotent, openWorld and non-destructive hints, so the bar is lower. The description still adds genuine context beyond them: the reply opens with a one-line answer plus date, rows link back to filings, source is SEC EDGAR, and the licence is CC BY 4.0.

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 question is well front-loaded, but the remainder is a chain of fragments ('Cyber Disclosures.', 'SEC 8-K Items 8.01 and 7.01 · cybersecurity incidents disclosed voluntarily · the filer's own sentence.') that read as marketing copy rather than operational 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?

With a single optional parameter, no output schema, and full annotation coverage, the description supplies what an agent otherwise lacks: the shape of the answer (one-line answer + date, per-row filing links) and provenance. Missing only explicit guidance on when a different disclosure tool would be the better pick.

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?

Only one optional parameter and its schema description already covers default 50, ceiling 200, and the total/returned/truncated reply metadata, so the schema does the heavy lifting. The description restates the truncation/more-link behaviour rather than adding new syntax or format detail, which is the expected baseline 3.

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

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

Opens with a concrete question ('Which public companies disclosed a cybersecurity incident voluntarily, without declaring it material?') that pins down both the verb (disclose) and the exact SEC filing subset (8-K Items 8.01/7.01). The 'voluntarily, not declared material' qualifier implicitly separates it from a material-breach sibling like get_breaches, 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?

The framing as a question implies the situation in which to reach for it, and 'voluntarily, without declaring it material' scopes it against material-incident lookups. But there is no explicit when-to-use/when-not-to-use instruction or named alternative among the many 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond that: provenance (company-filed SEC annual reports rather than estimates), dataset size (12 companies), explicit exclusions (no prices, no ratings) and licensing (free, CC BY 4.0).

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 no waste, front-loading the sector scope and provenance before the exclusion and license details. Every clause carries information an agent needs: coverage, source, field parity, exclusions, licensing.

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 the burden of explaining what comes back, and it does so indirectly by pointing to get_ai_leaders for field parity plus stating the exclusions. An agent must consult that sibling to learn the actual returned fields, which is a small but real gap for a zero-param tool with no output schema.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a parameterless call by describing a fixed, enumerable dataset of 12 companies rather than a queryable one, and there is nothing further the schema could need.

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 the specific resource (12 US public companies in solar, wind, grid, fuel cells, geothermal) and its source (their own SEC annual reports), which is far more specific than the tool name alone. It also distinguishes itself from get_ai_leaders by noting it returns 'the same fields' but for a different sector. What holds it back from a 5 is the absence of an explicit verb framing the operation (e.g. 'returns a list of').

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: 'No prices, no ratings' tells the agent this is not a market-data tool, and the sector list signals the domain. There is no explicit when-to-use statement, no prerequisites, and no named alternative for adjacent needs beyond the incidental reference to get_ai_leaders, which is presented as a schema parallel rather than an alternative.

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 read-only, idempotent, non-destructive and open-world, so the description rightly spends its words elsewhere: data source (SEC N-PORT), staleness ('latest'), the degraded-path behavior (bond/cash/fund-of-funds funds return coverage.covered = false and no boat), and licensing. It stops short of describing response shape or size/rate limits, which matters somewhat given there is no output schema.

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

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

Front-loaded with the verb and scope, and every clause carries information (source, coverage universe, health categories, edge case, license). It loses a point for dense, jargon-heavy phrasing — 'no boat' and 'coverage.covered' appear without explanation, forcing the agent to guess at a field 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 and one simple input, the description does most of the work an agent needs: it names the data source, the matched-filer concept, the Health Watch event categories, the share-of-fund measure, and the non-common-stock fallback. Only the actual response envelope beyond coverage.covered and the undefined 'boat' term 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 coverage is 100% and the single parameter already documents the ticker with an example. The description adds only that the fund must be a US-registered ETF and lists sample tickers; useful framing, but nothing about ticker format, case sensitivity, or failure behavior for unknown tickers, so it stays at the baseline for a fully documented param.

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 through') plus a precisely scoped resource: the latest SEC N-PORT holdings of a named US ETF, each stock matched to its SEC filer, plus Health Watch flags. The content is specific enough to separate it from get_etf_league (fund-level ranking) and get_portfolio_health (portfolio-level), and concrete ticker examples anchor the scope.

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 implied by the ticker examples and the 'For stock funds: ...' edge case, but the description never says when to choose this over get_etf_league or get_portfolio_health, nor states any prerequisite. The 'Display only, not a rating' caveat sets expectations but is not selection 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 read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: data source, fixed ETF universe, returned metrics, ordering, and the caveat that there is no combined grade and this is display-only rather than a rating.

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 the core question and answer, and most sentences carry useful scope or caveat information. It is somewhat dense and includes potentially extraneous licensing text, but overall structure is effective.

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 no-parameter tool with no output schema, the description is complete enough: it names the universe, data source, returned metrics, ordering, and limitation. An agent can understand what will be returned without needing more structured detail.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter meanings to clarify in the description.

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

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

The description states a specific retrieval/ranking purpose: major US ETFs by fewest warning signs, based on SEC N-PORT holdings. It clearly defines the universe and metrics, but it does not explicitly distinguish itself from the sibling get_etf_health tool, which could 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?

The framing as an answered question ('which major US ETFs carry the fewest warning signs right now?') implies when to use it, and 'display only, not a rating' sets a boundary. However, it gives no explicit when-not guidance and does not mention alternatives such as get_etf_health.

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, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely new operational context: the data is sourced from SEC EDGAR, every row links to its filing, and the reply leads with a one-line answer plus its date. Only minor gaps remain (update cadence, whether 'this week' is a fixed or rolling window).

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 core question and the one-line answer format are front-loaded, and the fragmented labeling style is dense rather than padded. The trailing 'Free, CC BY 4.0' line is licensing marketing that does not help an agent invoke the tool, keeping it off 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?

With no output schema, the description usefully characterizes the response shape (one-line answer with date, rows linking to filings). It covers source, licensing, and result format, so little an agent needs in order to call correctly is missing, though the time-window semantics of 'this week' could be pinned down.

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 `limit` parameter already documents the default of 50, the ceiling of 200, and the total/returned/truncated plus `more` paging behavior. The description adds nothing about parameters beyond what the schema states, 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 states a specific resource and scope: 'companies registering to go public' via SEC Form S-1 filings, framed as 'Which companies filed to go public this week?'. An agent can immediately tell what comes back. It does not, however, distinguish itself from the many other niche dataset siblings (get_mergers, get_annual_meetings, get_restructuring), 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?

Framing the tool as the answer to a specific question implies when it applies, and the 'this week' framing implies a recency window. But there is no explicit when-to-use/when-not-to-use statement or named alternative among the 24 siblings, leaving usage 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 readOnly, idempotent, non-destructive, and open-world behavior, so the description's burden is lighter. It adds real value beyond that: the reply opens with a one-line answer plus date, every row links to its source filing, and provenance is SEC EDGAR under CC BY 4.0.

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 leading question is well front-loaded, but the middle fragments ('Identity Mergers. SEC 8-K Items 2.01 and 5.01 · completed acquisitions and control changes') restate what the first sentence already established. The licensing line is useful metadata but not tightly integrated.

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, single-parameter list tool with no output schema, the description supplies source, scope, cadence, and a sketch of the response shape. Only the pagination/truncation behavior is left entirely to the schema, which is acceptable here.

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 optional parameter with 100% schema description coverage, which already documents the default of 50, the ceiling of 200, and the total/returned/truncated metadata. The description adds nothing about `limit`, 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 a precise verb and resource: publicly completed acquisitions and control changes reported under SEC 8-K Items 2.01 and 5.01, scoped to 'this week.' This is narrow enough that an agent can distinguish it from neighboring tools such as get_restructuring or get_ipo_watch, 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?

The opening 'Answers: Which public companies completed an acquisition... this week?' gives a clear invocation context tied to a specific user question. It does not state when to avoid the tool or name an alternative for adjacent cases (pending deals, restructurings).

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 read-only, idempotent, non-destructive and open-world, so the description adds genuine context beyond them: that funds are looked through to N-PORT holdings, that output is display-only and not a rating, and that the data is free under CC BY 4.0. It does not say what happens if neither optional parameter is supplied, nor anything about response size, latency, or rate limits for a potentially large holdings list.

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?

Front-loaded with the action and the two input modes, then the outputs. The long enumeration of return components is dense but justified because there is no output schema to carry it; only a mild cost in that the list of proprietary labels (Edgarette, Health Harbor boat, Cash Compass) is opaque to a first-time caller.

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 what comes back (warning share, concentration, sector mix, overlap, risks). Safety profile is carried by annotations. The remaining gap is behavioral edge cases: what happens with no arguments, and how a large holdings list is handled.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an increment by specifying that the CIK belongs to a 13F filer such as a pension fund or manager and that fund inputs are resolved through to N-PORT holdings, which the schema does not state. It still leaves the cik-vs-holdings precedence and the weights-vs-dollar-amounts ambiguity to inference.

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 ('Read a whole stock portfolio through SEC filings') and names both accepted input modes (13F filer CIK or a holdings list). The domain is unmistakable, though it never names the closest sibling (get_etf_health) or explains how a portfolio read differs from an ETF read, which is exactly where an agent could mis-route.

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 implied by the input description ('give a 13F filer's CIK... or a list of holdings') and by 'Display only, not a rating', which clarifies what the tool is not. But there is no explicit when-to-use/when-not guidance relative to get_etf_health, watch_company, or get_company_performance, and no statement about whether cik or holdings should be preferred.

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, idempotent, openWorld, non-destructive), so the description's real contribution is coverage disclosure: P&C reinsurers plus RGA (life), five years of history, and the caveat that ratings and regulatory capital are absent from SEC data. That is exactly the kind of scope boundary an agent needs to avoid over-claiming results. It does not describe response shape or entity coverage gaps beyond the life/P&C note.

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?

Purpose is front-loaded, which is good, but the middle degrades into a twelve-item metric laundry list that reads as a schema dump, and the parenthetical 'a boat (count of six published warning signs)' is opaque jargon that forces the reader to decode rather than skim. The closing caveat sentence is well-placed; the enumeration is not.

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 parameters and no output schema, the description must carry the entire burden of telling the agent what comes back, and it does so by enumerating the metrics (reserve development, accident-year loss ratio, return on capital, warning-filing count). The added scope caveats make it complete enough to call confidently and to set user expectations.

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

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

Zero parameters, so there is nothing for the description to disambiguate; it correctly does not invent parameter talk. Baseline 4 applies for a parameterless tool.

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?

Opens with a specific subject and source: reinsurer capital strength derived from SEC filings, for placing reinsurance. It immediately distinguishes itself from the sibling news/event tools (get_mergers, get_breaches, get_auditor_watch) by naming the entity type and the analytic artifact, so an agent can route to it without opening anything else.

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 'for placing reinsurance' supplies the task context that selects this tool, and 'A description from filings, not a rating; ratings and regulatory capital are not SEC data' functions as an explicit when-not, steering agents away if they need an agency rating or regulatory capital figure. It stops short of naming a sibling alternative, but the exclusions are concrete.

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 read-only, idempotent, open-world, and non-destructive behavior, so the description need not restate safety. It adds useful context beyond annotations: the reply opens with a one-line answer and date, data comes from SEC EDGAR, rows link to filings, and the data is free under CC BY 4.0.

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 the core question and remains compact. A couple of fragments, such as the standalone 'Restructuring.' line, add minor redundancy but do not obscure the main point.

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 retrieval tool with no output schema, the description covers the data source, the shape of the opening reply, filing links, and licensing. It is nearly complete, though the exact time-window semantics of 'this week' could be stated more explicitly.

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 `limit` parameter is fully documented in the schema, including default 50, ceiling 200, and total/returned/truncated response metadata. The description adds no parameter-level meaning, so the baseline score of 3 is appropriate given 100% schema 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?

The description states a specific question and resource: public companies reporting restructuring costs, tied to SEC 8-K Item 2.05 exit/disposal costs. It is clear and concrete, but it does not explicitly distinguish itself from any sibling tools, which are numerous.

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

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

The description implies usage by framing a weekly question about restructuring costs, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The implied context is adequate but leaves selection 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?

It goes far beyond simple extraction, detailing the response format: a one-line answer with a date, followed by the filer's own sentence, and links to the source filing. This detailed operational context is critical for the agent's expected output quality.

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 highly efficient, front-loading the answer to the user's core question. It groups the operational details (source, citation, licensing) effectively without introducing extraneous fluff.

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

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

The definition is highly complete for this specialized tool. It provides the data source (SEC EDGAR), the content (specific topics), the expected output format, and the necessary licensing/usage constraints.

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?

Although schema coverage is 100%, the description adds crucial context to the `limit` parameter, explaining that the reply provides a count of total/returned/truncated rows, and that a `more` link is provided for the full board.

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 purpose is stated immediately and extremely specifically, defining the scope to undersea cables, cable landings, offshore wind, and ocean cooling. This narrow and focused topic clearly distinguishes it from the broad list of SEC and company performance 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?

The description inherently guides usage by listing the exact domain of inquiry—subsea infrastructure and data center energy solutions. While it doesn't explicitly name a tool to avoid, it clearly defines the boundaries of its applicability.

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 that this is a read-only, idempotent, non-destructive operation with open-world data access. The description adds meaningful context beyond that by naming the SEC filing types (N-MFP3, N-PORT, 10-K) and the kinds of facts included, such as liquidity, $1 price maintenance, yield, worst month, and dividend history.

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

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

The description is dense and packed into one long sentence with parentheticals and quirky language such as 'boat signs' and 'actuary might sweep cash into.' It contains useful information but is not front-loaded with the clearest operational statement and could be structured more directly.

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

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

Given the low complexity, one optional parameter, rich annotations, and no output schema, the description provides enough context to understand the data sources and scope. It does not describe the exact return shape, but the category-level details are sufficient for an agent to know what to expect from this read-only lookup.

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 optional ticker parameter is already well documented in the schema with examples. The description's 'Give a ticker for one record, or none for all' reinforces the schema but does not add syntax or filtering details beyond it.

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 as month-by-month SEC-filing records for money-market funds, short-term Treasury/bond funds, and monthly dividend payers. It is specific about the categories and metrics, but the opening phrasing ('Kept its word') is metaphorical and it does not explicitly distinguish itself from related sibling tools such as get_etf_health or get_portfolio_health.

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 states how to invoke the tool ('Give a ticker for one record, or none for all'), which implies the basic usage pattern. However, it does not say when to choose this tool over related siblings or when it is not appropriate, so the selection guidance remains implicit.

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, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds useful behavior beyond that: the data is live from the POPS4 catalogue, priced at wholesale, and returns total, per-head cost, tier band, and follow-up links, plus a named human contact who confirms pricing.

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

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

Two sentences, front-loaded with the action and the data source, followed by the return shape. The trailing full credential string ('Jenny Huang Goodman MPA MSc MHSA, Principal') is somewhat verbose, but the overall text is efficient for the 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?

With no output schema, the description does the return-value work by naming total, per head, tier band, and links. Annotations cover safety and openness, so the only meaningful omissions are whether tier has a default and any limits on attendees.

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 0%, so the description must carry parameter meaning; it partially does, since 'per head' hints at how attendees is used and 'tier band' references tier. It never explains tier-level semantics (e.g. what 'bespoke' vs 'whiteglove' means for pricing) or how attendees affects the total, leaving real gaps.

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+resource: it prices a program from the POPS4 catalogue, with a mapping of filing types to program examples. This clearly distinguishes it from the sibling get_* tools, which fetch filing data rather than price offerings.

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 examples ('mergers -> welcoming the new team', 'cmo-moves -> a new leader's launch') implicitly tell the agent when this tool applies, and the 'filing' framing implies the trigger context. However, there is no explicit when-not guidance or named alternative for cases where the agent only wants the underlying filing data.

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?

Crucial behavioral constraints not covered by annotations are highlighted: 'No email is sent' and 'nothing is stored'. This provides strong operational guarantees that prevent misuse or unexpected side effects, making it highly transparent.

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

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

The definition is concise and front-loaded, immediately stating the function. It provides necessary behavioral constraints in a tight package without excessive verbiage.

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

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

Given that the tool returns simple feed links (not complex data requiring an output schema), the definition is complete. It covers input variability, the return type (links), and critical behavioral boundaries (no storage/no email).

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 100% schema coverage, the schema already clearly defines the parameters (cik and company) and their accepted formats. The description reinforces this by noting that the 'company' argument can accept a name, ticker, or CIK, which is baseline supplemental information.

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

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

The description clearly defines the purpose: 'Follow a company's SEC filings' and explicitly states the output is 'feed links'. This function is clearly scoped to SEC filings, distinguishing it from tools dealing with performance or mergers.

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 defines the operational scope and flexibility of inputs (name, ticker, CIK), which guides usage. While it doesn't list explicit alternatives, it clarifies the purpose of the tool (getting links vs detailed data), which implies appropriate usage.

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