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

Annotations already establish this is a read-only, idempotent, non-destructive computation, so the description's main added value is the soft hint that it is a pure pricing function. It notes the return contents, but an output schema already exists, so the description adds little behavioral context beyond the structured data.

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 padding, and the core capability is front-loaded ahead of the alternative-tool 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?

With a 100%-documented schema and an output schema present, the description covers what an agent needs to select and call the tool. It could note key model assumptions (e.g. no dividend yield, European exercise only beyond the single mention) but is otherwise adequate.

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

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

Schema coverage is 100% and each input (spot, strike, maturity, risk_free, volatility, option_type) is fully described in the schema. The description adds only the model-level constraint that inputs must correspond to a European option; it contributes no unit or format detail beyond the schema.

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

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

States a specific verb (price), resource (European call/put), and named model (Black-Scholes-Merton). It also draws a boundary against swap, convertible bond, futures, and greeks tools, so an agent can route correctly without inspecting 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?

Explicitly scopes usage to a single European option and lists what to use instead for swaps, convertible bonds, futures, and greeks. The alternatives are referred to generically as 'the delegated derivatives tools' rather than by concrete tool name, which leaves a small routing gap.

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 destructiveHint=false, so the safety profile is covered by structured data. The description adds the formula and states the return currency, but says nothing about validation failures, precision, or error behavior beyond what annotations and the output schema supply.

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 short sentences with zero filler: what it computes, when to use it versus alternatives, and what it returns. The purpose is front-loaded and the routing guidance follows immediately.

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 full schema coverage, annotations, and an output schema, the description covers purpose, formula, scope and return currency adequately. The only gap is the unclear reference to unspecified 'delegated credit-risk tools' for the portfolio case.

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

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

Schema description coverage is 100%, so EAD, PD and LGD units/ranges are already documented in the schema; baseline for that is 3. The description adds only the relationship among the three inputs via the formula, not per-parameter syntax or edge cases.

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

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

States a specific verb and resource ('Compute IFRS 9 / HKFRS 9 expected credit loss') and gives the exact formula EAD x PD x LGD, so the agent knows precisely what is calculated. It also distinguishes itself from portfolio/staging 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?

Explicitly scopes usage to a single exposure and routes portfolio or staging PD models elsewhere, which is clear when-to-use guidance. The alternative is only referred to vaguely as 'the delegated credit-risk tools', which do not appear in the sibling list, so routing is not fully actionable.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the computation semantics (the after-tax debt shield in the formula) and notes the return payload, but does not discuss validation behavior for weights not summing to 1 or null tax handling.

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, front-loaded with the operation and formula, then the usage condition, then the return shape. Every sentence carries distinct information and there is no padding.

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

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

An output schema exists, so return values need not be spelled out, yet the description still summarizes the WACC plus equity/debt contributions. Combined with full schema coverage and a clear alternative-tool pointer, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the formula adds genuine meaning the schema does not: it shows how the four required parameters combine and that tax_rate is applied only to the debt term as (1 - tax). That clarifies the optional parameter's role beyond 'marginal corporate tax rate'.

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 (Compute) plus the exact resource (WACC) and even the formula, so the agent knows precisely what is produced. It explicitly distinguishes itself from get_valuation_summary, which handles the upstream data-derivation step, so sibling disambiguation is done in the description itself.

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?

Gives an explicit precondition ('when you already have the weights and component costs') and an explicit alternative with its selecting condition ('to derive them from market data use get_valuation_summary first'). Nothing about when-to-use versus the 30+ siblings is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description's 'Read-only' restates the annotation, though 'fetches live market data' adds useful open-world context. No detail on latency, rate limits, or data freshness beyond 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?

Three compact sentences with the return contents front-loaded, followed by usage and safety notes. Only real waste is the duplicated 'price' in the metric list; otherwise 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?

An output schema exists, so return values need not be spelled out. The description covers what is fetched, why, and its read-only/live nature, leaving little an agent would need before calling it with a ticker.

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

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

Schema coverage is 100% with a single documented 'ticker' parameter, so the schema carries the semantics. The description adds nothing about ticker format, exchange suffixes, or resolution behavior, making the baseline 3 correct.

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 (Return) and resource (company profile with key market metrics), and lists the concrete fields returned (price, market cap, beta, P/E, volatility). This distinguishes it from the many valuation_* calculation siblings, which compute rather than fetch. Minor blemish: 'price' is listed twice.

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?

Gives clear when-to-use context: 'to gather inputs for a valuation or to sanity-check a fair value against the market.' However, it names no alternatives (e.g., when to prefer a valuation_* tool) and provides no exclusions, so routing against siblings is left partly 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context beyond them: macro-enabled and unsafe files are rejected, external-data formulas are flagged, and the output is 'findings plus a review report'. It does not say what happens on partial/inconclusive analyses or how findings are structured, but this is a strong disclosure for a read-only tool.

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

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

Three sentences, front-loaded with the analysis scope, then the audit-vs-produce routing, then constraints and return behavior. Dense and largely waste-free; the closing 'Returns findings plus a review report' is mildly redundant given an output schema exists, but it frames the response shape.

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

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

An output schema exists, so return values need not be detailed, and annotations cover safety. The description still supplies the missing pieces an agent needs: accepted input formats, the audit (not generate) intent, rejection rules, and flagging behavior. Nothing material for correct invocation is absent.

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

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

There is a single parameter with 100% schema description coverage; the schema already documents the accepted extensions (.xlsx/.xls, .pdf, .docx/.doc, images). The description's file-type mention mirrors the schema rather than adding format, path-resolution, or size/location semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Analyze an existing valuation report') and enumerates the exact checks performed: methodology, formulas, WACC and terminal value, key assumptions, data sources. It also proactively distinguishes itself from the entire valuation_* sibling family by declaring it audits rather than produces a 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?

Provides a clear when-to-use rule ('Use this to audit a document rather than to produce a valuation'), which is exactly the disambiguation needed against 33 valuation_* siblings. It does not name a specific alternative tool or state exclusions, so it stops short of a full 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious traits: deterministic computation, no external calls, no authentication, unsupported fields returning an error envelope rather than raising, and a shared result envelope. This is substantive context beyond the annotations, though the envelope itself is not described.

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

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

