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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial behavioral detail beyond them: the 10×10 cap, the 422 failure mode, consolidated-only values, one value per (entity, hub, year), fiscal-year alignment, and the caveat that non-December filers may see different values here than from get_fact. These are exactly the operational traits an agent needs before invoking the 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?

The description is front-loaded with the core purpose, then moves efficiently through limits, tool preference, return shape, and the fiscal-year nuance. Every sentence adds useful information, and the line breaks make it easy to scan.

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

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

Given the existence of an output schema, the description need not explain return values, yet it still summarizes the return shape (one row per entity plus a cells map) and the key fiscal-year caveat. Combined with the cap and failure-mode disclosure, it provides enough context for correct invocation in this complex comparison tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It adds useful semantics for the key parameters: entity_ids and hub_concept_codes are bounded by the N=10/M=10 limits, fiscal_year is tied to fiscal-period alignment and FY forcing, and hub_concept_code keys the output cells. It still does not explicitly describe the expected string format of entity_ids or hub_concept_codes, and fiscal_period_type is only implied via 'FY forced,' but the core meaning is well beyond what the bare schema provides.

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

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

The description opens with a specific verb and resource: 'Build a comparison matrix for N entities × M concepts at one period.' It distinguishes itself from sibling get_fact by name and explicitly states the preferred use case, so an agent can tell exactly what it does and when it is the right 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?

It gives an explicit selection rule: 'ALWAYS prefer this over N×get_fact when comparing more than one company.' It also discloses the operational cap (N=10, M=10) and the failure mode (422 validation error), which is direct guidance for avoiding misuse.

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 the read-only, idempotent, closed-world, non-destructive profile, so the description's added value is the semantic flag vocabulary it returns (`is_new_in_b`, `is_removed_in_b`, `is_sign_flip`, `has_restatement_warning`) and the restatement semantics itself, which is non-obvious behavior. It does not cover failure modes (mismatched fiscal year ends, missing prior filing), keeping it 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 one-line purpose, then trigger examples, then return semantics, then parameter overrides, then sibling disambiguation — a sensible order. Slightly long, and the inline backtick code spans make it dense, but every block 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 shape needn't be explained, and annotations carry the safety profile. What remains uncovered is the directionality convention of year A vs year B and the `fiscal_period_type` parameter, both of which an agent could get wrong on a 6-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the param burden. It handles `hub_concept_codes` well (optional, None = default hub set, explicit override up to 50) and `form_type` well (enumeration of accepted forms and the omit-for-most-recent-original default), but `entity_id`, `fiscal_year_a`/`fiscal_year_b` ordering convention, and the `fiscal_period_type` default of 'FY' are undocumented in both schema and description.

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

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

States a specific verb and resource ('Compare two annual filings') and narrows scope explicitly with 'of the SAME entity side-by-side,' which immediately separates it from the cross-entity sibling. The capitalized SAME is a deliberate disambiguator.

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 literal trigger phrasings ('what changed at X between FY{n-1} and FY{n}', 'year-over-year breakdown') plus an explicit exclusion block naming three siblings (compare_entities, get_amendment_diff, get_metric_history) with the condition that selects each. 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?

Adds real behavior beyond the annotations: unsupported currency yields an error result, cross-rates route through EUR, and 'date' resolves to the latest ECB fixing on or before the requested date. Annotations already cover read-only/idempotent safety, so this is additive. The stray 'fix_date echoes the requested date' sentence is unexplained noise that muddies an otherwise clean 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?

Front-loaded with a one-line purpose, then indented bullets that map cleanly to rate_type semantics and edge cases. Slightly long, and the dangling fix_date clause is a sentence that does not 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 the description still covers edge cases (unsupported code, from == to, cross-rates, fixing fallback). The one gap is that fix_date is referenced as if it were a parameter or output field without clarifying which, leaving a small ambiguity.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does: the three rate_type values are defined with distinct averaging windows (spot, rolling 365 days, prior calendar year), date format and default are given, and the pair semantics include identity short-circuit and EUR cross-rating. Only the trivially obvious 'amount' is left implicit.

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

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

