Diavgis — Greek Public Procurement

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

The annotations already declare this as a safe, read-only, idempotent, closed-world operation. The description adds valuable context beyond that: it explains the directional semantics of counterparties and states that results include act counts and EUR totals. It does not discuss pagination, rate limits, or edge cases, but with annotations and an output schema present, the bar is lower.

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 compact and front-loaded: it leads with the core resource and immediately clarifies the directional behavior and returned metrics. Every clause earns its place, with no filler or repetition.

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

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

Given an output schema, full parameter schema coverage, and annotations covering safety and idempotency, the description supplies the key missing nuance: how counterparties differ for buyers versus suppliers and what metrics are returned. It could optionally add a brief usage contrast with sibling tools, but nothing critical for correct invocation 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%, and both parameters are documented there (afm as a 9-digit ΑΦΜ, limit with max 30 and default 10). The description refers to 'an entity (ΑΦΜ)' but adds no syntax, format, or limit details beyond what the schema already provides. Baseline 3 is appropriate 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 clearly identifies the resource (top counterparties of an entity by ΑΦΜ) and specifies the directional logic: suppliers for buyers, public buyers for suppliers. It also mentions the returned metrics (act counts and EUR totals), so the purpose is concrete. It does not explicitly differentiate itself from siblings such as get_entity or spend_by_cpv, which keeps it from 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?

The phrase 'due-diligence view' suggests a use case, and the buyer/supplier distinction implies when the tool is relevant. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among siblings like get_entity or spend_by_cpv. Usage is therefore only 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?

Beyond annotations, it discloses non-obvious behavior: one procurement is counted once via lifecycle-chain deduplication, and every row's expiry_basis explains how the date was derived, with an explicit warning that computed_from_publication is systematically early and is an estimate, not a published date. It also discloses the plan/paywall boundary. That is exactly the kind of context annotations cannot carry.

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 purpose and the key caveat are front-loaded, and the ACCESS clause is clearly delineated in caps. It is on the dense side — the middle sentence about duration being published on award records is a long way to say 'de-duplicated' — but no sentence is superfluous.

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?

Output schema exists, so return values need no explanation, and the description still covers what an agent actually needs: which horizons are free, what expiry_basis means for data trustworthiness, and how rows are de-duplicated. Nothing material is missing 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%, so baseline is 3; the description adds real value on the h parameter by tying horizon values to expansion ('expiring today') and to the paywall, plus the warning that any horizon above 0 is a paid feature. cpv and region are left entirely to the schema, so it isn't a full 5.

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-plus-resource with scope: Greek public contracts running now that expire within a 0/7/30/180-day horizon, framed as a 'renewal pipeline'. It also gives the distinguishing content (incumbent holder, award procedure, bid count), which separates it from generic sibling searches like search_tenders or spend_by_cpv.

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 implies the use case clearly (renewal chasing) and gives concrete plan-based guidance: horizon 0 is free and complete, while 7/30/180 require a paid plan, so an agent knows which horizon values it can actually call. It does not explicitly name sibling alternatives or exclusions (e.g., 'use search_tenders for historical awards'), which keeps 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.

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 behavior: accent- and case-insensitive matching plus a fuzzy 'closest names' return. It doesn't state what happens on zero matches or whether results are ranked by score, which keeps 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?

Three tight clauses: the core action first, the routing condition and alternatives second, the matching/return behavior last. No filler, and the most decision-relevant information is front-loaded.

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

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

For a simple 3-parameter read tool with full schema coverage and an output schema, the description supplies the routing rationale and matching semantics an agent needs to invoke it correctly. Nothing material 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 each parameter (kind enum, name, limit) is documented in the schema. The description reinforces accent/case insensitivity but adds no syntax or semantics for limit or the buyer/supplier/both enum beyond what the schema already says, 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 (resolve a Greek buyer/supplier name to its ΑΦΜ), and explicitly distinguishes itself from get_entity, entity_counterparties and the afm filters which take the 9-digit number. An agent can tell exactly which tool to pick 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?

Gives the explicit trigger ('for when you have a name but no ΑΦΜ') and names the alternative tools and their precondition (they need the 9-digit number). This is the when/when-not/alternatives pattern fully realized.

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/openWorld=false, so safety is covered; the description instead spends its budget on non-obvious data semantics, notably that commitment_ada is a pointer into an external system and deliberately NOT a chain edge, and that discount is official-or-calculated. That is genuine disclosure beyond the structured fields. It stops short of covering behavior for unlinked acts or what happens with an unresolvable id.

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: the retrieval contract is fully stated in the first clause before any field trivia. Sentences are dense but each carries distinct information, and the parenthetical id-format list is compact rather than repetitive.

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 readOnly annotations, a 100%-covered single required param, and an output schema, the description covers the remaining unknowns: id formats, entity resolution, and the two misleading response fields. The only shortfall is that the long commitment_ada/discount exposition duplicates what the output schema already provides, indicating mild misallocation rather than a true information 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?