Front-loads name and purpose, but wastes words on the redundant 'valuation valuation capability' and repeats the tool name specifying itself as the target. The routing and behavior sentences earn their place; the framing is 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?

An output schema exists so return values need not be spelled out, but the opaque 'arguments' pass-through means an agent cannot discover supported fields from either the description or the schema. The pointing to a tool schema that is not exposed is the key gap, leaving it only minimally sufficient.

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

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

Schema coverage is 100% and there is a single 'arguments' parameter already documented in the schema. The description restates that fields must match the upstream tool's schema and that unsupported fields error, but the upstream schema is never shown, so it adds no usable field-level meaning. Baseline 3 applies.

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

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

It identifies itself as a startup valuation capability covering corporate/startup/intangible cases and as a fallback endpoint, but the phrasing is circular ('valuation valuation capability') and the referenced native 'valuation_advanced' tool is not in the sibling list, leaving the actual scope ambiguous. An agent can infer it is a catch-all proxy, but not precisely what it computes.

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 states when to use it (only for the startup case native tools do not handle) and names concrete alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price). The routing intent is clear, though only a fraction of the 30+ siblings are enumerated.

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 annotations (readOnly, idempotent, non-destructive, closed-world), the description adds that computation is deterministic, requires no external calls or authentication, that unsupported fields return an error envelope rather than raising, and that it returns the shared result envelope. These are genuinely useful behavioral facts not derivable from the annotations, though error-envelope shape details remain thin.

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 routing guidance is front-loaded, which is good, but the paragraph is long and run-on, and phrases like 'a startup valuation valuation capability' and repeated self-naming ('the startup valuation valuation_biotech case') waste space. Some trimming would sharpen it without losing 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?

An output schema exists, so return values need not be explained, and the description covers routing, safety, and error behavior. However, for a domain-specialized valuation tool the description is silent on what inputs the biotech case expects or what it models, leaving a real completeness gap despite the passthrough 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?

Schema description coverage is 100% and there is only one passthrough 'arguments' parameter, so the schema already carries the baseline. The description adds that unsupported fields produce an error envelope, but it defers field enumeration to 'that tool's schema,' which is not exposed here, so it does not meaningfully help an agent know what to pass.

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

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

The description identifies the resource as a 'startup valuation valuation capability' and frames it as a domain-specific case, but the phrase 'valuation valuation' is redundant and it never says what biotech-specific valuation actually computes (e.g., pipeline/rNPV logic) beyond restating its own name. An agent learns it is a startup-valuation variant but not what distinguishes it substantively from valuation_saas, valuation_technology, or the native 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 gives explicit routing: 'Use it only for the startup valuation ... case that the native tools do not handle; prefer the native tool (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, or black_scholes_price) whenever it applies.' That names alternatives and a preference order. It stops short of 5 because the criterion for when the biotech case 'applies' is never made concrete.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description goes beyond them by disclosing no external calls, no authentication, and that unsupported fields yield an error envelope rather than raising. This is useful operational context beyond the structured 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?

The description is front-loaded with the routing rule and is reasonably sized for a proxy tool. Minor slack from boilerplate phrasing and the 'startup valuation valuation' redundancy, but no wasted paragraphs.

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

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

An output schema exists, so return values need not be explained, and the routing/behavior story is complete. However, the actual callable semantics are delegated to an external schema that the agent cannot see, leaving the arguments' accepted fields opaque.

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 there is a single passthrough 'arguments' object, so the baseline is 3. The description only adds that arguments must match 'that tool's schema' (which is not supplied here) and that unsupported fields error out; it does not clarify any expected field semantics.

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

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

The description identifies the tool as a 'startup valuation capability' but never states what CAPM actually computes (e.g., cost of equity), and it contains a redundant phrase ('startup valuation valuation capability'). It does distinguish itself from siblings by positioning itself as a fallback, which lifts it above pure tautology, but the core purpose stays vague.

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 gives explicit when-to-use guidance ('use it only for the startup valuation valuation_capm case that the native tools do not handle') and names concrete alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) to prefer. The only weakness is the somewhat circular naming of its own case rather than describing the computation that should trigger it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the return shape ('an implied value per multiple and an average'), but says nothing about data sourcing for peers, precision, or behavior when peer_metrics is omitted. Some added value, but nothing beyond the baseline.

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

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

Two tight sentences: method first, routing second, output third. No filler, well front-loaded, and every clause is load-bearing.

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 an output schema present and annotations covering safety, the description need not explain return values, and it names the method and the primary alternative. It is slightly incomplete on the null-default behavior of peer_metrics/target_metrics (does the tool fetch or require them?) and on differentiation from the other comparable/market-approach siblings.

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%, so ticker, peer_metrics and target_metrics are already documented in the schema. The description echoes the multiples (P/E, P/B, P/S, EV/EBITDA) but adds no syntax, format, or defaulting semantics beyond what the schema states (median vs mean aggregation is the only real addition).

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

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

States a specific verb and resource ('value a company by applying median peer multiples...') and enumerates the multiples used, so the method is unmistakable. It distinguishes itself from valuation_dcf. However, it never distinguishes itself from the closely named siblings valuation_comparables and valuation_market_approach, which an agent could reasonably confuse with this tool.

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

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

'Use this for market-based pricing when comparable peers are available; for intrinsic value use valuation_dcf' gives an explicit condition plus a named alternative. The gap is that the two most likely alternatives (valuation_comparables, valuation_market_approach) are never addressed, leaving real routing ambiguity within the sibling set.

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, and the description adds real behavioral context beyond them: deterministic computation, no external calls, no authentication required, and the failure mode that unsupported fields return an error envelope rather than raising. That error-handling detail is genuinely useful and not in 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?

Reasonably front-loaded, but there is redundancy — 'startup valuation valuation capability' and repeated self-reference to 'valuation_comparables' — that eats space without adding meaning. The routing and behavior content earns its place; the framing sentences do not.

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

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

An output schema exists, so return values need not be explained (it just points to the shared result envelope). With annotations and schema covering safety and parameters, the description supplies auth posture and failure behavior, leaving little an agent needs that is missing.

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

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

Schema coverage is 100% and there is a single optional 'arguments' wrapper, so the baseline is 3. The description confirms arguments follow the underlying tool's schema and notes the error behavior for unsupported fields, which adds marginal value but no field-level 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?