States a specific verb and resource ('Convert an amount between two ISO 4217 currencies using ECB reference rates') and pins the rate source. No sibling tool in the list performs currency conversion, so there is no ambiguity to resolve, and the method (ECB) is named up front.

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 both concrete triggering phrases ('convert X in Y', 'Microsoft revenue in EUR') and the semantic rule for choosing a rate_type (closing for balance-sheet items per IAS 21, average_ytd for P&L/cash flow). Since no sibling offers conversion, no alternative needs to be excluded.

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, closed-world, so safety is covered. The description adds genuinely new behavior: the result cap (up to 5 matches) and the ranking rule (by exactness), which tells the agent how to interpret truncated or ordered results.

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, no filler. The identifier formats and result cap are front-loaded before the usage directive, so the agent gets the essential facts first.

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. For a one-parameter lookup tool, the description supplies everything needed: what to pass, when to call it, and what comes back.

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 0% for the single 'query' parameter, but the description compensates by enumerating accepted input forms and giving a concrete example ('CSCO'). It stops short of stating whether matching is exact or fuzzy beyond the ranking note.

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 (Search) and resource (Hub-Equity entities) plus the three accepted identifier forms (name, ticker, CIK). This clearly separates it from siblings like get_entity_profile, which consumes an entity_id rather than resolving one.

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 first when the user mentions a company by name or ticker" gives an explicit trigger, and "you need the entity_id to call any other tool" states the prerequisite that routes the agent here before the other 20 sibling tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds real behavioral context beyond that: the output fields, the sort order (|diff_pct| desc), and the default materiality filter. It stops short of noting pagination or result-size 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?

Front-loaded with the core definition, then differentiation, then examples — a clean structure with no filler. Slightly dense but 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?

With an output schema present, return values needn't be detailed. The description covers purpose, sibling differentiation, filters, and use cases; only the unexplained entity_id/fiscal_year semantics leave a minor gap.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains min_diff_pct (default 1%) and maps hub_concept_code and kind, but leaves entity_id and fiscal_year unexplained beyond an inferable 'FY24' example. Partial compensation only.

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

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

States a specific verb+resource with the exact output shape (old_value, new_value, diff_pct, kind) and scope (all 10-K/A amendments of an entity). It explicitly distinguishes itself from the sibling get_amendments, so an agent can route without opening either 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 contrasts with get_amendments ('which returns counts per amendment') and states when to use it via three concrete example queries (specific FY change, all REVENUE restatements, material corrections only). Both when-to-use and the alternative are covered.

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 behavior, so the safety profile is fully covered. The description adds only 'per-concept diffs when available,' a useful but thin note about return content, and says nothing about auth, limits, or data freshness. The output schema carries the return contract, so 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?

The core statement is front-loaded in the first sentence, followed by three short trigger examples. Slightly verbose with the repeated question-form quotes, but every line is scannable and none is wasted.

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

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

With an output schema present and annotations covering safety, most of the calling contract is complete. The remaining gap is routing: in a 22-tool sibling set dominated by amendment/restatement tools, the description never positions this tool relative to get_amendment_diff or get_silent_restatements.

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

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

Schema description coverage is 0%, so the description must carry the load. 'For an entity' maps to the required entity_id and 'FY20xx 10-K/A' hints at the optional fiscal_year filter, but neither format nor the behavior when fiscal_year is omitted (all years vs. latest) is explained, so compensation is only partial.

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

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

States a specific verb and resource: surfacing 10-K/A restatements for an entity, with a parenthetical noting per-concept diffs. However, it does not distinguish itself from close siblings like get_amendment_diff, get_silent_restatements, or get_silent_restatement_diff, leaving the agent to guess which amendment tool to call.

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

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