Only one parameter, and the schema description already spells out 'ΑΔΑ, kimdis:<ΑΔΑΜ> or ted:<number>' at 100% coverage. The description restates those same three forms without adding accepted-syntax detail the schema lacks (no prefix casing rules, no example values). Baseline 3 is appropriate since the schema does the work.

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

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

Opens with a specific verb+resource ('Full detail of one act by its id') and enumerates what comes back: canonical fields, resolved buyer/supplier entities, CPV codes with labels, cross-source lifecycle chain. It also names the id namespaces (Διαύγεια ΑΔΑ, kimdis:<ΑΔΑΜ>, ted:<number>), which separates it cleanly from list/search siblings like search_tenders or get_chain.

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

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

Usage is only implied: you fetch a single act by id. There is one explicit when-not — 'resolve it at diavgeia.gov.gr, not through this API' — but that constrains a response field, not the tool choice. It never routes the agent to get_chain versus get_act, even though get_chain exists as a sibling covering the lifecycle chain this tool only partially surfaces.

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 safety is covered. The description adds genuinely non-obvious behavior: umbrella acts cited by more than 25 acts are deliberately not merged, so chains never absorb unrelated yearly activity. It does not discuss size limits, ordering guarantees, or what happens when a chain is incomplete, though an output schema exists to carry 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?

Front-loaded: what the tool returns comes first, then how to get the input, then the scoping caveat. The umbrella-explanation passage is somewhat long and restates the same point twice ('deliberately NOT merged' and 'they simply do not form a chain'), which is the only 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 a single required parameter, an output schema, and rich annotations, the description supplies the missing conceptual context: what a chain is, what it is not, and where excluded references live instead. Only edge cases (empty or partial chains, invalid chain_id behavior) 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% and the schema gives only a bare string type, so the description must carry the meaning. It does: chain_id is a lifecycle-chain identifier obtained from the chain_id field of any act, which tells the agent how to source a valid value rather than guessing.

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 (reconstruct a procurement lifecycle chain by chain_id) and defines the resource precisely as the linked sequence of related acts with confidence and link method. This clearly differentiates it from the sibling get_act, which returns a single act rather than a linked sequence.

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

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

Explicitly tells the agent how to obtain the required input ('Get a chain_id from the chain_id field of any act') and clarifies the scope boundary of a chain. It implies get_act is the right tool for individual acts and their raw references, but never names an alternative or an explicit 'do not use this when' condition.

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 description's job is to add semantics beyond them — and it does, explaining that EUR totals are deduplicated committed procurement value with tenders/budgets excluded. That prevents a serious misreading of the numbers. It still doesn't say how an unknown or malformed ΑΦΜ is handled.

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: purpose first, then the critical measurement caveat. The second sentence is dense but every clause (deduplication, lifecycle coverage, exclusions) changes how the numbers should be read, so it earns its length.

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 for a one-parameter lookup the description is nearly sufficient, with the deduplication semantics being the key addition. Minor gaps remain around error/empty-result behavior and the meaning of 'role'.

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?

Single parameter with 100% schema coverage, so the baseline is 3. The description's '9-digit ΑΦΜ' merely restates the schema text without adding format examples, normalization rules, or what happens when the entity is absent from the registry.

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 (profile of a legal entity) and enumerates the content returned: name, role, buyer/supplier spend and receipt statistics. The 'by 9-digit ΑΦΜ' key implicitly separates it from find_entity (name-based lookup) and entity_counterparties, though it never names those siblings explicitly.

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

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

Usage is only implied: the agent must infer that this is the tool to call when it already has a 9-digit ΑΦΜ, and that find_entity is the alternative when it only has a name. No 'when not to use' or prerequisite statement is 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description goes further by disclosing that the call is free and not counted against the quota, and that the answer is identical for an API key and a connected account. Those are non-obvious behavioral facts an agent could not infer from annotations or schema, and they directly affect whether the agent should call it liberally.

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 returned data is front-loaded in the first clause, followed by the quota-exemption note and a short usage hint. Two sentences plus a fragment, with no filler or repetition that does not carry information.

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

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

For a zero-parameter, read-only, idempotent status tool with an output schema present, the description covers what it returns, when to reach for it, and its cost model. Nothing an agent needs in order to call it correctly is missing, and the field enumeration is a reasonable convenience even though the output schema also documents the return shape.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The enumerated fields in the description describe outputs rather than inputs, which is harmless but not parameter 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 states concretely what the tool returns: plan, calls used, calls remaining, per-minute rate, page-size and pagination caps, and the reset time. That is a specific resource with enumerated fields, not a restatement of the name. It does not explicitly contrast itself with the sibling tools (all domain-data tools like get_entity or search_tenders), though the difference is fairly self-evident.

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?