It names the resource ('valuation_comparables') and scopes it to the startup valuation case, but the description is largely circular — 'a startup valuation valuation capability' — and never explains what comparables analysis actually computes. It does route the agent away from named siblings, which helps distinguish it, but the core purpose stays vague.

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?

Explicit when-to-use logic: 'Use it only for the startup valuation case that the native tools do not handle; prefer the native tool (valuation_dcf, valuation_nav, valuation_cca, ...) whenever it applies.' It names alternatives and a fallback condition, though what the 'startup valuation comparables case' concretely is remains undefined.

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?

Adds useful behavioral context beyond the readOnlyHint/idempotentHint annotations: deterministic computation, no external calls, no authentication required, and unsupported fields return an error envelope rather than raising. These error-handling and side-effect details are not in the annotations. Minor gap on how the shared result envelope is structured, but output schema exists.

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

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

The definition is a single dense paragraph but is somewhat repetitive ('valuation compliance (valuation_compliance)', 'intangible valuation valuation capability') and awkwardly phrased. It front-loads the identity and usage, so it is functional, but the malformed phrasing and redundancy hurt structure.

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 an output schema exists, the description need not explain return values, and it covers usage, read-only determinism, argument forwarding, and error behavior. An agent can call it correctly. The remaining gap is the vague nature of the 'compliance' case itself, but the tool is largely complete for 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?

Only one parameter ('arguments') and schema coverage is 100%, so the schema documents it fully with a description pointing to the underlying tool's schema. The description confirms that arguments are forwarded to the intangible valuation tool and that unsupported fields error out, adding a small semantic note, but the schema already carries the parameter contract. 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 description states it is a 'valuation compliance' capability for 'intangible valuation,' a specific verb-resource pairing. However, 'valuation compliance' is tautological with the tool name and the phrase 'a intangible valuation valuation capability' is malformed and ambiguous, leaving the actual purpose of the compliance check vague. It does distinguish itself from siblings by naming them and by restricting to the intangible compliance case.

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

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

Explicitly tells the agent to use this only for the intangible valuation 'valuation_compliance' case that native tools don't handle, and to prefer native tools (valuation_dcf, valuation_nav, etc.) when they apply. That is a clear when-to-use and when-to-prefer-alternative rule, though it does not specify concrete conditions that select this tool beyond 'native tools don't handle it.'

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, but the description adds genuinely new behavioral facts: deterministic computation, no external calls, no authentication, and that unsupported fields return an error envelope rather than raising. The only weak point is the unexplained 'shared result envelope', which is vague despite an output schema existing.

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 routing constraint and safety profile are front-loaded, and the sentences are mostly information-dense. Minor redundancy ('a startup valuation valuation capability', restating 'valuation_core' twice) costs it a point, but nothing is padded with 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 thin dispatcher wrapper over an underlying schema, the description covers the essentials: purpose, routing, error behavior, and safety, and an output schema exists so return values need not be explained. The undefined 'shared result envelope' reference and the missing pointer to the actual underlying schema for supported fields leave a small 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?

There is a single 'arguments' parameter at 100% schema description coverage, so the schema already carries the load and a 3 is the baseline. The description adds only marginal value by noting the object must match the underlying tool's schema and that unknown fields error out rather than being silently ignored.

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+resource (startup valuation computation) and explicitly frames itself as the fallback dispatcher alongside named native tools. It distinguishes itself from siblings by listing the tools it should not replace. The phrasing 'the startup valuation valuation_core case' is somewhat circular and the duplicated word 'valuation valuation' muddies the statement, keeping it below a 5.

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

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

It gives explicit when-to-use ('only for the startup valuation case the native tools do not handle'), when-not ('prefer the native tool whenever it applies'), and enumerates six concrete alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price). Routing is fully specified with no inference required.

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 annotations (readOnly, idempotent, non-destructive, closed-world), the description adds that it is a deterministic computation with no external calls and no authentication, and that unsupported fields return an error envelope rather than raising. These are genuinely useful behavioral details that the annotations do not 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 name is front-loaded, but the first sentence is padded ('a intangible valuation valuation capability, exposed through this server so one endpoint covers corporate, startup, and intangible valuation') and contains repetition and awkward phrasing. The useful routing and behavioral content is buried behind 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?

An output schema exists so return values need not be described, and safety/error behavior is covered. However, the actual computation and the shape of the expected arguments remain unspecified beyond pointing back at the tool's own schema, leaving an agent under-informed about what a correct call looks like.

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

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

There is a single 'arguments' parameter with 100% schema description coverage, so the schema does the heavy lifting. The description only adds that unsupported fields produce an error envelope, but defers the real field list to "that tool's schema," which is circular and adds little syntax or format 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 identifies the category (an intangible valuation capability using the cost approach) and ties it to the tool name, but it never explains what the cost approach actually computes. It largely restates the name ("the intangible valuation 'valuation_cost_approach' case") and is circular rather than stating a concrete verb+resource with a described operation.

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 gives explicit routing guidance: use only for the case the native tools do not handle, and prefer the named native tools (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) whenever they apply. This is clear when/when-not guidance with named alternatives, though the condition selecting this tool is itself circular ("the case the native tools do not handle").

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 annotations' readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, the description adds that the computation is deterministic, requires no authentication, makes no external calls, returns an error envelope for unsupported fields, and uses a shared result envelope. These are useful behavioral details an agent needs when deciding whether the fallback is safe and appropriate. Nothing in the description 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?

The description is mostly front-loaded and covers purpose, usage, and behavior in order. However, it contains redundancy and awkward phrasing, especially 'a intangible valuation valuation capability' and the broad claim that 'one endpoint covers corporate, startup, and intangible valuation'. Those sentences do not clearly earn their place for this specific tool.

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?

Annotations cover the safety profile and an output schema exists, so return values do not need explanation. The description still leaves a substantial gap by not explaining what this fallback actually does or how to populate the arguments object beyond referring to an unspecified 'that tool's schema'. Given the one-parameter wrapper shape, it is minimally adequate but not fully complete.

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 input schema already has full description coverage for its single 'arguments' parameter, so the baseline is 3. The description reinforces that arguments must match the underlying tool's schema and that unsupported fields produce an error envelope, which is useful but does not add field-level semantics. No additional parameter meaning is provided beyond what the schema documents.

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

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

