Equitest

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the non-obvious fallback: on multiple name matches it returns candidate valuations instead of statements. That is exactly the kind of surprise behavior an agent needs warned about. It does not mention units, currency, or behavior when no company matches.

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

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

Two sentences, zero filler, with the primary return content front-loaded and the edge-case behavior trailing. Every clause carries information an agent would otherwise have to guess.

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 carries the return shape (statements by year plus derived EBITDA/margins, or a candidate list). For a read tool with full annotation coverage this is nearly sufficient; missing only minor details such as units/currency and the not-found case.

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 both parameters are documented, including that 'valuation' selects among several valuations of the same company, so the baseline is 3. The description's 'chosen by company name' and the multi-match note largely restate the schema rather than adding format, precedence, or partial-match semantics 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?

States a specific verb and resource (returns historical financial statements) and enumerates the returned artifacts: P&L, balance sheet by year, EBITDA, margins. It also discloses the ambiguity branch. It does not explicitly distinguish itself from the sibling get_company_valuation, so an agent must infer that one returns valuation data and this one returns statements.

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 rather than stated: the tool is selected by company name, and the 'if several valuations match' sentence tells the agent what happens in the ambiguous case. There is no explicit when-to-use versus get_company_valuation or when to call list_companies first to disambiguate, leaving the routing decision 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 the description layers real behavior on top: the fallback to candidate lists on ambiguous names, the always-included sections (company profile, weighted indication), and the unlock status / AI summary presence in reports. That is more than the annotations provide and directly shapes how an agent should react to the response.

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 purpose and the key lookup rule; every clause maps to something an agent needs (contents, fallback, filtering). The first sentence is a long enumeration that a bulleted listing would have made scannable, but no sentence is filler.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly, and all three parameters are covered by a 100%-documented schema. Nothing an agent needs to call this correctly — inputs, filtering semantics, ambiguity handling — is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds value by clarifying that sections filtering is partial — company profile and weighted indication are always returned regardless of the filter — and by explaining the name-match fallback that makes the valuation id parameter meaningful. It does not restate the parameter formats, but the schema already does.

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 verb+resource ("Returns one valuation") and enumerates exactly what that valuation contains (methods, ranges, DLOM, weighted indication, assumptions, reports). It never names or differentiates itself from siblings like get_company_financials or list_companies, so an agent must infer the split from the returned-data list 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?

Clear about the calling condition ("chosen by company name") and handles the ambiguous case explicitly — "If several valuations match the name, returns the candidates instead" — plus guidance to use "sections" to limit the answer. It stops short of stating when to prefer this over list_companies or get_company_financials.

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, closed-world), and the description adds the data provenance and the digit-dependent response mode, which is real behavioral context. It stops short of stating units, period/currency, or how many subsectors a 2-3 digit query returns.

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 what it returns, followed by the input-mode rule. The metric list is dense but earns its place since there is no output schema to enumerate return fields.

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 work of telling the agent what fields come back, and it covers the single parameter's behavior. Missing details on units, reference period, and result size keep it from being fully complete for a benchmarking 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 coverage is 100%, so the baseline would be 3, but the description adds semantics the schema does not: digit count changes the response mode (benchmarks vs. subsector listing). Minor tension with the schema's '2-6 digits; matched on its first 4 digits' wording, but not contradictory.

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

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

States a specific verb+resource (industry benchmark ratios by NAICS subsector), names the data source (Damodaran / NYU Stern as used by Equitest), and enumerates the exact metrics returned. This is clearly a sector-level lookup, distinguishable from company-level siblings like get_company_financials and get_company_valuation.

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

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

Explicitly tells the agent how the input depth selects behavior: a 4-digit code returns benchmarks, 2-3 digits lists the subsectors underneath. It gives clear context but never states when to prefer this over siblings (e.g., to contextualize a company's ratios) or any exclusions.

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 closed-world, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing that teammate-shared valuations are included and by listing the returned attributes. It does not explain pagination or truncation behavior even though a limit parameter (default 50, max 100) implies result capping.

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

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

A single front-loaded sentence that puts the verb, resource and access scope first and the field enumeration last. The field list is long but it is doing real work in the absence of an output schema, so it earns its place.

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

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

With no output schema, the description usefully compensates by naming the returned fields, and it clarifies the shared-access scope. The remaining gap is result-set behavior: nothing tells the agent whether 50 results is a full answer or requires further paging.

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 only 50%: 'search' is documented in the schema but 'limit' has no description anywhere. The tool description mentions neither parameter, so it does not compensate for the documented gap or clarify whether 'limit' caps results, requires paging, or how search interacts with the returned set.

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 (Lists) and resource (business valuations/companies) plus the exact scope: the user's own account plus valuations teammates shared with them. It also enumerates the returned fields, which makes it unmistakably the discovery/listing tool rather than the single-entity get_company_valuation or get_company_financials 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?

Usage is implied rather than stated: the enumeration of summary fields signals this is the entry point before drilling into siblings like get_company_financials or get_company_valuation. However, there is no explicit 'use this when...' or 'use X instead when...' routing, and no mention of what to do if the list is truncated.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description is free to add operational detail and does: up to 25 results, newest-first ordering, percentile statistics computed over ALL matches (not just returned rows), USD millions, and the definition of deal size as value of 100% of the target. It also discloses plan gating and per-day search limits, which are not in any structured field.

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?

Three tight sentences: what it does, what it returns, and the commercial/unit caveats. Result shape and limits are front-loaded before the plan note, and nothing repeats the annotations or schema.

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

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

For a 10-parameter, zero-required tool with no output schema, the description does the important work: return composition, percentile semantics, units, and result cap are all spelled out. What is missing is filter-combination behavior and the fact that there is no pagination beyond the 25-row cap, which matters for an agent that may want more results.

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

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

Schema coverage is 80%, so the schema handles most parameter meanings; the description still adds value by fixing units (USD millions) and clarifying that deal-size filters refer to 100% of the target, which prevents a common misinterpretation. It says nothing about require_multiple, gics vs naics precedence, or how multiple filters combine, leaving some 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 specific verb and resource: searching Equitest's curated M&A transaction database, and the second sentence clarifies exactly what comes back (deals plus p25/median/p75 multiples). The purpose is unambiguous. It never names a sibling to contrast with, though the siblings (company financials, valuation, industry benchmarks, list_companies) are far enough apart that confusion is unlikely.

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

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

Usage is only implied: an agent infers this is the tool for comparable-transaction analysis, but the description never says when to use it versus get_company_valuation or get_industry_benchmarks, nor when to skip it. Plan availability and daily search limits are stated, which is a useful gating hint but not usage guidance.

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