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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely useful behavioral context beyond them: the EV construction formula and, importantly, the rule that multiples come back null with a reason when inputs are missing, negative, or not meaningful. That null-semantics disclosure is the kind of thing an agent needs to interpret results correctly.

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 field list, plus a definition sentence that earns its place. No filler or redundant restatement of the 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 only annotations covering safety, the description does list the return fields and null behavior, which is helpful. However it omits input semantics (tickers format/cardinality) and any routing guidance against the four sibling tools, leaving gaps for a look-up tool in a dense sibling 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?

The single parameter 'tickers' has 0% schema description coverage, and the description does not mention it at all. It never states that the input is an array of ticker symbols, whether they can be mixed across exchanges, or how many can be supplied in one call, so the description fails to compensate for the coverage gap.

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 (trading comparables) and enumerates the exact output fields it produces (market cap, EV, LTM revenue/EBITDA/net income, and the three multiples). An agent knows what it gets back, though the description never explicitly distinguishes this from get_financials or get_market_data, which overlap on raw financial metrics.

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, when-not-to-use, or prerequisite guidance is given, and no sibling tool is named. The agent must infer that this is the multi-ticker comparables tool versus get_financials or get_market_data 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 declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered without description text. The description adds that results include document links, a small but real piece of return-content context; it says nothing about ordering, recency window, or coverage 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?

Two short sentences, zero filler, with the core purpose front-loaded and the filter detail second. Nothing here 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?

An output schema exists, so return values need not be spelled out, and the annotations cover the safety profile. Still, for a 3-parameter tool at 0% schema coverage, the description leaves `limit` semantics and what 'recent' actually means undefined.

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 0% schema description coverage the description must carry parameter meaning, and it does clarify `forms` with concrete example values (["10-K", "10-Q", "8-K"]), which is genuinely useful since no enums exist in the schema. However `limit` (page size, max value, offset behavior) and the `ticker` format are left entirely to inference, so the compensation is partial.

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 pair ('Recent SEC filings') and adds that results carry document links, which is more than a restatement of the name. It is distinguishable from get_financials and get_market_data by the 'filings' framing, though it never explicitly names a sibling to contrast with.

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

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

The description offers no when-to-use context, no prerequisites, and no routing to alternatives such as get_financials for reported numbers. The only usage hint is the `forms` filter example, which is a parameter note rather than 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 readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds useful behavioral context beyond that: values are sourced from SEC XBRL, each carries its concept and filing accession, and the `filings` map resolves accessions to URLs. It stops short of covering freshness or pagination, so not 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 sentences, front-loaded with the resource and scope, then the payload contents. No filler and no 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 carries the return-value burden and does so well by naming statement groups, derived metrics, and the accession/URL mapping. It is not fully complete because parameter behavior (notably `years`) goes unexplained and no usage routing is offered.

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 0%, so the description must compensate. It partially does: 'annual (and LTM)' maps to the include_ltm toggle, and 'filings' explains an output field. However, `years` (default 5) is never explained in scope or behavior, leaving a real gap in a 3-param 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?

The description states a specific verb+resource (standardized financials from SEC XBRL filings) and enumerates the exact contents (income statement, cash flow, balance sheet plus derived EBITDA, FCF, total/net debt). This clearly separates it from siblings like get_market_data, get_filings, and get_comps without the agent opening a 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?

Usage is implied by the resource but there is no explicit when-to-use guidance or routing against siblings such as get_filings or get_comps. An agent can infer it is the financial-statement tool, but nothing states when to prefer 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 declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds value by disclosing the returned data content (share price, shares outstanding, market cap, beta), but says nothing about sourcing, latency, or freshness beyond the annotations. With annotations carrying the behavior burden, a 3 is appropriate.

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 no filler, and the most salient returned data is front-loaded. It is a 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?

With no output schema, the description correctly enumerates what is returned, and the read-only annotations cover safety. For a simple single-parameter retrieval tool this is nearly complete, only missing ticker format expectations and any usage context.

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

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

Schema description coverage is 0% and the single required 'ticker' parameter is never mentioned in the description. Since the tool needs a ticker and the schema does not explain its format or expectations, the description should compensate but does not. Only the SEC reference hints tangentially at the domain.

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 lists the concrete data returned (share price, SEC cover-page shares outstanding, market cap, 5-year monthly beta), which distinguishes it from siblings like get_financials and get_filings. It is a noun-phrase field listing rather than a verb+resource sentence, and it never explicitly states 'retrieve market data,' but the content is specific enough for an agent to identify the tool.

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

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

There is no guidance on when to use this tool versus lookup_company, get_comps, or get_financials, nor any prerequisites or conditions. The agent must infer usage purely from the returned-field list.

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, and openWorld, so the safety profile is covered. The description adds useful context (FRED as the upstream source, percent as the unit) but says nothing about freshness, caching, or failure behavior for an open-world network call.

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 the core purpose and source front-loaded and a useful usage note second. No filler to trim.

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 a default in the schema and no output schema, the description covers source, unit, and default guidance adequately. The main gap is enumeration of valid maturity values, which an agent would need.

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 0% for the single 'maturity' parameter, so the description carries the burden. It mentions '10Y' only as the usual rate, never explains accepted maturity values, format (e.g., '3M', '2Y'), or what happens on unsupported maturities.

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), resource (Treasury constant-maturity yield), source (FRED), and unit (percent). It is recognizable against siblings like get_market_data, though it does not explicitly state how it differs from the broader market-data tool.

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

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

'10Y is the usual DCF risk-free rate' gives implied usage context for the default case, but there is no explicit when-to-use guidance, no alternatives named, and no explanation of when a different maturity would be 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 declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety and reproducibility profile is covered. The description adds only that matching is on ticker or name; it says nothing about fuzzy vs exact matching, permissions, or result ordering beyond what structured fields provide.

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

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

Two short, front-loaded sentences with no filler; the purpose statement comes first and the return summary second. The return-field sentence is somewhat redundant given an output schema exists, keeping it just below full marks.

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?

An output schema already documents the returned fields and annotations cover safety, so the description need not explain return values. The remaining gaps are the meaning of 'limit' and matching behavior, which leave the definition only minimally adequate for a 2-parameter lookup 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 0%, so the description carries the burden and does partially compensate by explaining that 'query' accepts a ticker or a name. However, 'limit' is left completely undefined in both the description and the schema beyond its default of 10.

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 ('Find SEC registrants') plus the two accepted lookup keys (ticker or name), which is more precise than the bare tool name. It is distinguishable from siblings like get_market_data or get_filings, though it never explicitly contrasts itself with them.

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

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

The description implies the natural use case (resolving an entity by ticker or name) but gives no explicit when-to-use guidance, no prerequisites, and no mention of when an agent should prefer a sibling tool. Usage is inferable rather than stated.

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