The description identifies the tool as a fallback intangible valuation capability and names the 'valuation_customer' case, but it does not specify what this operation actually computes. Phrases like 'intangible valuation valuation_customer case' largely restate the tool name rather than explaining the resource or calculation. It does distinguish from siblings by positioning itself as the non-native fallback, which keeps it above tautology but still vague.

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 to use this tool only when the native tools do not handle the intangible valuation case, and it names several preferred alternatives including valuation_dcf, valuation_nav, and calculate_wacc. The missing piece is a precise explanation of when the native tools 'apply', which makes the routing condition somewhat circular. Still, the when-to-use and when-not-to-use guidance 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 establish readOnlyHint, idempotentHint, and openWorldHint, so safety behavior is covered by structured fields. The description adds useful context about the fallback ('omit them to derive from current market data') and the response shape ('fair value per share plus the WACC and terminal value'). It does not disclose what happens with partial assumption sets or error conditions, but with annotations covering the safety profile and an output schema present, a 3 is appropriate.

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

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

Three sentences, zero waste: purpose first, then the assumption-vs-derived behavior, then sibling routing, then return values. 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?

Given a 13-param tool with an existing output schema and annotations, the description covers purpose, fallback behavior, sibling alternatives, and return values. It could note anything about the granularity of the derived market data or whether partial assumptions are supported, but it is otherwise complete 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 coverage is 100% with per-parameter descriptions for all 13 fields, so the schema carries the parameter burden. The description adds only the high-level insight that assumptions can be supplied or omitted, without explaining syntax or precedence. Baseline 3 is correct.

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

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

The description states a specific verb+resource ('Value a company by discounting projected free cash flows to present value') and explicitly differentiates from two named siblings: valuation_nav for asset-heavy holding companies and valuation_cca for peer-based pricing. An agent can disambiguate among the 35 valuation_* siblings without opening any schema.

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

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

Explicitly names when to use this tool ('going-concern cash-flow businesses') and provides two concrete alternatives with the conditions that select them. This is textbook 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 cover readOnly/idempotent/non-destructive/closed-world, but the description adds genuinely new behavior: deterministic computation, no external calls, no authentication, and the error-envelope-instead-of-raise contract for unsupported fields. These are real operational facts not present in the structured fields.

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

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

Front-loaded with the name, but the phrasing is repetitive ('intangible valuation valuation capability') and the routing list of six sibling tools is dense. Most sentences earn their place, though the opening clause is filler.

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

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

With an output schema present, return values need no explanation, and the passthrough contract is stated. However, an agent still cannot tell what the discount rate tool computes or what arguments it accepts beyond being pointed at another schema, which is a real gap for a valuation capability.

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 one optional passthrough parameter with 100% schema coverage, so the schema already carries the meaning. The description adds only that fields are forwarded to the underlying tool's schema and that unsupported fields error out — marginal but correct. Baseline 3 applies.

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

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

The description defines the tool almost entirely by restating its own name — 'a intangible valuation valuation capability' — and never states what a discount rate computation actually produces (WACC-style discounting, intangible asset rate, etc.). It routes away from siblings but never positively establishes its own purpose, leaving an agent with no functional understanding of the resource.

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 gives an explicit routing rule: use only for the intangible 'valuation_discount_rate' case the native tools don't handle, and prefer named native tools (valuation_dcf, calculate_wacc, etc.) when they apply. The 'when-not' side is strong; only the boundary of 'which intangible cases' remains vague.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and the description is consistent with them. It adds genuine context beyond the annotations: no external calls, no authentication required, and the failure mode that unsupported fields return an error envelope rather than raising. It could go further on determinism guarantees or output shape, but the added detail is substantive.

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 routing guidance (when to use, which alternatives to prefer, safety profile) is front-loaded and each sentence carries information. It is slightly padded by the repetitive 'valuation valuation' phrase and an exhaustive sibling list when examples would suffice.

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 an output schema present, return values need not be spelled out, and the description instead notes the shared result envelope and the error behavior. Given the very simple one-parameter proxying surface plus rich annotations, the definition covers what an agent needs to invoke it, though the underlying computational scope remains 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?

There is a single optional 'arguments' object and schema coverage is 100%, so the schema already documents it fully. The description explains the forwarding contract ('pass an arguments object matching that tool's schema') and points to the underlying tool's schema for supported fields, but adds no field-level detail. That is the expected baseline when the schema does the heavy lifting.

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

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

The description names the resource ('startup valuation') and positions the tool within a broader valuation capability, and it distinguishes itself from siblings by listing the native tools it substitutes for. However, the phrasing is somewhat circular ('a startup valuation valuation capability') and never states which specific emerging-company method it computes, so the agent knows the category but not the substance.

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 tells the agent when to use it ('only for the startup valuation case that the native tools do not handle') and names six concrete alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) with a preference ordering. The gap is that it never defines what distinguishes the 'emerging' case from those alternatives, leaving the selection boundary fuzzy.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds meaningful behavior: deterministic computation, no external calls, no authentication required, and the fact that unsupported fields return an error envelope rather than raising. The error-handling contract in particular is behavior an agent could not infer from annotations alone.

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 routing information (prefer native tools) is front-loaded, which is good, but the opening sentence is padded with the redundant 'valuation valuation' phrasing and a server-exposition clause ('exposed through this server so one endpoint covers corporate, startup, and intangible valuation') that adds little. It is neither wasteful nor tight.

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

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

An output schema exists, so return values need not be explained, and the description still notes the shared result envelope. Combined with the routing guidance, error-envelope behavior, and no-auth/no-external-call facts, it is nearly complete; the only real gap is that the fintech-specific computation remains undefined.

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

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

With a single parameter and 100% schema description coverage, the baseline is 3. The description adds that 'arguments' is forwarded to the underlying tool's schema and that unsupported fields produce an error envelope, which is useful but does not compensate for the fact that the actual accepted fields are undefined (additionalProperties: true) and must be discovered elsewhere.

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

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

