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

Annotations already mark the tool readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds useful context by naming the data sources and the narrative format, but it does not disclose limitations such as potentially outdated or incomplete public data, or access failures.

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

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

One sentence with no filler, front-loaded with the core action and output. Every phrase adds information about either the output content or the data sources, making it easy to scan.

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

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

The description adequately names the output type and content for a simple read-only research tool, and the schema covers most inputs. However, there is no output schema and the description does not address the sector-research alternative supported by the schema, nor any caveats about the narrative result, leaving some gaps.

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

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

Schema description coverage is 0%, and the required context.company field has no description in the input schema. The tool description does not explain how to specify the company (name vs. domain), nor does it clarify the optional sector/country fields, so the description fails to compensate for the schema 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?

The description uses a specific verb ('Produces') and clearly identifies the resource: a narrative business overview. It also lists the content dimensions (what the company does, products/services, target market) and sources, which helps differentiate it from sibling tools like company_profile or industry_overview, though it does not explicitly name 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?

No explicit guidance is given on when to use this tool versus alternatives such as company_profile or discover_competitors, and no exclusions are stated. The description only indirectly implies a use case (public-facing overview from the company's own site and LinkedIn), leaving 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?

Annotations already signal readOnlyHint=true and openWorldHint=true, so the description does not need to re-establish safety. It adds useful behavioral context by disclosing that the tool aggregates data from MCA, Tofler, Zauba, OpenCorporates, and the company's own site, which helps the agent calibrate expectations about data provenance and breadth. It does not cover failure modes or freshness, but this is not required given the annotation coverage.

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 with the core action front-loaded, then concrete facts in parentheses, then sources at the end. Every element earns its place and there is no filler or redundancy.

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 description is enough for an agent to understand the tool's basic purpose and safety profile, especially with readOnlyHint and openWorldHint present. However, it leaves open how to construct the required `context` object, how to distinguish this from sibling profile/overview tools, and what happens when registry data is unavailable, so it is not fully complete for autonomous invocation.

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

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

The schema description coverage is 0% for the top-level `context` parameter, and the required `company` field has no schema description. The tool description names the kind of facts retrieved but does not clarify how `company` should be provided (legal name, CIN, or search string) or how optional fields like `sector`, `listed`, and `companyDomain` affect the lookup, so the description does not compensate for the schema 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?

The description uses a specific verb ('Retrieves') and a specific resource ('registry-grade company profile facts') with concrete examples of the data returned (CIN, incorporation date, registered office). It also names the sources searched, which distinguishes it from generic overview or search tools even without explicitly mentioning 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 intended use is implied: an agent can infer this is for authoritative registry-level company facts rather than a narrative overview. However, it does not explicitly state when to prefer this over siblings like company_overview or search_company, nor does it provide any exclusions or alternative routing.

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

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

Annotations already mark the tool read-only and idempotent, so the description adds valuable behavioral context: it is deterministic, silently omits a multiple type if inputs are incomplete, never guesses missing inputs, and bridges enterprise value to equity via netDebt. This goes well beyond the annotation hints and helps the agent anticipate edge cases.

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 three dense sentences with the primary behavior front-loaded, followed by constraints and edge-case behavior. The parentheticals add length but every clause carries meaningful information; it is concise relative to the complexity it explains, though not as tight as a two-sentence definition.

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

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

For a tool with nested objects and no output schema, the description explains inputs, outputs, methodology, and failure behavior well. It mentions `issues` for silent omissions, but because there is no output schema, the agent still lacks exact return-value structure. Overall it is complete enough for correct invocation.

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

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

With schema description coverage only at 33%, the description compensates by explaining the core meaning of `peers` (real peer multiples, e.g. from listed_peer_comparison), `target` (the company's own financial metrics), and `netDebt` (used to bridge enterprise-value bands to equity). It does not detail every parameter such as `companyName` or `sharesOutstanding`, but the most important semantic distinctions are covered.

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

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

The description names a specific verb ('Applies'), a precise resource (peer trading multiples to target financial metrics), and the exact outputs (low/median/high valuation bands plus a blended equity range). It also differentiates itself from sibling valuation tools like dcf_valuation and listed_peer_comparison by stating it 'picks no peers and invents no multiples.'

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 tool says to supply real peer figures 'e.g. from listed_peer_comparison' and clarifies it performs only banding/blending arithmetic, not peer selection. It implies the right condition for use — when peer multiples and target metrics are already available — but does not explicitly contrast with DCF or other valuation alternatives.

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 readOnlyHint and openWorldHint annotations, the description discloses the tool's best-effort nature, its reliance on press coverage rather than paid feeds, and the risk of misrepresenting the output as a true Street consensus. This is meaningful behavioral context that annotations alone do not 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?

Three sentences, no filler, and the most important caveat is placed immediately after the core function. Every sentence earns its place by either defining the tool or preventing misuse.

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 description clearly conveys what the tool returns, its limitations, and how the output should be framed. It does not describe the output schema or parameter usage, but the required 'context.company' is evident from the schema and the tool's purpose is unambiguous.

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 description adds no parameter-level guidance. There is one required nested 'context' parameter with a required 'company' field, but the description never explains how to specify the company, date, or other context fields. The tool's behavior implies a company context but does not compensate for the missing schema descriptions.

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

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

The description names a specific verb and resource: 'Pulls individually-reported brokerage target prices/ratings from press coverage.' It explicitly distinguishes the tool from a real consensus feed, which prevents the natural misreading of the tool name 'consensus_estimates.'

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 explicit when-to-use guidance: 'Use this for "here's what a few brokerages have said"' and a clear when-not: 'never present averageTargetPrice as "the market consensus."' It also explains why, citing the lack of a paid market-data subscription.

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 readOnly and idempotent hints, the description discloses that the tool never forecasts, guesses, or defaults assumptions; echoes all assumptions for auditability; reports structural issues like wacc <= terminalGrowthRate in an `issues` field; and outputs calculations rather than a verdict. This is exactly the kind of contextual behavior annotations cannot convey.

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 long but information-dense, with each sentence contributing either scope, prerequisites, issue handling, or output interpretation. It could be more scannable with structure, but there is no filler or tautology.

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 no output schema, the description covers most of the contract: explicit assumptions in, auditable output, fairValuePerShare, issues reporting on structural problems, and non-advisory framing. It references metadata.kind and generate_report, giving an agent enough context to use the result responsibly; only the full result shape and the optional companyName/sharesOutstanding semantics remain implicit.

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?

Despite 0% schema-description coverage at the top level, the description names most assumption inputs: revenue growth path, EBITDA margin path, D&A/capex/NWC percentages, tax rate, WACC, terminal growth rate, and net debt. It omits the optional companyName and sharesOutstanding parameters, so it does not fully compensate for the schema gap, but it adds substantial semantic meaning beyond the raw field names.

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 opens with a specific verb ('Runs') and a concrete operation: a discounted-cash-flow valuation from caller-supplied assumptions. It clearly distinguishes this from report-generation or advisory tools, though it does not explicitly differentiate among DCF siblings like multi_stage_dcf_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?

The description gives strong usage context: reason about assumptions from financial_statements, ratio_analysis, and sector context before calling, and pair the output with an ai_interpretation section rather than treating fairValuePerShare as advice. It does not explicitly state when not to use this versus multi-stage, SOTP, or comparables, but the computation-vs-verdict framing provides clear orientation.

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

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

With readOnlyHint and openWorldHint already present, the description adds substantial process detail: source types, text-pattern extraction, ranking heuristics, and deterministic top-5 selection. It also clarifies that coverage is open-world and that candidate selection is not left to the calling model.

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 dense sentence conveys source, method, ranking inputs, output cardinality, and determinism without filler. The action is front-loaded and every clause adds useful 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?

The behavior and output count are well described, but the description is not fully complete because it omits output shape and the meaning of the optional nested context parameters. Given no output schema and 0% schema description coverage, these gaps matter for reliable invocation.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it only implicitly covers 'company' and hints at a 'listed-company signal'. The nested context fields (date, sector, country, companyDomain) and their effect on the search are left undocumented in both the schema and 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 action (searches industry-analyst and news sources), a specific resource (competitors/rivals of a company), and a concrete output (top-5). It also distinguishes itself from manual/model-driven selection by noting the server picks peers deterministically.

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 when this is useful (when deterministic server-side competitor selection is desired rather than model-selected peers) but never gives an explicit condition or names alternative sibling tools. There are no when-not-to-use or fallback rules.

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?

The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the source waterfall, inline ratio/CAGR/projection computation, the mechanical nature of the projection, and the structured not_available response instead of bare nulls. This is rich behavioral context that annotations do not 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?

The description is front-loaded with the primary purpose and waterfall, then packs the important caveats into compact, purposeful clauses. Every sentence adds value: return shape, projection labeling, fallback sources, and null handling. No filler or repetition of schema details.

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 explains the return type, projection behavior, and failure mode, referencing ratio_analysis for shape. It is slightly incomplete regarding coverage nuances for unlisted vs. global companies and exact date-range handling, but it is comprehensive enough for most invocation decisions.

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 50% schema coverage, the description partially compensates by adding conditional detail about includeRatios ('computed inline by default whenever 2+ historical periods are available'). However, it does not clarify the required context object's role in the source waterfall or explain how fields like listed, country, or sector influence behavior, leaving a gap for the required parameter.

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

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

The description uses a specific verb ('Retrieves') and names the exact resource ('financial statements'), then details the source waterfall. It also distinguishes itself from siblings by noting that ratio_analysis consumes its output and that dcf_valuation/scenario_analysis handle assumption-driven fair value, so an agent can tell it apart without inspecting schemas.

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 clearly signals when this tool is appropriate: when financial statements are needed, and it routes fair-value work to dcf_valuation/scenario_analysis. It does not explicitly say when not to use it or name a direct alternative for the same statements, but the context is strong enough to guide selection.

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 readOnlyHint and openWorldHint annotations, the description reveals that the tool searches multiple external sources and 'extracts candidate round/amount facts from retrieved text,' signaling possible noise and text-derived inferences. It does not mention rate limits, pagination, or failure behavior, but the annotations already cover the safety profile.

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 dense sentence front-loads the action and then efficiently lists sources and target data. Every word earns its place, with no filler or repetition.

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 description covers the core behavior and output type but omits how optional context fields affect the search and what the exact return format is. Given the absence of an output schema and the range of parameters, this is a clear gap.

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

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

Schema description coverage is 0%, and the description provides no guidance on the required 'company' field or the optional 'date', 'country', 'listed', 'sector', and 'companyDomain' fields. The named data sources hint at country relevance (e.g., Tofler/MCA for India), but the relationship is left implicit.

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 uses the specific verb 'Searches' and identifies the exact resource: funding rounds, investors, and valuation mentions across six named sources. It clearly distinguishes funding_history from sibling tools like financial_statements or company_overview, and the extraction phrase clarifies the output type.

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 this tool is for retrieving a company's funding history, but it never explicitly states when to prefer it over sibling research tools or which contexts it is unsuitable for. No alternatives or exclusions are mentioned, leaving the agent to infer usage from the behavior.

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?

The annotations only carry readOnlyHint=false, openWorldHint=true, idempotentHint=false, leaving the description to carry the behavioral burden, and it does so thoroughly. It discloses the sector fallback, the report's closing section telling the calling model exactly which analyst-judgment sections to add next (SWOT, bull/bear, valuation with metadata.kind='ai_interpretation'), the risk screen's evidence checklist of which sources were checked, output rendering behavior, and the required writing convention with concrete examples of direct versus hedged phrasing.

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 unusually long for a tool definition at roughly 200 words, but nearly every clause earns its place: the verb+scope statement is front-loaded, the consolidation directive over nine sibling tools is placed early, and the trailing writing-style instruction, while lengthy, dictates the model's output voice and is essential to downstream quality. It is dense but not padded.

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

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

For a complex 7-parameter aggregator with no output schema, the description covers a great deal: the report's section composition, sector fallback, output formats, sibling alternatives to avoid, and the expectation that the calling model adds analyst-judgment sections. What is missing is the response shape (no output schema exists, and the description only says 'rendered in the requested output formats') and the behavioral meaning of the three enum parameters, both of which matter for a correct call.

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 57%: company, sector, companyDomain, and outputFormats already have schema descriptions, and the tool description adds no new per-parameter meaning — the sector fallback repeats the schema text and outputFormats merely lists the same formats. The three enum parameters (listed, country, reportType) remain undocumented in both schema and description, so an agent has no way to know what reportType=debt_raising changes or what listed=unlisted affects behaviorally. Since coverage sits in the mid range and the description does not compensate for the enum gaps, baseline 3 is appropriate.

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

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

The opening clause 'Generates a complete institutional research report for a company in one call' pairs a specific verb with a clear resource, and the description then enumerates the report's contents (company profile, financial snapshot, macro/industry overview, competitor list, funding history, risk screen, news). It differentiates itself from siblings by explicitly naming the nine tools it consolidates, so an agent can select it over search_company or company_profile without ambiguity.

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 contains an explicit directive: 'Use this instead of calling search_company, company_profile, financial_statements, discover_competitors, litigation_history, promoter_background, negative_news, latest_news, and generate_pdf separately,' which clearly states when this tool is the right choice and names the alternatives. It also explains the sector fallback behavior. It stops short of a full 5 because it never states when NOT to use it — e.g., when only a single section like financial statements is needed — but the consolidation guidance is strong.

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 mark the tool idempotent; the description adds that the operation renders/transforms rather than mutating, and enumerates output components. It does not disclose whether the result is a returned Markdown string or a written file, which would be valuable since no output schema exists. No contradiction with annotations.

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

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

One sentence with the action front-loaded and the output structure compressed into a list of meaningful deliverables. The parenthetical schema pointer is efficient and avoids repeating the nested 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?

The description captures the core rendering behavior and output features, but with no output schema it should state whether the result is a Markdown string or a file path, and ideally indicate the intended pipeline from generate_report. It is adequate but not fully complete for a 10-parameter 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?

The schema already documents half the parameters, and the description reinforces the semantics of 'sections' by mentioning per-section confidence/sources and consolidated citations. It does not add meaning for tags, subtitle, generatedAt, or other cover-page fields, but those are relatively self-evident and the input schema carries the detail.

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

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

The description names a specific action ('Renders'), a clear input ('structured report ... generate_report's schema'), and a concrete output ('GitHub-flavored Markdown document with table of contents, per-section confidence/sources, and a consolidated citation list'). It is unambiguous about what the tool produces, though it does not explicitly contrast with generate_pdf or generate_report.

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 'see generate_report's schema' reference implies it is meant to consume output produced by generate_report, and the output type differentiates it from PDF generation. However, it never explicitly states when to choose this over generate_pdf or when not to use it, nor does it describe the intended pipeline.

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 discloses important runtime behavior beyond the generic annotations: the PDF is embedded directly as a base64 resource, a downloadUrl appears only over httpStream, and no filesystem access is required. This gives an agent a clear model of how output is delivered, though it does not mention error cases or potential server-side side effects.

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 tightly packed sentences with no filler. The first sentence front-loads the core purpose and output format; the second explains delivery behavior. Every clause earns its place.

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

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

For a 10-parameter tool with no output schema, the description covers the input source, the output format, transport behavior, and the main layout characteristics. Minor gaps remain around defaults and error behavior, but an agent has enough information to select and invoke the tool 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?

With schema description coverage at 50%, the description adds meaning by referencing generate_report's schema and explaining that the input is a structured report with rendering-specific layout features. It does not individually explain every optional parameter, but the external schema reference plus self-explanatory field names covers most practical invocation needs.

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 action ('Renders a structured report'), a concrete output ('institutional-layout PDF'), and details the layout features. It also points to generate_report's schema, tying the tool's input contract to a sibling and clearly distinguishing this PDF-rendering tool from markdown or structured-report 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 clearly indicates this is for rendering a generate_report-style structure into a PDF and returning it inline for remote clients. It does not explicitly say 'use generate_markdown instead when Markdown is needed' or list excluded alternatives, so it stops short of full when-to-use/when-not-to-use 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 provide idempotentHint=true and readOnlyHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond the schema: the renderer visually distinguishes AI-interpretation sections, always attaches a 'not advice' disclaimer, and the tool enforces a specific analyst voice. This enriches the agent's mental model of what invoking the tool produces.

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 purpose and then adds only high-value operational guidance. The length is justified by the need to communicate report content standards, AI-interpretation handling, and voice requirements; there is no filler or repetition of schema details.

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 description covers when to call, what it does, how to mark interpretive sections, and the required writing style. For a tool with no output schema, it could more explicitly state what the call returns (e.g., a rendered report or a report object), but the phrase 'assembles ... into the standard report envelope' implies the output sufficiently for an agent.

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 50%, so the description must add parameter meaning. It clarifies that sections carry 'summary, tables, citations, and confidence' and gives precise semantics for metadata.kind = 'ai_interpretation', which the schema leaves open as additionalProperties. It does not cover every undocumented field (e.g., generatedAt, companyName), but it adds real value beyond the schema on the most behaviorally important parameters.

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 ('Assembles'), a specific resource ('a structured research report from ResearchSections ... into the standard report envelope'), and explicitly differentiates it from research-gathering tools: 'this tool does no research of its own.' It is immediately distinguishable from fact-finding siblings like financial_statements or latest_news.

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 explicit when-to-use guidance: 'Use after gathering facts with other tools.' It also rules out using it as a research tool, and explains exactly how to handle interpretive content by setting metadata.kind = 'ai_interpretation'. This is strong routing guidance relative to 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=true and openWorldHint=true. The description goes well beyond that by revealing the data source (screener.in), the point-in-time nature of the multiples, and the non-fabrication behavior: unavailable peers return status 'not_available' with a reason rather than a made-up valuation. It also honestly states the ceiling of free data versus paid market-data subscriptions, which is valuable behavioral context for an agent.

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 action and output fields in the first sentence. The second sentence efficiently conveys coverage limits and failure behavior. The final sentence, while relevant for setting expectations, is slightly rhetorical and could be tightened without losing meaning. Overall it is well-structured but slightly more verbose than necessary.

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

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

For a read-only tool with a single parameter and no output schema, the description covers everything an agent needs to invoke it and interpret results: the input convention, the source, the returned multiples, the failure mode for unsupported peers, and the explicit honesty boundary versus paid terminal data. Nothing critical 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?

There is only one parameter, companyNames, and the schema already describes it as peer companies to look up, typically the target plus discover_competitors' output. The description repeats the same guidance without adding extra meaning such as string format, company-name matching rules, or case sensitivity. With 100% schema description coverage, a baseline score of 3 is appropriate.

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

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

The description precisely states what the tool does: for each peer company name, it searches screener.in and pulls real point-in-time valuation multiples, listing the exact metrics (CMP, Market Cap, Stock P/E, Book Value, ROCE, ROE). It is clearly distinguished from a generic global-comps tool by stating the Indian-listed-only limitation and the not_available status for private or foreign peers.

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 clear usage context: feed it peer names, typically the target plus discover_competitors' output, and use it only for Indian-listed companies. It also tells the agent when the tool will not work—for private or foreign-exchange-listed companies—and explicitly disclaims the possibility of producing a paid-terminal-grade global forward-consensus table. However, it does not name a specific sibling tool as a concrete alternative, so routing guidance is not fully 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 readOnlyHint, idempotentHint, and openWorldHint false. The description adds useful behavioral context by specifying what is assessed (config, Redis, Postgres, registry), going beyond the annotations. It doesn't mention response format or auth, but for a read-only diagnostic this is sufficient.

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 entire description is one front-loaded sentence with no filler. Every phrase adds concrete information about what the health check reports.

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-parameter read-only health check, the description covers the important operational aspects: the subsystems checked and the diagnostic scope. It doesn't specify the response schema, but no output schema exists and the listed components give an agent enough context to invoke and interpret basic 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?

The tool has zero parameters and the schema is fully described, so there are no parameter semantics to clarify. Per the rubric, zero params warrants a baseline 4.

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

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

The description uses a specific verb ('Reports') with a clear resource ('server health') and enumerates the exact subsystems checked: config validity, Redis cache connectivity, Postgres configuration status, and the capability registry. This clearly distinguishes it from all sibling tools, which focus on company/valuation data.

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 makes the operational use obvious: call this when server health status is needed. It doesn't explicitly name alternatives or exclusions, but none of the siblings serve a health-check purpose, so the context is clear enough without them.

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

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

With readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral context: it names the top-tier research sources and describes fallback behavior when sector is omitted. No contradiction with annotations.

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

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

Two front-loaded sentences convey the core purpose, scope, and usage hint efficiently. The source list is somewhat long but adds credibility and helps define the tool's domain; no filler.

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

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

The description conveys what the tool returns (industry research with specific components) and how to steer it, which is enough for initial selection. With no output schema, it does not describe return structure or formatting, but the core decision-making context is present.

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 clarifies the sector/company relationship and fallback, but leaves other context fields (country, listed, date, companyDomain) semantically unexplained, leaving gaps for an agent.

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 uses a specific verb ('Retrieves') and a clear resource ('macro/industry-level research') with enumerated content areas (market structure, key players, growth drivers, TAM/market size). It distinguishes itself as the industry-wide context for company-specific reports, though it does not explicitly name sibling tools that overlap (e.g., market_size).

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 actionable usage guidance: pass context.sector for a sharper search, and notes the fallback to context.company's industry. It contrasts with company-specific (micro) reports, implying when not to use it, but it does not name alternative sibling tools or explicit 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 readOnlyHint and openWorldHint, so the core safety profile is covered. The description adds useful behavioral context by naming specific news sources and stating that results are sorted by publish date, but it does not disclose limits, pagination, return shape, or how broad 'recent' is. This is acceptable but not rich.

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 sentence with no filler. It front-loads the core action and covers the main scope, sources, and ordering. Every part of the sentence 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?

The description covers the core operation adequately for a read-only news lookup, and the schema fills in parameter structure. However, there is no output schema and no mention of what the returned news items look like (titles, links, summaries), nor is there any guidance on the meaning of daysBack or how this differs from negative_news. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 0%, so the description needed to compensate for parameter meaning. It only hints at the 'company' parameter through 'of a company', and it says nothing about 'daysBack', 'date', 'country', or the nested context object structure. The schema provides some field names and defaults, but the description does not help an agent understand how to set these parameters effectively.

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 action and resource: retrieving recent news coverage of a company, and it names concrete sources and a sort order. It is clear in what the tool does, but it does not explicitly differentiate it from sibling tools like negative_news or management_commentary, aside from the general word 'coverage'.

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 about when to choose this tool over alternatives. It does not mention that negative_news exists for negative-only coverage, or that management_commentary covers management statements instead of press coverage. The usage context is implied by the name and description but never made 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?

With readOnlyHint=true and openWorldHint=true already covering the safety profile and non-exhaustive nature, the description adds meaningful context: multi-source aggregation across screener.in, Trendlyne, and exchange portals, plus the expectation of repeated per-company calls. It doesn't cover failure modes like source unavailability, but the openWorldHint partially 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?

One dense, information-packed sentence that front-loads the action and resource before the usage tail. Every clause earns its place — the em-dash section is critical for sibling differentiation. Slightly run-on and could be split into two sentences, but there is zero filler.

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

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

For a read-only, one-parameter tool with no output schema, the description covers the essential bases: what fields come back (market cap, P/E, shareholding-pattern context), where the data comes from, and how to call it per company. Minor gaps: the Indian-only sources imply country=india but the schema allows 'global', and the description doesn't clarify behavior when a company is unlisted.

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% per the context signal, so the description bears the burden. It adds important semantics for the required 'company' parameter (must be a listed company; one company per call). However, it says nothing about 'country', 'listed', 'sector', or 'companyDomain' semantics, and while the schema itself documents three of six properties, the key required param is only partially explained.

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?

Uses a specific verb ('Retrieves') with a concrete resource ('listed company's own financial snapshot') and names the exact data points (market cap, P/E, shareholding-pattern context). The 'run once per company' clause distinguishes it from sibling tools like discover_competitors and global_peer_comps, which operate across companies in one call.

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 an explicit invocation pattern: run once per company, for the target and each peer that discover_competitors identifies, then assemble results into a peer-comparison table. It clearly references a sibling workflow but stops short of naming alternatives to avoid or stating when-not-to-use conditions (e.g., for unlisted companies).

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 the safety and exhaustiveness profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real provenance context: the specific legal databases screened and the categories of enforcement records covered, which helps an agent calibrate coverage expectations. It does not address result format, data freshness, or source-coverage limitations, but these are secondary given the annotations.

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

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

Exactly two sentences with no filler: the first packs sources, record types, and subject scope; the second delivers the sibling distinction. The most decision-relevant information is front-loaded before the alternative routing.

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 research tool with one required nested parameter and no output schema, the description covers the subject, sources, record categories, and the key alternative thoroughly. Two gaps remain: it never hints at the return shape (list of case citations vs. narrative findings), and the `sector`-as-subject option is not reconciled with the 'company or promoter name' subject phrasing. These are minor for invoking the tool correctly, hence a 4 rather than a 5.

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% at the top level, and the only required field (`company`) is undescribed in the schema, so the description must compensate. It partially does by stating the subject can be a company or promoter name, giving the `company` parameter meaning the schema lacks. However, it adds nothing about `date`, `listed`, `country`, or `companyDomain`, and the India-specific source list sits awkwardly with the `country: global` option — compensation is only 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?

The description uses a specific verb ('screens'), names precise sources (SEBI, NCLT, IndianKanoon, LiveLaw, Bar & Bench), and enumerates concrete record types (litigation, regulatory penalties, insolvency proceedings, director disqualification). It also explicitly distinguishes itself from the closest sibling, negative_news, so an agent can differentiate the tools without opening schemas.

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 second sentence gives an explicit routing rule: this tool is for hard legal/regulatory records, while negative_news covers general press/employee sentiment. That is a clear when/when-not with a named alternative, matching the structure of the strongest calibration examples. It only covers one sibling, but negative_news is the genuinely confusable one; other siblings are distinguished by name alone.

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

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

The description discloses crucial behavioral traits beyond the readOnly/openWorld annotations: it returns 'guidance-shaped sentence fragments' from press coverage, not verified transcript quotes, and instructs agents to attribute to the covering outlet unless the source is the transcript. This materially shapes how the output should be interpreted and cited, which is highly valuable for an agent.

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 two sentences, each earning its place: the first states the function and use case, the second sets expectations about source quality and attribution. It is front-loaded and contains no filler or redundant restatement of the tool title.

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

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

For a tool with no output schema, the description does a good job of explaining what the agent will receive and how to attribute it. However, it does not explain how optional context fields such as date, listed, sector, or country affect results, leaving some ambiguity for non-standard queries like sector-level research.

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 reported at 0%, so the description is responsible for explaining how the context parameter influences the tool's behavior. It provides no guidance about company, date, country, sector, or other input fields, leaving the agent to infer parameter semantics from the schema alone. This is a significant gap for a nested parameter object.

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 uses a specific verb ('Finds') and a specific resource ('management guidance and outlook commentary from earnings-call coverage and press interviews'), making the tool's purpose immediately clear. The added analogy about 'what did management say about the next few quarters' further clarifies its role in initiating-coverage research. It is easily distinguishable from sibling tools like management_profile or consensus_estimates.

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 clearly identifies a use case: the management-guidance input for initiating-coverage notes. It also informs the agent that output comes from press coverage rather than verified transcripts, setting expectations about source fidelity. However, it does not name alternative tools or explicitly state when not to use this tool, so it falls short of full routing 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 establish readOnlyHint and openWorldHint, and the description adds valuable behavioral disclosure: the data is pattern-extracted from narrative search snippets, so identity must be verified against the source URL before quoting. This goes beyond the annotation safety profile by flagging potential unreliability. No contradiction with annotations.

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

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

The core action is front-loaded in the first sentence, and the second sentence contains the important caveat. The text is compact at roughly two sentences, though the second sentence is slightly convoluted with the 'Every real initiating-coverage note' construction.

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 description names the output fields and the reliability caveat, which is helpful given there is no output schema. However, it does not explain how optional context fields like sector, listed, or country affect the lookup, nor the return shape beyond field names, so an agent may have to infer some invocation details.

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 schema description coverage at 0%, the description needed to explain the required context.company and the optional filters, but it does not. 'Company's own site' loosely hints at companyDomain, and 'company' is inferable from the subject matter, but no explicit parameter guidance is provided.

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 states a specific action ('Retrieves') and resource ('key management personnel and board member profiles') and enumerates the data fields (name, designation, background) and sources. It does not explicitly position the tool against siblings such as management_commentary or promoter_background, so it falls short of full sibling differentiation.

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

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

The description gives a purpose but no when-to-use guidance, prerequisites, or comparisons to alternative tools. The second sentence explains data provenance and a verification requirement, but it does not tell an agent when to choose this tool over management_commentary, promoter_background, or company_profile.

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?

The annotations already provide readOnlyHint and openWorldHint. The description adds useful behavioral context: results are numeric estimates extracted via pattern matching from analyst/research sources, and the sector-to-company fallback behavior. It does not mention no-result behavior, but it goes beyond what the annotations convey.

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 with no filler. The first sentence states the tool's purpose, method, and sources; the second gives parameter guidance. Information is front-loaded and every sentence earns its place.

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

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

For a read-only extraction tool with no output schema, it communicates the purpose, sources, extraction method, and parameter fallback. It does not specify the exact return shape, units, or behavior when no figures are found, but these are minor gaps given the tool's narrow scope and simple input 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?

The description explains the relationship between context.sector and context.company, which is not evident from the schema alone, and it tells the agent which to set. The nested schema fields have their own descriptions, though the top-level context parameter lacks one; a little more about expected units or country defaults would round this out.

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 action ('Finds') and the resource ('market size and CAGR figures for an industry'), and it names concrete analyst/research sources. It also explicitly distinguishes the company-fallback behavior, so an agent can tell this tool apart from broader industry-overview or company-profile tools.

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

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

It provides explicit parameter guidance: pass context.sector when known, otherwise the tool falls back to searching around context.company's own market. It does not name sibling alternatives or state when not to use it, but the intended usage context is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful behavioral context beyond those: 'every assumption is caller-supplied and echoed back, nothing is guessed or defaulted, and this computes — it doesn't render a verdict.' It also explains the glide mechanics of the fade stage, which is a behavioral trait not evident from the annotations.

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

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

The description is informative but quite long and parenthetical. It front-loads the core 'Runs a 3-stage DCF' and the key structural details, but the ICICI Securities anecdote and the extended contrast with single-stage ad value. It could be tightened without losing meaning.

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

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

Given the tool's complexity and the absence of an output schema, the description should clarify what the tool returns (e.g., enterprise value, equity value, per-share value) and how 'echoed back' manifests. It explains the conceptual model and parameter usage well, but the output contract is left to inference via 'same rules as dcf_valuation.'

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 schema description coverage at 0% for top-level parameters, the description carries the burden for explaining the complex inputs. It elaborates on stage1GrowthPath/stage1EbitdaMarginPath (explicit forecast years, typical 8-10 for growth names) and fadeYears (linear glide from stage 1 final rate to terminal growth). However, standard inputs like wacc, taxRate, and netDebt are not individually described, 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?

The description states a specific verb and resource: 'Runs a 3-stage DCF' with an explicit forecast stage, fade stage, and terminal value. It clearly differentiates from sibling dcf_valuation by describing the single-stage alternative's behavior and why multi-stage is superior for fast-growing names.

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 clear context on when the tool is appropriate: companies still years from steady state benefit from 8-10 year explicit forecasts and a fade stage, whereas single-stage dcf_valuation understates such cases. It names the alternative (dcf_valuation) but doesn't spell out a hard when-to-use/when-not-to-use rule or address other valuation siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is safe and potentially partial. The description adds context about the information sources (Glassdoor, Reddit) and the type of adverse signals covered (fraud, layoffs, defaults, employee/public controversy), which goes beyond the annotations. It does not describe pagination or return format, but for a screening tool with readOnlyHint and openWorldHint, the description adds meaningful behavioral context. A 4 seems fair.

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 core purpose and examples of what it covers. The second sentence routes to the alternative tool. No filler. Slightly dense but highly efficient.

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 no output schema, complexity includes a nested context object with several optional fields. The description tells the agent the purpose and the source categories, and points to the sibling for legal records. It does not explain how to use optional parameters like sector, companyDomain, or listed, and does not describe output shape, but the readOnly and openWorld annotations cover the uncertainty. Complete enough for the agent to decide and invoke, though parameter usage guidance is modest.

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. The description mentions 'a company' but does not elaborate on any of the input parameters (context, company, date, listed, sector, country, companyDomain). It does not say how the parameters influence the search, e.g., how country or listed affect the sources. Baseline is 3 when description adds some context; here it adds purpose context but no parameter-specific semantics beyond what the JSON schema already shows.

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 states the tool's purpose: screens news and public-sentiment sources (Glassdoor, Reddit) for adverse media and complaints about a company, specifically for due-diligence and risk-screening. It differentiates from litigation_history by explicitly stating that hard regulatory/legal records should use that tool instead. The verb 'screens' plus the resource and context make the purpose specific and distinguishable.

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

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

The description explicitly names an alternative tool (litigation_history) and gives the condition for selecting it ('For hard regulatory/legal records... use litigation_history instead'). This leaves no ambiguity about when to use this tool versus its closest sibling.

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

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

With readOnlyHint and openWorldHint already in annotations, the description still adds substantial behavioral context: the proximity-matching mechanism ('proximity-matched numbers near a metric name in free text'), the output being 'not a structured KPI table', the fallback to a 'generic cross-sector list', and an explicit verification directive ('treat every value as a lead to verify against its source URL'). Nothing contradicts the annotations.

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

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

Three sentences, each earning its place: (1) scope and sources, (2) parameter tuning plus fallback, (3) quality warning and verification workflow. The core purpose is front-loaded, and there is zero filler or repetition of schema content.

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 no output schema and two parameters, the description covers the essential ground: what is searched, where, how to narrow it, what happens without narrowing, and how to treat the noisy results. Minor gaps: it doesn't name a specific structured alternative to route to, and the return shape is described only abstractly (proximity-matched numbers with source URLs) rather than concretely.

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% at the parameter level, so the description must compensate. It richly explains metricNames — its purpose, how to source the vocabulary (industry_overview/discover_competitors results), and the fallback when omitted. The context object is not explained, but its nested schema provides structural hints for company/sector/country; the gap is minor since metricNames is the differentiating parameter.

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

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

The description opens with a specific verb ('Searches for') and a well-scoped resource ('sector-specific operating KPIs'), backed by concrete examples (store count, same-store-sales growth, DAU/MAU, GMV) and explicit sources (investor-presentation and press coverage). This clearly separates it from structured-financial siblings like financial_statements and ratio_analysis without needing the schemas.

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 explicit usage guidance for the key parameter — 'Pass metricNames with the specific KPI vocabulary... for a sharper search' — and discloses the fallback behavior when it is omitted. The noise caveat ('noisier than the server's other tools') implies the agent should prefer structured tools for citable facts, though it stops short of naming a specific alternative sibling.

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 and openWorldHint, so the description only needs to add context beyond that. It adds the regulatory source set and clarifies the company-field semantics, but it does not disclose result format, limitations of coverage, or how open-world results should be interpreted.

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 tool's purpose, followed by a direct invocation instruction. There is no filler or redundant material.

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

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

For a tool with one required parameter, the description fully explains what to pass and why, and the schema documents optional fields. The only gap is that it does not hint at the shape or nature of the returned findings, but this is not essential for correct invocation.

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

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

Schema description coverage is 100% and the context property description already explains that context.company should be the promoter/director's name or a company name. The tool description essentially restates that same guidance without adding new parameter-level meaning.

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 action ('Screens'), a specific subject (promoter or director name), specific data sources (SEBI/MCA/registry), and specific outcomes (disqualification, debarment, regulatory penalty). This is enough to distinguish it from general management or litigation lookup tools.

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 clear instruction on what to pass as context.company and when that could be a person or a company. However, it does not explicitly state when to prefer this tool over siblings such as management_profile, litigation_history, or red_flag_screen, nor does it mention 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 mark readOnlyHint, idempotentHint, and openWorldHint, and the description adds 'deterministic' and 'Pure calculation — no search, no LLM tokens', reinforcing and extending the behavioral profile. It does not contradict annotations. It could add edge-case or output-format details, but the annotations carry part of the burden.

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 primary purpose, with no redundant filler. The behavioral qualifier 'Pure calculation — no search, no LLM tokens' is compact and earns its place.

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

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

For a calculation tool with a detailed input schema, the description covers the key inputs, the computation scope, and the output themes. There is no output schema, so a little more detail about the returned structure would improve completeness, but the description is still sufficient for selection and invocation.

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

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

The schema describes the main 'statements' parameter with ordering and source context, and the description adds the notion of multi-period CAGR and the financial statement categories. However, optional fields like companyName and the exact required financial metrics (revenue, netProfit) are not explained beyond the schema, and schema description coverage is only 50%.

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?

Description uses a specific verb ('performs') with a clear resource ('financial ratio analysis over FinancialStatement objects') and lists the exact ratio categories and CAGR trend. The phrase 'Pure calculation — no search, no LLM tokens' also helps distinguish it from sibling tools that generate narratives or search data.

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 provides clear context for when to use it: when deterministic financial ratio analysis or multi-period CAGR is needed, not when search or LLM-driven output is required. It does not explicitly name sibling alternatives or state when-not-to-use conditions, so it stops short of a 5.

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 readOnly and idempotent annotations, the description adds important behavioral context: the tool only aggregates supplied evidence, never fabricates new evidence, and does not render an investment verdict. It also explains the optionality behavior, making the tool's operational boundaries clear.

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 every sentence earns its place: it defines the output, names the evidence sources, clarifies non-invention and non-verdict behavior, and explains optionality. It is front-loaded with the core purpose and avoids redundant phrasing.

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 description covers the aggregation purpose, severity buckets, overall severity, source traceability, and optional inputs. Since there is no output schema, the description does most of the work, though it stops short of describing the exact flag object structure or threshold logic; monthsSinceLastFunding is also 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?

The description usefully maps several parameters to their upstream tool outputs, such as litigationCases from litigation_history and negativeNewsCount from negative_news. However, monthsSinceLastFunding and companyName receive no semantic explanation in either the schema or the description, leaving a noticeable gap for those parameters.

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 and resource: it aggregates already-gathered evidence into a severity-bucketed flag list. It names the upstream tools and explicitly clarifies that it invents no new evidence and renders no investment verdict, which clearly distinguishes it from other research and report-generation 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 gives clear context for when to use the tool: after evidence has been collected from litigation_history, negative_news, ratio_analysis/financial_statements, and promoter_background. It also states that all inputs are optional and that omitted categories contribute no flags, which is practical selection guidance, though it does not explicitly name exclusions or alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint. The description adds meaningful behavior beyond these: it reports each case's validity issues rather than presenting a distorted number, invents no assumptions of its own, and performs no search. This is consistent with the annotations and gives an agent useful non-obvious expectations.

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 dense sentences with no filler: the first states the core behavior, the second explains input ownership and validity handling, and the third gives the tool-type constraint. The length is justified by the tool's complexity and every sentence adds useful 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?

For a complex nested-schema tool with no output schema, the description covers execution modes, input ownership, validity behavior, and the no-search constraint. It could be more explicit about the exact shape of returned fair-value outputs, but 'fair-value outcomes' and per-case validity reporting give adequate 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?

Schema description coverage is low (~20%), so the description does meaningful compensation: it explains bull/bear deltas with a concrete example (+3% revenue growth, -1% WACC), clarifies that the base case is 'as given', and notes sensitivity grid values are typically WACC x terminal growth rate. It does not enumerate the required baseAssumptions fields, but those are standard DCF inputs largely inferable from property names.

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 ('Runs'), resource ('mechanical DCF'), and precise behavior: three cases (base, bull, bear) plus an optional 2D sensitivity grid. It also clearly distinguishes the tool from the sibling dcf_valuation by noting it runs the same DCF across scenarios rather than a single 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?

The description positions the tool relative to dcf_valuation, explains that the caller must supply deltas/grid values from their own analysis, and explicitly says it is 'pure calculation — no search'. It provides clear context but does not enumerate exclusions or name alternatives like multi_stage_dcf_valuation or sotp_valuation.

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?

Builds on the readOnlyHint and openWorldHint by explaining that the search is domain-restricted and that it returns authoritative source URLs for website, LinkedIn, and registry presence. This gives the agent useful behavioral expectations without contradicting the annotations.

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

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

Two front-loaded sentences: the first names the output and method, the second gives the routing intent. No filler or repetition of schema data.

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

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

For a simple read-only discovery tool, the description names the output and its upstream position. However, it omits semantics for the optional context fields and any no-result behavior, so while adequate, it is not fully complete for an agent working with the richer nested context parameter.

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 schema description coverage at 0%, the description needed to explain the context object and its optional fields (date, listed, sector, country, companyDomain), but it only implies the company name. Aside from company, an agent cannot tell from the description why or how to set the other fields, so it does not compensate for the schema 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?

States a specific verb ('Discover') plus concrete resources (official website, LinkedIn, registry presence) and the method (domain-restricted Exa search). The second sentence clarifies it is a pre-resolution step for other company tools, so it is clearly distinct from downstream tools like company_profile or financial_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?

Explicitly instructs the agent to use this first to resolve a company name to authoritative URLs before other company tools, which is clear situational guidance. It stops short of saying when not to use it (e.g., when the domain is already known) or naming specific alternative tools, so it earns a 4 rather than a 5.

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 readOnlyHint and openWorldHint annotations, the description adds valuable behavioral detail: it does not fabricate splits when unreported, it is pattern-matched from narrative text, and users should verify labeled values against the source URL. This gives an agent an accurate model of the tool's reliability and limitations.

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 three sentences, each earning its place: the first defines the core purpose, the second explains the empty-result behavior, and the third warns about verification. The main function is front-loaded and there is no filler.

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

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

For a tool with no output schema, the description conveys the key return behavior (mentions[]), the anti-fabrication guarantee, and the need to verify against source URLs. It does not fully describe the output structure or parameter semantics, but it gives enough context for an agent to call the tool and interpret basic results.

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

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

Schema description coverage is 0%, and the description provides essentially no parameter-level guidance. It mentions 'a company' and 'source URL' but does not explain the context object, required company field, optional sector/country/date fields, or how the input affects the search. The description fails to compensate for the low 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 uses a specific verb and resource: it 'Finds business-segment or channel revenue mix' and gives concrete examples like Online vs Offline and product-line splits. It also clarifies that it only returns results when a company actually discloses such a split, which clearly distinguishes it from generic financial or operating metric tools.

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 clearly states when the tool applies: when a company discloses segment revenue in an investor presentation, annual report, or press coverage. It also provides guidance for the negative case by noting that an empty mentions[] is returned rather than a fabricated split. It does not explicitly name alternatives, but the scope is clear enough for selection among 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 mark this as read-only and open-world, and the description adds meaningful behavioral context by disclosing that data is 'pattern-extracted from search snippets' and must be verified against the source URL. This goes beyond what the annotations convey and appropriately warns about potential reliability limitations.

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 with no filler. The first sentence front-loads the core function and output scope; the second adds a necessary reliability caveat. Every clause contributes 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?

The description covers the core output and verification expectation, which is reasonable given no output schema. However, it does not address the optional context fields such as sector, country, listed, or companyDomain, and the 'listed company' framing leaves the unlisted/sector/global possibilities under-specified.

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 description does not compensate. It never explains how to populate context.company, context.date, context.listed, context.sector, context.country, or context.companyDomain. The only indirect hint is 'listed company,' which is too weak to count as meaningful parameter guidance.

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

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

The description states a specific verb ('Retrieves'), a specific resource ('Promoter / FII / DII / Public shareholding split'), and sources ('screener.in, Trendlyne, and exchange sources'). This clearly distinguishes it from sibling tools like management_profile or financial_statements by naming a unique data domain and 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?

The description gives clear usage context: this data is a standalone exhibit in institutional notes, implying it is the tool to use when such an exhibit is needed. It also provides a practical guardrail: verify against the source URL before client-facing quoting. It does not explicitly name alternative tools or exclusion criteria, so it misses the top score.

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 this as read-only and idempotent, and the description is fully consistent. Beyond the annotations, it discloses the tool's key behavioral boundary — it computes but does not judge — and explains the expected analyst contribution: reasoning per segment, supplying rationale, and marking the output as an AI interpretation. This is materially useful context.

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

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

The description is dense but every sentence carries important information: mechanics, usage context, a real-world example, and analyst responsibilities. It could be slightly tightened or broken into bullets, but it remains well front-loaded with the core function and does not waste words on filler.

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

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

For a valuation tool with no output schema, the description covers the full workflow: valuation logic, segment structure, citation of peer inputs, rationale expectations, and metadata handling. An agent has enough to call the tool correctly and to present the result appropriately in a report.

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 schema description coverage at 0%, the description compensates well: it enumerates the allowed metric types, clarifies that 'Direct EV' supplies the segment value directly while other metrics use a multiple, and traces how cash, netDebt, and sharesOutstanding feed into the final per-share value. companyName is not explicitly mentioned, but its meaning is self-evident, so the gap is minor.

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 opens with a specific verb and resource: 'Runs a Sum-of-the-Parts valuation,' then walks through the exact valuation waterfall. It also distinguishes itself from a single blended DCF/multiple by stating it is for companies whose segments have genuinely different economics, which separates it from dcf_valuation and comparables_valuation 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?

It explicitly says when to use this tool ('Use this instead of a single blended DCF/multiple for a company whose segments have genuinely different economics') and gives a concrete example. It also tells the agent what not to expect ('does NOT choose the multiples for you') and directs it to peer-comparison tools for support, making the selection and invocation decision clear.

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