Concrete trigger phrases ('has X amended any filing?', 'restatements?', 'what changed in the FY20xx 10-K/A?') give clear context for when to reach for this tool. It stops short of exclusions or naming alternatives, so an agent still cannot tell when to prefer get_amendment_diff over this one.

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, so the safety profile is covered. The description still adds real context beyond them: result ordering ('largest first'), the two-call workflow, and the semantic distinction between declared and supported signs. It doesn't mention pagination or limits, keeping it 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 purpose, then workflow, then example queries — no filler sentences. The prose is dense with domain jargon and long clauses, which slightly taxes readability, but every sentence contributes meaning.

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

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

With an output schema present, the description need not explain return fields, yet it clarifies the hardest-to-interpret ones, and it covers invocation order, parameter sourcing, and use cases. 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 description coverage is 0%, so the description must carry parameter meaning, and it does: filing_id's provenance is given precisely, and link_role is explained both as a filter (the statement or note you want) and as a discoverable value via the first no-argument call. Both parameters are covered beyond what the bare schema provides.

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

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

The opening sentence states a specific resource and scope: 'the issuer's own arithmetic in one filing: which concepts add up to which total.' It names the distinguishing artifacts (weight vs corrected_weight, is_corrected, corrected_count), so an agent can separate it from siblings like roll_up_metric or get_fact_decomposition.

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 sequencing ('call it first without link_role... then again with the link_role'), states where to obtain the required filing_id ('from the source of get_fact or from get_entity_profile'), and lists concrete triggering questions. The when-to-use and parameter-flow guidance is fully worked 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 supply readOnly/idempotent/destructive safety, so the description correctly uses its space for deeper semantics: the grade is computed on the latest reported fiscal year, is the worse of two gates, and notably that "a missing grade is not a bad grade" — a genuinely useful interpretive caveat. It also previews the payload (counts, direct vs derived split, GAAP/IFRS presence, freshness), though the output schema already covers return shape.

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

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

The core purpose and the A+/D range are front-loaded, followed by the computation semantics and the missing-grade caveat. It is dense but every clause carries meaning; the trailing enumeration of payload fields is slightly list-like but still informative.

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

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

For a single-parameter read tool with a full output schema, the description covers purpose, computation, interpretation, and payload contents well. The one gap is that it never describes the entity_id parameter, which the schema also leaves undocumented.

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 0% and the sole parameter entity_id is never mentioned or explained in the description. While the name is somewhat self-evident given siblings like find_entity, the description does nothing to compensate for the missing schema documentation, leaving the agent to infer format and source.

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 precise verb+resource (compute/return a data-quality grade for an entity) and defines the output domain (A+ to D, or none). It distinguishes itself from siblings like get_validation_results by framing the grade around completeness and the two gates it uses, so an agent can tell it apart without opening other schemas.

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

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

"Use when the user asks how reliable a company's data is" gives a clear triggering context. It stops short of naming alternatives (e.g., get_validation_results) or stating when-not to use it, so it is strong but not fully explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds the content scope of the response, but that largely duplicates the output schema, and it says nothing about cost, latency, or freshness of the snapshot.

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 payload summary, then the routing guidance, in two tight sentences. No filler and no repetition of annotation or schema content.

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

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

With an output schema present, return values need not be re-explained, and usage guidance is strong. The remaining gap is the undocumented entity_id contract, which is the only input an agent must supply and is not clarified anywhere.

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 required parameter (entity_id) with 0% schema description coverage, so the description carries the burden. It only indirectly implies the ID source by saying to call this after find_entity; it never states the expected format or origin of entity_id explicitly.

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 ('company snapshot') and enumerates the exact payload (identifiers, sector, auditor, employees, legal form, fiscal year end, recent filings summary). This clearly separates it from siblings like find_entity (search) and get_fact (single metric).

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 concrete sequencing ('Use after find_entity') plus trigger phrases for direct invocation, including a French variant. It names one alternative, but does not state when NOT to use it (e.g. for a single datapoint, use get_fact), so it stops short of full when/when-not coverage.

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), so the bar is lower. The description adds real behavioral detail beyond them: a hard cap of 100 results, sort order by usage_count desc, and the semantics of the status_filter values. It does not mention pagination/truncation behavior when the cap is hit.

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 front-loaded with the core purpose and keeps parameter semantics compact. The return-field enumeration ('qname, label, item type, ...') is somewhat redundant given an output schema exists, which is minor 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?