The description identifies the resource as a 'startup valuation' capability for the fintech case, but the phrasing 'a startup valuation valuation capability' is repetitive and never states what the fintech-specific valuation actually computes. It distinguishes itself from siblings only by saying native tools don't handle this case, which routes the agent but does not clarify the tool's own function. An agent knows it is a fallback valuation endpoint but not what makes the fintech case distinct.

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 states when to use this tool ('only for the startup valuation case that the native tools do not handle') and names the specific alternatives to prefer (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price). The fallback condition and the preferred tools are both spelled out, leaving nothing to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: deterministic computation, no external calls, no authentication, and unsupported fields returning an error envelope instead of raising.

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 reasonably front-loaded and covers usage, behavior, and return handling in a few sentences. However, the first sentence is largely tautological and repeats the tool name unnecessarily.

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?

It covers usage routing, read-only behavior, and error handling, and an output schema exists for return values. But because the underlying tool schema is not provided, the agent still cannot know what fields to pass in the 'arguments' object, leaving a significant gap for a wrapper tool.

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

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

Schema description coverage is 100% for the single 'arguments' parameter, so the schema already documents its purpose. The description only says to see the underlying tool's schema for supported fields, adding no concrete parameter semantics beyond what is structured.

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 restates the tool name and calls it 'a intangible valuation valuation capability,' which is tautological and never states what the tool actually computes (e.g., purchase price allocation for goodwill/intangibles). It does route the agent away from native tools, but the core purpose remains vague.

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 to use this only for the intangible valuation case the native tools do not handle, and lists specific native alternatives to prefer. The condition is somewhat circular, but the when-to-use versus alternatives guidance is clear enough for 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety bar is already met. The description adds genuine context beyond them: deterministic computation, no external calls, no authentication, and the error contract that unsupported fields return an error envelope rather than raising. It does not describe runtime cost, result envelope shape (though an output schema exists), or any limits.

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

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

Compact and front-loaded: the identity, routing rule, safety profile, and error behavior each appear once in a logical order. The only waste is the duplicated 'valuation valuation' phrasing and the slightly padding 'exposed through this server so one endpoint covers corporate, startup, and intangible valuation' clause.

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

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

An output schema exists, so return values need no explanation, and the auth/safety/error behavior is fully covered. The remaining gap is substantive: for a tool whose name is unrecognizable ('hardware'), the description never says what domain inputs or outputs distinguish it from the ~35 valuation siblings, leaving the routing decision under-specified at the exact point it matters.

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

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

There is a single passthrough 'arguments' object, whose schema definition already points the caller to the target tool's schema (100% coverage). The description reinforces this ('pass an arguments object matching that tool's schema') and adds the valuable failure semantics that unsupported fields yield an error envelope. For an inherently opaque forwarding parameter this is about as much as can be said.

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

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

The description identifies the resource as a 'startup valuation valuation_hardware capability' but never explains what hardware valuation actually computes, and the phrase 'valuation valuation' is a redundant restatement of the name. It does route the agent away from named siblings, which helps, but the core purpose stays opaque — an agent learns it is a valuation endpoint, not what it produces.

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 says to use it 'only for the startup valuation valuation_hardware case that the native tools do not handle' and lists the preferred alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price). That is clear when-to-use guidance. It loses a point because the selection condition is circular — 'the case native tools do not handle' is never defined by any observable input or output characteristic.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description reinforces it but also adds genuinely new behavior — deterministic computation, no authentication required, and that unsupported fields return an error envelope rather than raising. That error-handling disclosure is useful context beyond the structured fields.

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

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

Purpose and routing are front-loaded, which is good, but the text is repetitive and grammatically garbled ('a intangible valuation valuation capability') and spends a sentence restating its own name as the use case. The content is largely earned, but the redundancy costs it.

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

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

An output schema exists so return values need not be explained, and the routing/behavioral context is solid. The real gap is that the effective input contract lives in the referenced tool's schema, which is not supplied to the agent — so the description is complete on routing but incomplete on how to actually invoke it 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?

There is a single 'arguments' parameter at 100% schema coverage, and the schema itself explains it forwards to the target tool. The description confirms the pass-through and the error behavior on unsupported fields, but it defers field-level meaning to 'that tool's schema', which the agent cannot see — so no real semantic detail is added.

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 gives a category ('a intangible valuation valuation capability') and names the resource, but the phrasing is circular and partly tautological — it defines the tool by restating its own name ('the intangible valuation \'valuation_human_capital\' case'). An agent learns it is a human-capital intangible valuation, but not what it actually computes or returns.

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 states the when-not ('Use it only for the intangible valuation case that the native tools do not handle') and enumerates the preferred alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) with a clear precedence rule ('prefer the native tool whenever it applies'). This is exactly the routing guidance an agent needs among 30+ 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 read-only/idempotent/non-destructive/closed-world, but the description adds genuinely new behavior: deterministic, no external calls, no authentication required, and an error envelope rather than an exception on unsupported fields. That error-handling contract is valuable context beyond 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?

Front-loaded with the tool name and a routing rule, which is good, but the opening clause is awkward and repetitive ('a intangible valuation valuation capability') and the middle sentence restates the same routing idea. It is acceptable but not tightly written.

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

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

An output schema exists, so return values need no prose, and the description covers routing, auth, and error behavior. However, for a wrapper whose only job is forwarding arguments, it never tells the agent what valid arguments look like, leaving a real gap for 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 single 'arguments' param is documented in the schema as forwarded fields. The description adds only that unsupported fields return an error envelope and that callers should match 'that tool's schema' — useful, but it does not say where that schema lives or what fields are valid.

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?

It names the resource (an intangible valuation 'valuation_impairment' capability) but the purpose is largely circular — it describes itself as forwarding to the same-named tool rather than stating what an impairment computation actually produces. It does distinguish itself as the fallback that native tools don't cover, which is its one clear differentiator.

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?

Explicit when-to-use ('only for the intangible valuation case the native tools do not handle') and when-not ('prefer the native tool ... whenever it applies'), with named alternatives. The list of alternatives is partial relative to the large sibling set, but the routing intent is unambiguous.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world, so the bar is lower, yet the description adds real behavioral context: no external calls, no authentication, and the error-handling contract that unsupported fields return an error envelope rather than raising. The 'deterministic computation' and 'returns the shared result envelope' lines largely restate annotations/output schema, keeping this short of a 5.

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

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