"Useful for sizing a long job" gives a concrete situation in which to call it, and the note that the call is free gives a reason to prefer calling it early. There is no explicit when-not-to-use or named alternative, but for a zero-parameter meta tool the context is clear enough.

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 goes well beyond them: it discloses that results are precomputed and refreshed every 6 hours, that the published ranking only holds the top 15, and that spend is deduplicated across sources and lifecycle stages with tenders excluded. The Greek term for direct award and the ≤1-bid definition of single_bidder also clarify metric semantics.

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 action, then defaults and metric definitions, then the example questions and refresh cadence. The by= parenthetical is dense and slightly overloaded, but every clause carries information an agent needs.

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, yet the description still names the returned fields (afm, name, metric, total) and flags the top-15 ceiling that bounds every call. For a read-only ranking tool, nothing needed for correct invocation 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 enums are already listed, so baseline would be 3; the description earns more by defining what each enum actually measures (COMMITTED EUR counted once, single_bidder award count, direct_award = απευθείας ανάθεση) and by explaining the hard 15 cap on limit.

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 (rank) and resource (Greek public-procurement buyers/suppliers), plus the two axes of ranking. This is clearly distinct from lookup siblings like find_entity and get_entity, which retrieve a single entity rather than a leaderboard.

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?

Example phrasings ('top 10 suppliers by public revenue', 'which buyers award most without competition') map directly onto parameter choices, and defaults are stated. It does not explicitly exclude or route away from siblings like spend_by_cpv or entity_counterparties, so it stops short of full when-not guidance.

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

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

Beyond the readOnly/idempotent annotations, it discloses that results are a paginated envelope where 'next' is a page number or null, that natural-person counterparties are redacted, and that one procurement appears at multiple lifecycle stages causing double-counting. Those are exactly the non-obvious behaviors an agent needs before trusting 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?

Front-loaded with the core scope and filter list, then the caveats in the final sentences, with no filler. It is a dense single block with a long parenthetical filter enumeration, which costs a little readability.

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

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

For an 18-parameter open search with an output schema, the description covers purpose, filter semantics, pagination return shape, redaction, and the main analytical pitfall. An agent can call it correctly without reading anything else.

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 already 94%, so the baseline is 3; the description earns more by explaining intent-level meaning — lifecycle status values, procurement signals as published ΚΗΜΔΗΣ facts (direct_award = απευθείας ανάθεση, single_bidder = ≤1 bid), and the TODAY/deadline idiom. It does not cover every parameter (e.g. has_chain, price_only, page_size caps) in prose, leaving minor gaps.

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

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

States a specific verb and resource (search Greek public-procurement acts) and names the three cross-linked sources it spans (Διαύγεια, ΚΗΜΔΗΣ, EU TED). It also distinguishes itself from aggregation siblings by warning that summing amount_net double-counts and naming rank_entities and spend_by_cpv as the correct alternatives.

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

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

Gives concrete combinatorial guidance — deadline_after=TODAY with status=tender yields open tenders — and routes aggregate questions to rank_entities/spend_by_cpv. It does not explicitly state when to prefer get_act, get_chain, or find_entity over this tool, so the sibling routing is partial rather than complete.

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 substantial context beyond the read-only annotations: value is counted once per procurement with deduplication across sources and award/contract/payment stages, tenders are excluded, and results are precomputed nightly so calls are instant. The main gap is that it doesn't say how large the 'top list' is, so an agent can't judge truncation.

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?

Four sentences, each carrying distinct information: definition, deduplication rule, return shape, freshness, and alternatives. Scope and exclusions are front-loaded before the sibling 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 safety covered by annotations and return fields by an output schema, the description supplies exactly the missing pieces: valuation methodology, exclusion of tenders, precomputation/freshness, and the boundary of coverage with a fallback tool.

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

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

Schema coverage is 100% and the schema already documents the year parameter including 'omit for all-time'. The description only restates optionality ('optionally for one year'), so it adds little beyond what the schema provides — baseline 3.

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 measure (deduplicated committed procurement value) against a specific dimension (CPV 2-digit division) with an optional year scope. The parenthetical naming of search_tenders for out-of-top-list divisions makes it clearly distinguishable from 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?

Gives the exact question it answers ('what does the Greek state spend the most on') and explicitly routes the agent elsewhere — search_tenders with cpv= — when a division falls outside the precomputed top list. Both the use case and the escape hatch are named.

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