With an output schema present, the description need not explain return values, yet it still does, and it covers the limit cap, sort order, and filter semantics that the schema omits. It is complete enough to invoke correctly; only pagination/truncation edge behavior is 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 0%, so the description must carry the load, and it largely does: it defines the `limit` cap (100) and enumerates `status_filter` values {all, mapped} with the meaning of `mapped` (extensions read into a standardised hub). Only `entity_id` is left unexplained, which is near-self-evident from the name.

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 resource ('issuer-specific qnames declared outside standard taxonomies') and scopes it against the standard taxonomies (us-gaap / ifrs-full), which cleanly separates it from siblings like search_concept or get_fact. An agent can tell what it returns and why it exists without opening the 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?

It gives a concrete invocation cue ('Use for "what custom concepts has Apple declared?"'), which is strong positive guidance. It does not explicitly state when NOT to use it or name the alternative tool for standard concepts, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, but the description adds real behavior: non-FY periods are refused with an error, and missing combinations return an error result rather than null. It stops short of noting pagination/units or the exact error shape.

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 purpose followed by parameter notes and an error caveat; every sentence carries information. Slightly paragraph-heavy for what could be tighter bullets, but no filler.

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

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

An output schema exists, so return-format detail is unnecessary, and annotations cover the safety profile. Combined with the error/refusal guidance, the agent has enough to invoke it correctly; only entity_id/fiscal_year semantics and value units are unaddressed.

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 0%, so the description must compensate and largely does: hub_concept_code is explained as a standardized code with concrete examples, and fiscal_period_type carries default and constraint ('defaults to FY; annual only, others refused'). entity_id and fiscal_year are left implicit, but their meaning is self-evident.

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

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

States a specific verb+resource+scope: 'Get a normalized financial value for an entity at a given period.' The concept-code dimension and period semantics make it identifiable apart from siblings like get_metric_history or get_fact_decomposition without opening a schema.

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

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

Explicitly routes the agent: 'Use search_concept first if you don't know the code.' It also encodes a when-not rule for the period parameter (non-annual types are refused) and an anti-pattern ('never fill the gap with an estimate').

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?

Goes well beyond the annotations, which only cover safety (readOnly/idempotent/non-destructive). It discloses entitlement behavior (two of three layers are paid-plan gated and return 'empty... with a note' below it), a hard recursion cap ('depth max 3'), and the round-trip tradeoff that motivates depth=2 — all operationally valuable and not derivable from 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-loads the one-line purpose, then uses a numbered list for the three layers and a closing line for depth/plan guidance — a clean structure that earns its length. Slightly verbose in places, but each clause carries information.

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

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

An output schema exists so return shapes needn't be restated, yet the description helpfully sketches the three layers and their gating. The remaining gap is the unexplained identity/period parameters, which an agent must guess at for a required-parameter operation.

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

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

Schema description coverage is 0%, so the description bears the full burden and it clearly explains the hub_concept_code/qname tradeoff and depth semantics, including a worked qname example. But entity_id, fiscal_year, and fiscal_period_type receive no explanation at all, so half the parameters remain undocumented in both places.

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 ('decompose') and resource ('financial fact') followed by a concrete overview of the three output layers. However, it never distinguishes itself from the sibling `get_calculation_tree`, which also surfaces XBRL calc linkbase structure, so an agent must infer which one to reach for.

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 explicit parameter-selection guidance ('Pass EITHER hub_concept_code (preferred) OR qname') and depth guidance tied to plan tier, which is useful context. But it never says when to prefer this tool over alternatives like get_calculation_tree, get_fact, or roll_up_metric, leaving the routing decision implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context the annotations lack: annual granularity only, and that YoY is null across a missing year—a non-obvious edge case.

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, front-loaded with the core capability followed by routing examples. No filler.

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

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