Front-loaded with the tool name and its capability, followed by the routing rule, then the behavioral contract — a sensible order with no padding. Minor waste from repeated 'valuation' wording and the redundant restatement of read-only/idempotent traits already in annotations.

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

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

An output schema exists, so return values need not be explained, and the description does state the error contract. However, for a dispatcher whose entire payload is an opaque 'arguments' object, the description leaves the agent unable to determine which fields to supply, which is the single most important thing to convey 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?

Only one parameter exists with 100% schema description coverage, so the baseline is 3. The description adds the error-envelope behavior for unsupported fields, but the argument bag is an open object with additionalProperties=true and the description points the agent back to 'that tool's schema' — the same tool — rather than enumerating any supported income-method fields, so no real field semantics are conveyed.

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 verb-adjacent capability (intangible valuation via income methods) and gives the tool's routing identity, but it never says what an income method actually computes (e.g., DCF-based income approach, relief-from-royalty, MPEEM). The phrasing 'a intangible valuation valuation capability' and the self-referential 'intangible valuation valuation_income_methods case' restate the name rather than define the operation, so the agent knows the category but not the substance.

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 an explicit when-to-use rule ('only for the intangible valuation case that the native tools do not handle') and a named preference list, which is better than most. But the alternatives listed (dcf, nav, cca, wacc, ecl, black_scholes) omit the obvious competing siblings such as valuation_ip, valuation_royalty_analysis, valuation_technology, and valuation_customer, and 'the case the native tools do not handle' is never defined, so the routing boundary remains fuzzy.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: deterministic computation, no external calls, no authentication, and that unsupported fields return an error envelope rather than raising. That last point is especially valuable for an agent constructing arguments, and there is no contradiction with 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?

It is front-loaded with the name and a scope statement, and the fallback routing appears early. But there is notable redundancy ('valuation valuation'), and the long sibling enumeration consumes space without resolving the core ambiguity of when to use this versus the many startup-industry siblings.

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

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

For a single-argument wrapper with a full-ish schema and an output schema present, the description covers the essential operational facts (read-only, deterministic, no auth, error envelope, argument forwarding). What it omits is the substantive differentiator: what specific valuation case this covers and how to choose it over the overlapping startup/advanced/industry siblings, which is the main thing an agent needs.

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 there is only one parameter, so the schema already documents 'arguments' fully. The description adds only the pointer that supported fields come from the forwarded tool's schema and that unsupported fields error out, which is helpful but not richer than the structured data. 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 description says it is a 'startup valuation valuation capability' and covers 'corporate, startup, and intangible valuation', which is vague and partly tautological relative to the name. It never specifies what this endpoint actually computes (e.g., 409A, preferred allocation, or conversion) beyond a generic label, and the key routing signal is only 'the case that native tools do not handle', which does not distinguish it from the many startup/industry siblings such as valuation_saas, valuation_fintech, or valuation_advanced.

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 does give some routing guidance: 'Use it only for the startup valuation case that the native tools do not handle' and lists several alternatives to prefer. However, with 34 siblings including multiple overlap candidates (valuation_advanced, valuation_saas, valuation_fintech, valuation_technology), it offers no concrete condition distinguishing this fallback from those, leaving the choice largely to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely useful behavioral context beyond that: deterministic computation with no external calls, no authentication required, and specifically that unsupported fields return an error envelope rather than raising. The only gap is that it doesn't describe the shape of the shared result envelope, but that is covered by the output schema.

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

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

The guidance is reasonably front-loaded and free of padding, but the opening clause "a intangible valuation valuation capability" is malformed and repetitive, and the sentence about the arguments object is somewhat circular. It is adequate but not tightly written.

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 thin proxy wrapper with annotations, an output schema, and a fully documented single parameter, the description covers the essentials: safety profile, no-auth, error behavior, and return envelope. What is missing is any concrete statement of what an IP valuation does or when it is the correct choice, which matters given ~34 valuation siblings.

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

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

There is a single parameter with 100% schema description coverage, so the baseline is 3. The description confirms the argument is forwarded to the underlying tool and that unsupported fields produce an error, which adds a little operational meaning, but it provides no field-level detail beyond pointing at an external schema the agent cannot see here.

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

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

The description labels this an "intangible valuation capability" and calls out corporate/startup/intangible coverage, but it never specifies what IP valuation actually computes (patents, trademarks, royalty relief, etc.). The phrasing "intangible valuation 'valuation_ip' case" largely restates the name, so the agent learns the domain but not the concrete operation, and differentiation from siblings like valuation_royalty_analysis is thin.

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 names the native alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) and says to prefer them when they apply, which is real routing guidance. However, the core directive "use it only for the 'valuation_ip' case" is circular and never defines what that case is, so the agent still cannot tell when this tool genuinely applies versus valuation_royalty_analysis or valuation_technology.

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, non-destructive, and closed-world. The description adds genuinely useful context beyond them: no external calls, no authentication required, deterministic computation, and that unsupported fields return an error envelope rather than raising an exception.

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 operational constraints (read-only, no auth, error envelope) are front-loaded, but the opening clause repeats 'valuation' twice and the routing sentence is longer than necessary. Some redundancy dilutes an otherwise compact 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?

An output schema exists, so return values need not be explained, and the description still notes the shared result envelope. Together with the behavioral and routing notes, an agent has enough to invoke it correctly, though the awkward capability framing leaves the exact computation slightly ambiguous.

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

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

Schema description coverage is 100% for the single 'arguments' parameter, so baseline is 3. The description adds only the note that unsupported fields yield an error envelope, but gives no field-level detail on what the forwarded schema accepts.

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

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

The description names the capability ('intangible valuation', 'market approach') and distinguishes itself from siblings by listing the native tools it should not replace. However, the framing 'a intangible valuation valuation capability' is repetitive and near-tautological, and no concrete verb describes what computation is actually performed.

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 gives explicit routing guidance: use only for the 'valuation_market_approach' case the native tools do not handle, and prefer valuation_dcf, valuation_nav, valuation_cca, etc. whenever applicable. The instruction is somewhat circular (use this tool for the case this tool handles), but alternatives are named concretely.

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?

