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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the overview is sourced from the company's own site and LinkedIn, which is useful behavioral context about data provenance. However, it does not disclose limitations (e.g., private companies may have sparse data) or any failure modes, so it adds moderate value beyond annotations.

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

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

The description is a single sentence, which is concise and front-loads the core purpose. However, it omits critical usage and parameter information, so it does not fully earn its place. It is not overly verbose, but the missing details make it less effective than it could be.

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 nested context object, multiple optional parameters, and no output schema, the description is incomplete. It does not explain how to provide the company (e.g., via context.company), how to use companyDomain, or the significance of country or sector. The agent is left with insufficient information to correctly invoke the tool beyond the schema names.

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 does not mention any parameters at all. Schema description coverage is 0% (the description does not explain any of the inputs). The required context object and its sub-properties (company, companyDomain, country, etc.) are left entirely to the schema. The description fails to compensate for the lack of parameter documentation, so an agent has no guidance on how to specify the target company or domain.

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

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

The description clearly states the tool produces a narrative business overview (what the company does, products/services, target market) and identifies sources (company's own site and LinkedIn). The verb 'produces' is specific, and the resource is the company overview. It distinguishes from siblings like industry_overview or market_size by focusing on a single company, but does not explicitly differentiate from company_profile, so it's clear but not perfectly distinguished.

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 guidance is given on when to use this tool versus alternatives like company_profile or industry_overview. It does not state any conditions, exclusions, or mention sibling tools. The agent is left to infer when this is the right choice.

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 safety profile is covered. The description adds that it searches multiple external sources and the company's own site, which is useful context. However, it doesn't disclose potential failure modes, data availability limitations, or that results may be incomplete—gaps that are more relevant given the openWorldHint.

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, front-loaded sentence that efficiently conveys the core purpose and sources. No filler or repetition—every word 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 tool with a nested required parameter (company) and zero schema coverage, the description is incomplete. It doesn't tell the agent what to supply for the context object, how optional fields like country or listed affect results, or what the return looks like (no output schema). An agent would struggle to invoke this correctly without additional inference.

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, but it provides no explanation of the parameters. The nested context object includes company (required), date, listed, sector, country, and companyDomain, but the description doesn't mention any of them, how they influence the search, or what the required company field means. The schema's own descriptions are sparse, leaving the agent with little 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 clearly states the action (retrieves) and resource (registry-grade company profile facts) with specific data points (CIN, incorporation date, registered office). It also names the data sources (MCA/Tofler/Zauba/OpenCorporates and company site), which helps distinguish it from siblings like company_overview or search_company, though it doesn't explicitly call out alternatives.

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 no guidance on when to use this tool versus siblings. It doesn't state that this is for registry facts specifically, nor does it mention exclusions like 'use financial_statements for financials'. The context of 'registry-grade' implies a purpose, but there is no explicit when/when-not 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 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 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?

The description discloses the heuristic extraction method, ranking signals (mention frequency and listed-company signal), and deterministic top-5 selection. This adds behavioral detail beyond the readOnlyHint and openWorldHint annotations. No side effects or contradictions are present.

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 dense sentence, but it remains readable and contains substantive information about the process and output. It is concise without being overly terse, though the long em-dash clause slightly reduces clarity.

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

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

The description explains the core workflow and output ('returns a top-5'), but it does not describe the expected output structure or clarify how optional inputs like sector, country, and listed affect results. Given there is no output schema, more detail about the return format would improve completeness.

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 does not explain the required 'context' object or its properties. Schema coverage is low, with only some properties having descriptions, and the description adds no additional parameter guidance for fields like company, country, listed, or date. The agent must infer meaning from the schema alone.

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 function: searches industry-analyst and news sources for named competitors, extracts and ranks candidates, and returns a top-5. It also differentiates from similar tools by noting that the server deterministically picks peers instead of leaving selection to the calling model.

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 explains what the tool does and contrasts it with model-driven peer selection, but it does not explicitly state when to use this tool versus alternatives like comparables_valuation or listed_peer_comparison. Some guidance is implicit, but explicit when-to-use/when-not-to-use instructions are missing.

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 several behavioral traits beyond annotations: the source waterfall order, inline computation of ratios and CAGR, and the structured not_available fallback instead of bare nulls. These details help set expectations accurately.

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 moderately long but each sentence adds value, covering the waterfall, return shape, inline computation, and error handling. It could be slightly more concise by trimming redundant phrasing, but it is well-structured.

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 (nested context object, multiple sources, no output schema), the description covers data sources, return shape, and error behavior adequately. However, it does not clarify the role of the 'listed' and 'country' fields in the context object, which are only partially described in the schema.

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

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

The description adds no additional meaning for individual parameters beyond what the schema already provides. With only 50% schema description coverage and no parameter-specific clarification, this dimension falls short.

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 retrieves financial statements, with a specific verb and resource. It also distinguishes the output shape as the one consumed by ratio_analysis, providing clear purpose.

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 lacks explicit guidance on when to use this tool versus sibling tools. It mentions the return shape is the same as ratio_analysis consumes, which implies a use case, but it does not name alternatives or provide conditions for 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?

The description states it searches and extracts information, aligning with the readOnlyHint annotation. It does not mention side effects or modifications, consistent with a read-only operation. However, it does not disclose potential limitations or data coverage beyond listing sources.

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, clear sentence that efficiently conveys the action and scope. It is well-organized and free of unnecessary words.

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

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

The description lacks details about output format or how the extracted facts are presented. With no output schema and no parameter explanations, the tool's full behavior is under-specified. The purpose is clear, but the lack of parameter semantics and usage guidance leaves gaps 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?

The description provides zero coverage of the parameters, despite the 'context' object containing multiple fields like date, listed, sector, and country. None of these are explained. The only implicit reference is 'company' in the phrase 'company's funding rounds'.

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 tool's purpose: searching multiple databases for funding rounds, investors, and valuation mentions, and extracting candidate facts. It specifies the resource (company funding history) and the sources, making its role distinct from other finance 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?

No explicit guidance is provided on when to use this tool versus alternatives like company_profile or financial_statements. The description implies it is for funding history but does not state conditions or exclusions. Given the large sibling set, more direction would be beneficial.

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, 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?

The description uses the verb 'Retrieves', which is consistent with the readOnlyHint annotation and implies no side effects. It adds context about the nature of sources but does not disclose additional behavioral aspects such as rate limits, error handling, or data completeness beyond what annotations already 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 two sentences long, front-loaded with the primary action and purpose. It efficiently lists content areas and sources without unnecessary verbosity, maintaining clear structure and readability.

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 function and gives usage hints for the main parameters, but it omits details on other parameters like country or listed and does not mention geographic scope or output format. While not critically incomplete for a research retrieval tool, it could be more thorough given the nested context object.

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 only elaborates on two of the six parameters inside the context object (sector and company), explaining when to pass them and the fallback behavior. It does not mention date, listed, country, or companyDomain, leaving their semantics solely to the schema descriptions. Given the low schema description coverage, the description should have compensated but only partially does.

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

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

The description clearly states the tool's function: 'Retrieves macro/industry-level research' and specifies the content (market structure, key players, growth drivers, TAM/market size) and sources (top-tier consulting/research). It also explains its purpose as providing the industry-wide context for a company-specific 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 description provides usage guidance by instructing to 'Pass context.sector when known for a sharper search' and explaining the fallback to company's industry. However, it does not explicitly state when to prefer this tool over alternatives like company_overview or market_size, nor does it give clear when-not-to-use conditions.

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 matches the readOnlyHint annotation by stating it 'retrieves' data, so there is no contradiction. However, it adds no additional behavioral details beyond the annotation, such as rate limits, data freshness constraints, or any side effects, so it adds minimal transparency beyond the annotation.

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, well-structured sentence that front-loads the action and includes essential details (sources, sorting). There is no fluff or redundancy, making it appropriately concise and clear.

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 nested context object and the daysBack parameter, the description is too sparse to be considered complete. It does not indicate that company is required, explain the role of daysBack, or clarify how the country or domain parameters affect results. The schema provides limited help (some nested descriptions), but the overall tool context is not sufficiently covered by the description.

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 description does not explain the meaning or purpose of any parameter, including the required context object or the daysBack field. With 0% schema description coverage on top-level parameters, the description contributes no semantic value to understanding how to use the 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 clearly states the tool retrieves recent news coverage for a company, specifies the exact news sources (Reuters, Economic Times, Mint, Business Standard, Moneycontrol), and mentions sorting by publish date, leaving no ambiguity about its purpose.

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 no guidance on when to use this tool versus alternatives such as negative_news or other news-related tools. It does not mention any selection criteria, exclusions, or conditions that would help an agent decide between this and 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, so the description doesn't need to restate that. It adds value by naming external sources (screener.in, Trendlyne, Ace Equity-adjacent, exchange/finance portals) and the per-company invocation pattern. It does not mention any side effects or rate limits, but given the read-only annotation, that is acceptable.

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 a dash, effectively front-loading the core purpose and sources. It is not overly verbose and conveys essential information in one line. A slightly more structured format could improve readability, but it is appropriately concise.

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

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

Given the lack of an output schema, the description should explain what the tool returns (e.g., a snapshot object with fields). It does not mention the return format or any error behavior (e.g., unlisted company handling). It does clarify the usage pattern (once per company) and the purpose, which covers part of the context, but missing output details and edge-case guidance makes it incomplete for a tool with a nested object 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?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It fails to explain the 'context' object structure, the required 'company' field, or optional fields like 'listed', 'sector', 'country', and 'companyDomain'. The description mentions metrics like market cap but does not connect them to any parameter. This is a significant gap for an agent needing to construct a valid request.

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 action: 'Retrieves a listed company's own financial snapshot' and specifies key metrics (market cap, P/E, shareholding-pattern context). It also explains the intended purpose of building a peer-comparison table, which distinguishes it from generic overview or financial statement tools. However, it does not explicitly name alternative sibling tools, so differentiation is implicit rather than explicit.

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

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

It provides clear guidance: 'meant to be run once per company (the target and each peer discover_competitors identifies)'. This tells the agent when to invoke it and references a specific sibling (discover_competitors) as the source of peers. It lacks explicit exclusion of other tools (e.g., company_overview), but the usage scenario is well-defined.

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, covering the safety profile. The description adds meaningful behavioral context by specifying the exact sources screened and the categories of legal/regulatory data returned, which goes beyond the bare annotations. It does not describe output format or pagination, but that is not critical given the read-only research nature.

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

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

Two sentences, zero fluff. The purpose is front-loaded, and the sibling distinction is given in a single clause. Every word 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 tool has a nested required parameter (context.company) plus several optional fields, but the description does not explain when to set 'sector', 'listed', 'country', or 'companyDomain', nor what the output looks like. The sources are India-specific, yet the schema allows 'country' to be 'global', which could confuse an agent. This is a moderately complex tool that needs more operational detail to be fully usable.

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%, meaning the description provides no guidance on any parameter. The schema itself only describes 'date' and 'companyDomain', leaving 'company', 'sector', 'listed', and 'country' undocumented. The description does not compensate by explaining how to fill the context object, making parameter usage entirely unclear. This is a significant gap for a required nested 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 states a specific verb ('screens'), names the exact sources (SEBI, NCLT, IndianKanoon, LiveLaw, Bar & Bench), and enumerates the record types found (litigation, regulatory penalties, insolvency, director disqualification). It also explicitly distinguishes itself from the sibling negative_news, so an agent can reliably tell them apart.

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 the alternative tool (negative_news) and the condition that selects it: use this tool for hard legal/regulatory records, use negative_news for general press/employee sentiment. This gives clear when-to-use guidance and prevents mis-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?

The readOnlyHint annotation already signals no side effects, and the description adds useful context about relying on analyst/research sources and extracting approximate numeric estimates via pattern matching. This helps set expectations about data provenance and precision.

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, focused sentence that front-loads the main purpose and adds a concise behavioral detail. No unnecessary words or redundant 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?

There is no output schema, and the description only implies that numeric market size and CAGR estimates are returned. It does not describe the return format, units, source attribution, or how output may vary based on optional inputs, leaving moderate ambiguity.

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

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

The schema has nested parameters with almost no descriptions, and the tool description does not explain how parameters like company, country, listed, or date affect the market size lookup. The description only references 'industry', leaving important parameter behavior unclear.

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 specific function: finding market size and CAGR figures for an industry from research sources. It is distinguishable from sibling tools like financial_statements or dcf_valuation because it focuses on market-level numeric estimates, though it does not explicitly name an alternative.

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

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

The purpose implies usage for market-sizing questions, but there is no explicit 'use when' guidance or notes about when to prefer this over related tools like industry_overview. Usage intent is inferable but not directly stated.

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

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

The description uses 'Screens' which implies a read-only operation, consistent with the readOnlyHint annotation. It also aligns with the openWorldHint by referencing external sources (Glassdoor, Reddit). It does not contradict the annotations, and the behavioral scope is clear from the wording.

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: the first states the core function and scope, the second provides an important alternative. It is concise, front-loaded with the primary purpose, and contains no redundant information.

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

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

For a screening tool with a single nested object parameter, the description adequately conveys the purpose and the types of data covered. It lacks details on output format or parameter details, but given the absence of an output schema and the straightforward nature of the parameters, this is acceptable. The mention of the alternative tool adds practical completeness.

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 does not explain any parameters explicitly. It mentions 'about a company' which loosely relates to the 'company' field, but other parameters like country, sector, and companyDomain are not described. With schema description coverage at 0%, the description fails to compensate for the lack of parameter guidance, leaving agents to infer from names alone.

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 function: screening news and public-sentiment sources for adverse media and complaints, and explicitly lists the types of issues (fraud, layoffs, defaults, controversy) and the purpose (due diligence/risk screening). It also names specific sources (Glassdoor, Reddit), making the scope unambiguous.

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

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

The description provides an explicit contrast with litigation_history: 'For hard regulatory/legal records... use litigation_history instead.' This tells the agent when not to use this tool and directs to an appropriate alternative, though it doesn't mention other related tools like latest_news or red_flag_screen.

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 the type of records it checks (disqualification, debarment, penalty) and the data sources, adding context beyond the readOnlyHint annotation. No contradictions with the read-only or open-world hints.

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 concise sentences with no redundancy. The instruction is front-loaded and the supplementary guidance about screening a company's leadership is efficiently placed.

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 nested object schema and absence of an output schema, the description sufficiently explains the tool's purpose and how to specify the target. It does not describe output format, but that is not required here.

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

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

The description clarifies the main parameter (context.company) but does not add meaning for other fields like date, listed, or sector. The schema already provides descriptions for most parameters, so the added value is limited.

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?

Clearly states the tool screens a promoter or director against SEBI/MCA/registry sources for disqualification, debarment, or penalties. The specific verb 'screens' and the resource list make the purpose unambiguous and distinct from general company research 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?

Provides explicit instruction on how to pass the target (individual or company) via context.company. It does not explicitly contrast with sibling tools like red_flag_screen or litigation_history, but the purpose is so specific that when to use it is implied.

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?

The annotations indicate readOnlyHint and openWorldHint, and the description aligns with these by describing a search/discovery operation. The description adds context about domain-restricted search and authoritative source URLs, but it does not explicitly mention potential empty results or the exact return format. However, the read-only nature is clear and there is no contradiction.

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 concise, at two sentences, and front-loads the primary action and purpose. It avoids redundant or extraneous information, making it easy for an agent to quickly understand the tool's function and placement.

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 provides enough context for an agent to know when to use the tool and what kind of output to expect (authoritative source URLs). Since there is no output schema, the description partially compensates by mentioning website, LinkedIn, and registry presence, but it could be more explicit about the exact return structure or potential edge cases.

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 nested schema describes some fields (date, sector, companyDomain) but lacks descriptions for others such as company, listed, and country. The 'company' field is obvious from context, but 'listed' and 'country' would benefit from explanations. The description of the tool does not add much beyond the schema for individual parameters, so the semantics are only partially clarified.

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: discovering a company's official website, LinkedIn, and registry presence via domain-restricted Exa search. It also distinguishes this tool by specifying that it should be used first to resolve a company name to authoritative source URLs before other company tools, making its role unique among the sibling 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 explicitly instructs when to use the tool: 'Use this first to resolve a company name to authoritative source URLs before calling other company tools.' This provides clear guidance on the tool's position in a workflow and implies that it should be used before downstream data-gathering tools.

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