An output schema exists, so return structure needn't be described; the description still covers the notable return behaviors (annual only, null YoY, CAGR). Only the meaning of the required identifier parameters is left unaddressed.

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 0%, so the description must carry the parameter burden. It only loosely maps to n_years ('N-year') and gestures at fiscal_period_type ('annual values only'), while entity_id and hub_concept_code—both required—are entirely unexplained.

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

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

States a specific verb+resource+scope: 'N-year time series for one metric (annual values only)' and names the derived values (YoY growth, CAGR). An agent can distinguish it from get_fact, roll_up_metric, and compare_entities without opening a schema.

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

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

Explicitly routes trend/growth questions with three concrete example queries. However, it never names an alternative sibling (e.g., get_fact for a single period) or states when NOT to use 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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds real behavior beyond them: an edge case ('Returns empty `axes` when the issuer reported only the consolidated total') and a gating rule ('members of each axis need a paid plan... below it the axes are listed without them, with a note'). That is substantive, non-obvious disclosure; only error/pagination behavior is left out.

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 core purpose on line one, followed by usage examples, then edge cases and the plan caveat. Every sentence carries information; formatting with line breaks aids scanning. Slightly fragmentary prose but no filler.

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

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

An output schema exists, so return-shape explanation is not owed here, and the plan/empty-axes notes cover the two most surprising runtime behaviors. However, with four parameters at zero schema coverage and no explanation of how hub_concept_code is obtained, an agent has enough to understand the tool's role but not enough to invoke it confidently without consulting another 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?

All four parameters (entity_id, hub_concept_code, fiscal_year, fiscal_period_type) have 0% schema description coverage, and the description supplies no per-parameter meaning, format, or valid values — 'hub_concept_code' in particular is opaque without a reference to search_concept/list_hubs. Only a loose hint about 'the given period' and 'a metric' gestures at two of the four.

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: 'Dimensional breakdown of a metric (axis/member from XBRL dimensions)' plus 'Reads the dimensional (segment) values for the given period.' An agent can tell this is the segment/axis dimension reader rather than a plain fact lookup. It stops short of naming the closest siblings (get_fact, get_fact_decomposition, roll_up_metric), so the boundary is inferable rather than explicit.

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

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

Gives concrete trigger phrases — 'revenue par région', 'profit by segment', 'split by product/geography' — that map directly to user intent. It does not state when NOT to use it or name an alternative tool for non-dimensional facts, which the sibling set (get_fact, get_fact_decomposition) clearly contains.

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), so the bar is lower. The description adds real context beyond them: the |diff_pct| descending sort, the meaning of 'silent' (no amendment filed), and the default materiality threshold, though return format is left to 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 field list (old_value, new_value, diff_abs, diff_pct, kind, label...) duplicates what the output schema already provides, and the get_amendment_diff sentence is grammatically tangled. The purpose is not front-loaded, and the trigger examples sit at the very end.

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 5-parameter financial tool with an output schema present, the description covers the key filters, the materiality default, sort order, and how it relates to get_amendment_diff. Remaining gaps (entity_id/fiscal_year semantics) are modest given the output schema carries return values.

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 0%, so the description must compensate, and it partially does: it explains min_diff_pct ('a fraction, default 1%'), names hub_concept_code, and supplies enum-like values for kind ('modified', or 'added' for a newly disclosed figure). However entity_id and fiscal_year get no explanation, leaving half the surface undocumented.

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

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