Adds meaningful behavior beyond the annotations: deterministic computation, no external calls, no authentication required, and the non-raising error envelope for unsupported fields. Annotations already cover read-only/idempotent/non-destructive, so this is solid supplementary context rather than the full 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?

Front-loaded with name and capability, but the first sentence is redundant and awkward ('a startup valuation valuation capability ... one endpoint covers corporate, startup, and intangible valuation'), and the routing guidance is buried after it. Some sentences do not fully earn their place.

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

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

An output schema exists, so return-value detail is unnecessary, and the description still notes it returns the shared result envelope. Combined with rich annotations and 100% schema coverage, an agent has enough to invoke it correctly, though the actual computation semantics remain underspecified.

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

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

Schema description coverage is 100% and the single 'arguments' parameter is already documented as forwarded to the underlying tool's schema. The description repeats that ('Pass an arguments object matching that tool's schema') without adding syntax, field lists, or examples, so baseline 3 applies.

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

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

The description identifies the resource (startup valuation) and positions the tool as the catch-all endpoint for corporate/startup/intangible valuation, but the phrasing is circular ('a startup valuation valuation capability') and never states what it actually computes or returns. An agent knows roughly what domain it belongs to, but not the specific operation beyond 'startup 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?

Explicit routing guidance: 'Use it only for the startup valuation case that the native tools do not handle; prefer the native tool (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, or black_scholes_price) whenever it applies.' Names both the when-to-use condition and the specific alternative 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 the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds the computation logic (gross holdings less liabilities), but does not disclose auth needs, data-freshness, or handling of missing holdings inputs. Adequate but not rich beyond structured data.

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

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

Three tight sentences with the purpose front-loaded, followed by selection guidance and return value. Every sentence earns its place with no 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?

With an output schema present, return-value explanation is optional (and lightly provided). The description covers purpose, selection criteria, and method, so nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the holdings item shape and types. The description adds no parameter-level syntax or defaults beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb ('Value') and resource ('asset-heavy or holding company') plus the method (sum of listed and unlisted holdings less liabilities). It clearly distinguishes itself from cash-flow siblings like valuation_dcf.

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 gives the selection condition ('when value is asset-based rather than cash-flow-based') and names the alternative for the opposite case ('for cash-flow businesses use valuation_dcf'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond that: deterministic computation, no external calls, no auth required, and error-envelope behavior for unsupported fields instead of raising.

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 paragraph with the routing rule front-loaded after the identity clause; nearly every clause carries information. Minor redundancy ('startup valuation' repeated, awkward double 'valuation valuation') costs it a point.

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

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

An output schema exists, so return values need not be explained, and sibling differentiation is strong. However, the core payload — which fields 'arguments' accepts — is deferred to an unexposed schema, leaving an agent unable to construct a valid call without the native tool's definition.

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% for the single 'arguments' parameter, so baseline is 3. The description reinforces that arguments must match the referenced tool's schema and that unsupported fields return an error, but since that referenced schema is not exposed, it cannot tell the agent which fields are valid.

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

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

The description names the tool and frames it as a startup valuation capability, but it never states what 'valuaton_probability' actually computes (e.g. probability-weighted/scenario valuation). It is largely a restatement of the name plus routing context, so the agent learns scope but not the specific computation.

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 states when to use it ('only for the startup valuation valuation_probability case that the native tools do not handle') and names six concrete alternative tools to prefer. This is a textbook when/when-not/alternatives statement.

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, non-destructive, and closed-world, so safety is covered. The description adds value beyond that by stating it is deterministic with 'no external calls and no authentication required' and by disclosing error behavior: 'unsupported fields return an error envelope rather than raising.' That error-handling contract is not present in the structured fields.

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 name/identifier is front-loaded, but the text is padded with redundancy ('intangible valuation valuation capability') and repeats the tool name twice. The useful routing and error-handling sentences are buried behind boilerplate, so every sentence does not fully earn 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?

An output schema exists so return values need not be explained, and annotations carry the safety profile. Given the wrapper/proxy complexity, the description supplies the needed routing, read-only determinism, and error-envelope behavior, making it largely complete for calling the tool correctly; only the actual domain semantics of the royalty method remain unstated.

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

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

Schema coverage is 100% and the single 'arguments' property is already documented as a passthrough to the target tool's schema. The description largely restates this ('Pass an arguments object matching that tool's schema'), adding only the unsupported-field error behavior. With the schema doing the heavy lifting, 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 description names the resource ('royalty analysis' within intangible valuation) and states it is exposed so 'one endpoint covers corporate, startup, and intangible valuation,' but the core phrasing 'a intangible valuation valuation capability' is repetitive and tautological, and it never explains what a royalty analysis actually computes. It does distinguish itself from siblings by naming them, which lifts it above a pure restatement.

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 gives explicit routing: 'Use it only for the intangible valuation case that the native tools do not handle; prefer the native tool (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, or black_scholes_price) whenever it applies.' That is a clear when-to-use and alternatives statement. It stops short of a 5 because the fallback condition is somewhat circular ('the case the native tools do not handle') rather than describing what a royalty analysis specifically covers.

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 annotations it adds that the computation is deterministic, makes no external calls, requires no authentication, and — most usefully — that unsupported fields return an error envelope rather than raising. The error-handling behavior is exactly the kind of trait 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?

Front-loads the name and scope, then sequences routing, safety, and error behavior efficiently. Slightly repetitive phrasing ('startup valuation valuation capability') and heavy em-dash use cost it a point.

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

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

An output schema exists, so return values need not be detailed, and the description correctly points at the shared envelope. The one gap is that the referenced target tool schema is external and unavailable, leaving the agent without the actual supported fields.

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

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

Schema coverage is 100% and there is a single pass-through 'arguments' object, so the baseline is 3. The description only says to match 'that tool's schema', which is not provided here, so it adds little syntax or meaning beyond the schema itself.

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?

It states a specific resource (startup valuation) and frames itself as a fallback endpoint, naming the native tools it stands apart from. It loses a point because the opening clause is muddled — it claims to cover 'corporate, startup, and intangible valuation' while the next sentence restricts it to the startup case only.

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?

Explicit routing guidance: use only for the startup valuation case native tools do not handle, and prefer the six named native tools whenever they apply. The condition that selects this tool and the alternatives are both spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, but the description adds real operational context: no external calls, no authentication needed, deterministic computation, unsupported fields return an error envelope rather than raising, and it returns the shared result envelope. These error-handling and auth details go beyond the structured fields. It does not explain why unsupported fields occur given the permissive anyOf schema, which keeps it from a 5.

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

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

Purpose and routing are reasonably front-loaded, but the prose is cluttered: 'a intangible valuation valuation capability' is awkward and redundant, and the 'intangible valuation valuation_simulation case' phrasing restates the name. Several sentences could be tightened without losing 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?

An output schema and full annotations exist, so return values and safety profile need not be re-explained. The core gap is that an agent must go read the underlying tool's schema to learn what fields 'arguments' accepts, and the description never says which underlying tool that is. For a generic dispatcher wrapper this is adequate but leaves the main invocation question unanswered.

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 there is a single optional 'arguments' property, so the schema already documents the parameter. The description adds that arguments must match the target tool's schema and that unsupported fields error out, which is mildly useful, but it does not enumerate any supported fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description identifies the resource as an 'intangible valuation' capability and frames itself as the catch-all endpoint for cases the native tools do not handle. However, it never states what the simulation actually computes or how it differs semantically from the many sibling valuation_* tools, and 'intangible valuation valuation capability' is close to circular. It distinguishes itself from siblings only as a fallback, not by describing distinct behavior.

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?

Explicit routing guidance: 'Use it only for the intangible valuation case that the native tools do not handle; prefer the native tool ... whenever it applies.' This gives a clear when-to-use and a when-not-to-use with named alternatives. It falls short of 5 because it names only 6 siblings while the tool list contains ~35, so the agent cannot tell whether an unnamed sibling (e.g. valuation_ip, valuation_advanced, valuation_comparables) counts as 'native' and should be preferred.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds context the annotations do not: deterministic computation, no external calls, no auth required, and error-envelope behavior for unsupported fields instead of exceptions. That is genuine added value beyond the structured 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?

The content is front-loaded well, but the opening 'Valuation Stakeholder (valuation_stakeholder) — a startup valuation valuation capability' is redundant restatement of name and title and contains an awkward duplication. The rest earns its place, so this is adequate rather than tight.

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

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

An output schema exists, so return-value detail is not required, and the description does note the shared result envelope. For a single-parameter passthrough tool, the routing guidance plus behavioral notes are close to complete; only the undefined nature of 'stakeholder valuation' leaves a 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 100% and there is a single optional 'arguments' passthrough object, so the baseline is 3. The description restates that arguments must match the target tool's schema and that unsupported fields error out, but adds no field-level meaning beyond the schema.

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

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

The description identifies the tool as a 'startup valuation capability' and names it against a large sibling family, which is useful for routing. However, what a 'valuation_stakeholder' computation actually does is never explained — the term is circularly repeated rather than defined, leaving the agent unsure what business result this produces.

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 gives explicit routing guidance: use this only for the startup valuation case, and prefer named native alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) whenever they apply. The trigger for this tool is still defined circularly ('the valuation_stakeholder case'), so exclusion logic is stronger than inclusion logic.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: deterministic computation, no external calls, no authentication required, and unsupported fields yielding an error envelope rather than an exception. The error-handling behavior is the most valuable disclosure.

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 routing rule is reasonably front-loaded, but the text is padded with awkward repetition ('intangible valuation valuation capability', 'the intangible valuation valuation_technology case') and the long parenthetical tool list. Sentences are longer than they need to be, and the self-referential naming wastes space.

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 an output schema present, return values need no explanation, and the description covers behavior, auth, error handling, and fallback routing. Given a one-parameter pass-through wrapper, this is nearly sufficient; only concrete guidance on what technology valuation computes (vs. valuation_ip or valuation_saas) 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?

The single 'arguments' parameter is already 100% described in the schema, setting a baseline of 3. The description essentially restates the schema ('pass an arguments object matching that tool's schema') and only adds the unsupported-field error behavior. No field names, formats, or argument examples are provided to compensate further.

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

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

The description identifies a specific resource (intangible/technology valuation) and frames it as a fallback, but the phrasing 'a intangible valuation valuation capability' and 'the intangible valuation valuation_technology case' is circular and awkward. It is distinguishable from the named native siblings, but it never clearly states what technology valuation actually computes. Purpose is implied rather than stated cleanly.

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

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

It gives an explicit routing rule: use only for the case native tools do not handle, and prefer valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, or black_scholes_price whenever they apply. The named alternatives are concrete, though the selecting condition ('the case the native tools do not handle') stays abstract since no examples are given.

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 annotations (readOnlyHint, idempotentHint, openWorldHint=false, destructiveHint=false), it adds useful behavioral context: deterministic computation, no external calls, no authentication required, and that unsupported fields return an error envelope instead of raising. That error-handling disclosure is genuinely non-derivable from the structured fields.

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 routing rule and safety facts are front-loaded and the text is compact for the amount it covers. There is minor redundancy ('intangible valuation valuation capability') and slightly awkward phrasing, but no wasted padding.

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

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

An output schema exists, so return values need not be described, and the annotations cover the safety profile; the description still supplies routing, auth, determinism, and error behavior. The remaining gap is that it points the agent at 'that tool's schema' for the arguments object without exposing those fields, which is a real limitation for a proxy-style 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?

There is only one parameter and schema coverage is 100%, so the schema itself already documents it, which sets the baseline at 3. The description adds the meaningful detail that harmless extra fields produce an error envelope rather than an exception, but gives no insight into the forwarded sub-schema's supported fields.

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 labels this an 'intangible valuation valuation capability' for the 'valuation_time_value' case, essentially restating the name without explaining what a time-value valuation actually computes. It never distinguishes the resource from sibling valuation tools on domain grounds; the only differentiation offered is a routing preference, not a statement of 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?

It explicitly states when to use this tool ('only for the intangible valuation valuation_time_value case that the native tools do not handle') and names the alternatives (valuation_dcf, valuation_nav, valuation_cca, calculate_wacc, calculate_ecl, black_scholes_price) with a clear 'prefer native' rule. The selection condition is somewhat circular since the reader cannot tell what the fallback case actually covers, keeping it below a 5.

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