Names the specific resource ('per-concept silent restatements') and distinguishes it from the sibling get_amendment_diff by the defining trait 'with no amendment filed'. The purpose is inferable, though the opening leads with output fields rather than the action, and the contrast sentence is awkwardly worded ('get_amendment_diff on the other source').

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 concrete use queries ('all silent REVENUE restatements of X', 'material quiet revisions only', 'which filing revised FY2023 and by how much?') and names an alternative tool (get_amendment_diff). It lacks an explicit when-not condition, but the examples make the intended trigger context 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 cover read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds useful semantic context: results are grouped by the revealing filing, no amendment is involved, and diff_pct is expressed in percent. It stops short of describing return-shape nuances or edge cases, but an 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 front-loaded with the core behavior, then adds the key exclusion and field semantics, then closes with compact use cases. Every sentence contributes context and none is redundant.

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 annotations, an output schema, and only two parameters, the description covers the essential behavior and scope. The remaining gap is minor: entity_id and fiscal_year optionality are left to the schema rather than explained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains fiscal_year as the year of the restated figure and mentions diff_pct, but it does not explain entity_id or clarify that fiscal_year is optional. Partial compensation for a two-parameter tool warrants a mid score.

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 operation: finding later-filed comparative figures reprinted without an amendment, grouped by revealing filing. It explicitly distinguishes itself from get_amendments by saying these are the restatements get_amendments cannot see.

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 use cases ('did X quietly change its past numbers?', 'restatements without an amendment') and names the relevant alternative, get_amendments, along with the condition that differentiates them. The when-to-use context is clear enough for an agent to route correctly.

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 read-only/idempotent/non-destructive safety profile, and the description adds genuinely new behavior: the default filter hides valid/skipped rows, an 'error' is an unreconciled check rather than a finding that the issuer is wrong, and results are sorted by severity then |relative_difference| and capped at 100 rows.

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 check-type taxonomy is stated twice in near-identical prose (the check-type paragraph and the validation_type enumeration), duplicating definitions of accounting_equation and calculation. The content is useful but the repetition costs efficiency.

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 explained, yet the description usefully adds ordering and row-cap semantics, usage triggers, and parameter guidance. Only fiscal_year's meaning is left uncovered.

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 0%, so the description carries the burden and largely does: it enumerates validation_type values, explains status_filter defaults and accepted values, and states the filing_id/entity_id requirement. fiscal_year is left undocumented, so it is not quite complete.

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 first sentence states a specific verb and resource ('surface the checks Hub-Equity ran on the numbers of a filing'), and the enumerated check types let an agent distinguish it from siblings like get_data_quality_grade and get_calculation_tree.

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 trigger questions ('did the balance sheet balance?') and a hard prerequisite ('provide at least one of filing_id or entity_id'), plus the default status_filter behavior. It does not name a sibling alternative for when validation results are the wrong tool, so it falls short of the 5 bar.

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 the safety profile is fully covered. The description adds behavioral context only in the form of parameter domain limits (max 200, default 80) and the efficiency rationale; it says nothing extra about pagination, ordering, or result shape beyond what the output schema presumably covers. Adequate but not rich.

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

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

Front-loads the purpose, then the usage rationale, then a compact Args block; nothing is wasted. Minor redundancy in restating the default of 80 that already appears in the schema keeps it from a 5.

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

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

For a zero-required-parameter list tool with an output schema already defining the return shape, the description covers purpose, routing, and every parameter's semantics and constraints. Nothing an agent needs in order to call 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 coverage is 0% and no enums are declared in the schema, yet the description supplies the full allowed value set for category (income_statement, balance_sheet, cash_flow, ratio, equity_info, metadata), the meaning of include_non_primary (derived/secondary hubs), and the limit cap of 200 with default 80. This is exactly the compensation required for an undocumented 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 (List) and a specific resource (the catalog of standardized Hub-Equity hubs), and immediately contrasts itself with the sibling search_concept by framing the tool as a bulk-enumeration alternative. An agent can tell it apart from search_concept without opening either 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?

Gives a concrete usage scenario ('enumerate available metrics for a category, e.g. all balance-sheet hubs') and names the alternative it replaces (N search_concept calls), which is exactly the routing decision an agent needs. It lacks an explicit when-not condition (e.g. when a single known metric is wanted), so it falls 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 establish that this is a read-only, idempotent, non-destructive, closed-world computation, so the safety profile is covered. The description adds genuinely non-obvious behavior: below a paid plan the response omits `algorithm` and `contributions`, which changes how an agent should interpret results.

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, front-loaded with the action and the trigger, closing with the plan-gating caveat. Every sentence adds information with no restatement of the name or 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-value explanation is not required, and the description usefully flags the tier-gated omissions from that output. However, for a domain-specific aggregation tool with zero schema description coverage, the inputs an agent must supply are entirely unexplained, leaving a real gap.

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

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

Schema description coverage is 0% for four parameters (entity_id, hub_concept_code, fiscal_year, fiscal_period_type with its FY default), and the description explains none of them. The only identifiers it mentions, `algorithm` and `contributions`, are output fields, not inputs, so it does not compensate for the schema gap.

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

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

States a specific action on a specific resource: rebuild a reported figure from its components when the figure is untagged. It also names the sibling it substitutes for (get_fact), so an agent can separate the two without opening schemas.

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

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

Gives an explicit routing rule: 'Use when get_fact finds nothing for an aggregate.' The alternative tool and the condition that selects this one are both named, 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral detail beyond them: entities whose currency lacks a current ECB rate are silently excluded from revenue filters, and revenue_year selects on latest reported revenue year rather than fiscal year N for all entities. Return shape is left to 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?

Purpose and the list-vs-single routing are front-loaded, followed by terse backtick-labeled parameter notes. No filler sentences; the length is proportionate to a 13-parameter 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?

The output schema covers return values, and the description handles several tricky filters. But for a 13-parameter, zero-coverage schema it omits the sector/gics_sector distinction, limit/pagination behavior, and bankruptcy_flag semantics, leaving real gaps an agent must guess at.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it compensates well for the parameters it touches (min/max_revenue currency + spot-rate caveat, country as ISO-2, revenue_year semantics, min_quality_grade and sort_by enumerations). However roughly eight of thirteen parameters (limit, sector, gics_sector, auditor_name, min/max_employees, bankruptcy_flag) get no explanation, and the overlapping 'sector' vs 'gics_sector' pair is left ambiguous.

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 ('Filter the Hub-Equity universe') with the criteria domain named. It explicitly distinguishes itself from single-entity siblings with 'Use this when the user wants a LIST of companies matching criteria, not a single company.'

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 plus two concrete example queries and a when-not ('not a single company'). It does not name the specific alternative tool to use for single-entity lookups (e.g. find_entity / get_entity_profile), so routing requires 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 safety (readOnly, idempotent, non-destructive, closed-world), so the bar is low; the description adds the concrete result cap ('Returns up to 10 matches'), which is genuine behavioral context not present in the annotations. It omits matching behavior (prefix vs. fuzzy, case sensitivity), so not a 5.

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

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

Three short sentences, front-loaded with purpose, then behavior, then usage condition. No filler, every sentence carries information.

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

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

An output schema exists so return values need no explanation; the description still covers scope, result limit, and input format. Only minor gaps remain (match semantics, case handling).

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

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

Schema description coverage is 0% for the single `query` parameter, so the description must compensate, and it does: it names both accepted input forms (plain English like 'Costs and Expenses' and bare codes like 'TOTAL_ASSETS'). It could add matching semantics but the format guidance is solid.

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 ('Search Hub-Equity standardized hub concepts by code or label'), so an agent knows exactly what domain is being searched. It does not explicitly distinguish itself from potential siblings like get_extension_concepts or find_entity, so it falls short of 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?

'Use this when you don't know the exact `hub_concept_code`' gives a clear triggering condition for the tool. It implies the alternative path (when you do know the code, look it up directly) without naming the specific sibling tool, so it stops short of a 5.

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