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

readOnlyHint=true already covers the safety profile, and the description adds genuine context on top: the return structure (bid/ask lists of price/size) and the fact that the call can fail for connection- or license-related reasons. It stops short of saying how to detect or work around that unavailability.

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

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

A single front-loaded sentence that names the resource, the data shape, and the main caveat with zero filler. Nothing to trim.

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

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

With no output schema, the description usefully describes the response shape and the environmental precondition for failure, and the input schema carries the parameter detail. Adequate for a three-parameter read tool, though it omits any hint of pagination/partial-depth behavior.

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 depth, symbolId and connectionId are fully documented in the schema; baseline is 3. The description adds nothing about parameter semantics (e.g., how depth interacts with the two-sided list) beyond what the schema already states.

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 resource (Level 2 market depth) and even the payload shape (bids/asks {price, size}), which implicitly separates it from quantower_get_quote's top-of-book. However, it never names the sibling it complements or contrasts with, so an agent must infer the Level 1 vs Level 2 split itself.

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

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

The description gives no when-to-use or when-not-to-use guidance relative to quantower_get_quote or the other market-data siblings. The only condition mentioned ('peut être indisponible selon la connexion ou la licence') is an availability caveat, not routing advice.

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 only declare readOnlyHint=true, so the description carries real extra weight: it discloses the hard bar cap (QUANTOWER_MAX_BARS, currently 500) and that reads are not cached, which affects call strategy. It stops short of describing response shape or pagination behavior.

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

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

Three tight sentences: purpose first, then the cap, then the caching/perf caveat. No filler, though the timeframe enumeration partly duplicates the schema enum and could be trimmed.

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

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

With no output schema and six parameters, the description does cover the operation's constraints and read-only nature adequately for an agent to call it correctly. It could go further by sketching the returned bar structure (OHLCV field layout, ordering) since no output schema exists.

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 every parameter (symbolId, timeframe, from, to, limit, connectionId) is documented in the schema, so the baseline is 3. The description restates the timeframe list and the limit cap rather than adding format or interaction details beyond the schema.

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

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

States a precise verb and resource ('Renvoie les bougies OHLCV d'un instrument') and enumerates the supported timeframes, which immediately separates it from siblings such as quantower_get_quote, quantower_get_dom and quantower_get_trades. An agent can identify the tool's output domain 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?

The description implies the use case (historical candle retrieval) and gives a tuning hint ('réduisez limit pour les gros historiques'), but never states when to choose this over alternatives, nor any exclusions or prerequisites. Usage is inferred rather than spelled out.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds real value by clarifying the '(working)' qualifier and enumerating returned fields, but omits pagination, ordering, and whether results are limited when no filter is supplied. 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?

One sentence, front-loaded with the action and resource, followed by the returned fields and the filter options. No filler and no repetition of the tool name.

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 parameterless-required, read-only list tool with no output schema, the description covers what the tool returns and how to narrow it, which is enough to call it correctly. Only the behavior with no filters (full dump? capped?) is left 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 description coverage is 100%, so both filters are already documented in the schema. The description only restates that filtering happens via connectionId/accountId and adds no syntax, formatting, or mutual-exclusivity detail. Baseline 3 is correct.

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

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

States a specific verb and resource ('Liste les ordres actifs') and scopes it to working orders only, which implicitly separates it from quantower_get_orders_history. It also enumerates the returned fields, so the agent knows exactly what it gets. It does not name the sibling explicitly, keeping it shy 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?

The description tells the agent the result can be narrowed by connectionId or accountId, which implies the usage context (scoped lookups). However it never states when to prefer this tool over siblings such as quantower_get_orders_history or quantower_get_trades, nor any prerequisites. Usage is implied, not guided.

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?

readOnlyHint=true already declares this is a safe read, so the description carries a lighter burden. It usefully discloses that only terminal statuses (filled/cancelled/rejected) and executed quantities are returned, which is real behavioral context. It stops short of describing pagination, ordering, or auth requirements.

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

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

A single dense sentence with the core purpose front-loaded and no filler. It is compact and information-bearing, though the parenthetical API reference and list of filters make it slightly crowded.

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

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

For a read-only, all-optional-parameter query with no output schema, the description covers the essentials: what population is returned (terminal-status orders), which fields are relevant (executed quantities), and how to filter. The absence of an output schema is partly offset by naming returned statuses and quantities.

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

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

Schema description coverage is 100%, so all five parameters are already documented with formats and bounds (ISO 8601 UTC, default 100 / max 1000). The description only restates the filter categories (range, connectionId/accountId, limit) without adding syntax or semantics beyond the schema, so the baseline of 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 (orders history) and scopes it with 'terminés' (completed), which meaningfully distinguishes it from the sibling quantower_get_orders. It also names the underlying Core.GetOrdersHistory call, adding traceability. It does not, however, explicitly name the alternative sibling to route against.

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 'ordres terminés' scoping implies when to use this over quantower_get_orders (completed vs. active orders), but the usage boundary is left to inference. There are no explicit when-not conditions or prerequisites stated.

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

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

readOnlyHint=true already covers the safety profile. Since there is no output schema, the description usefully lists the returned fields (positionId, NetPnL, etc.), which adds return-format context, but it says nothing about default behavior when no filter is given or volume/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?

Two short sentences, with the core purpose and field list front-loaded ahead of the filter note. No filler, though the parenthetical field list makes it slightly dense.

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

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

For a simple read-only list tool with fully documented params and annotations covering safety, most of what an agent needs is present. The gap is unspecified default scope (all connections/accounts when unfiltered) and the absence of pagination or volume guidance.

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

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

Schema description coverage is 100%, so the schema already documents both filter parameters, and the description only mirrors that with "Filtrable par connectionId / accountId". 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?

States a specific verb ("Liste") and resource ("positions ouvertes") and even enumerates the returned fields, so an agent can distinguish it from get_orders, get_trades, and get_orders_history. It lacks an explicit naming of a sibling alternative, but the resource differs enough from all 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?

"Filtrable par connectionId / accountId" only indicates that filtering is possible; it does not say when to use this tool rather than get_orders or get_trades, nor does it state prerequisites or exclusions. Usage is at best weakly 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 readOnlyHint=true, so the description is not required to establish safety. It goes beyond that by disclosing the one-second server-side MCP cache for quotes, which is a real behavioral trait an agent should know when polling. It omits failure behavior for unknown symbols.

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

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

Two tight sentences: what is returned first, the caching caveat second. No filler and nothing buried.

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

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

With no output schema, the description correctly enumerates the returned fields (Bid/Ask/Last/volume/OHLC du jour), so an agent knows the payload shape. Only minor gaps remain, such as behavior on unknown symbols or multi-connection 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 coverage is 100%, so the baseline is 3, but the description adds the constraint that symbolId must be exact and supplies a concrete example ('EUR/USD'), reinforcing the 'Symbol.Name' format note in the schema. It says nothing extra about connectionId beyond the schema.

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

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

States a specific verb (Renvoie) and resource (Bid/Ask/Last/volume + OHLC du jour) for a given instrument, which cleanly separates it from siblings like quantower_get_dom and quantower_get_history. An agent can tell what it returns 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?

Usage is implied by 'pour un instrument donné', but there is no explicit when-to-use guidance and no mention of alternatives such as get_dom for depth or get_history for past bars. Adequate but leaves routing decisions 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?

readOnlyHint=true already declares this as a safe read, and the description usefully discloses the data source (Core.Trades) and the fact that connectionId/accountId act as optional filters. It says nothing about ordering, pagination, or what happens when no filter is supplied, so it adds moderate rather than rich behavioral context.

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

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

A single dense sentence that front-loads the resource and the source of truth, then the returned fields, then the filters. No filler, though the parenthetical source reference is slightly technical overhead.

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

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

For a read-only listing tool with complete schema coverage and readOnlyHint annotations, the description covers the essentials and even enumerates the return fields, which matters since there is no output schema. The absence of any note on ordering or pagination beyond limit is 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 100%, with the default (100) and maximum (1000) for limit documented in the schema itself, so the schema carries parameter semantics. The description only restates that connectionId/accountId/limit are the filters, adding no syntax or interaction detail beyond the schema.

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

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

States a specific verb-resource pair (history of executions from the Quantower login / Core.Trades) and enumerates the returned fields (tradeId, price, quantity, fee, orderId). It is distinguishable from view tools like get_orders/get_positions by being about fills, though it never explicitly contrasts itself with the sibling quantower_get_orders_history.

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

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

The description notes it is filterable by connectionId / accountId and supports a limit, which implies the usage context, but it gives no explicit when-to-use or when-not-to-use guidance relative to siblings such as quantower_get_orders or quantower_get_orders_history. Usage is left largely to inference.

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

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

Annotations declare readOnlyHint=true, so safety is covered. The description adds value beyond that by enumerating the return fields (accountId, connectionId, balance, devise, PnL) in the absence of an output schema, plus the demo-only operating constraint. It omits any note on pagination or behavior when no accounts exist.

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

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

Three compact sentences that front-load the purpose, then filter, then constraint. No filler, though the parenthetical field list and the filter sentence partially duplicate information the schema already carries.

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 no output schema, the description covers purpose, return fields, filtering, and the safety constraint. Only minor gaps remain, such as pagination or empty-result behavior.

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

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

Schema description coverage is 100% and the single connectionId parameter is already documented with a pointer to quantower_list_connections. The description's "Filtrable par connectionId" merely restates the schema, adding no syntax or format detail. Baseline 3 is correct.

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

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

States a specific verb and resource ("Liste les comptes Quantower") and enumerates the returned fields, so an agent knows exactly what it gets back. It is broadly distinguishable from siblings like quantower_get_positions or quantower_list_connections, though it never explicitly says what it is not.

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

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

Provides a clear usage constraint: use only with demo accounts during development. That is an explicit when-to-use boundary. It stops short of naming an alternative tool or explaining what to do for live accounts, so it is not 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?

readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds that only ACTIVE connections are listed and that connectionId is the key output, which is useful context beyond annotations, but it says nothing about return format, pagination, or behavior when no connection is active.

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

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

Two front-loaded sentences with no filler; the purpose comes first and the usage note second. The trailing "(multi-connexion, plan §1.1)" is a slightly noisy internal reference but does not bloat the text.

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-param lister with readOnly hints, the description carries enough: what it returns (connectionId) and why it matters. No output schema exists, so the brief mention of the returned connectionId is helpful, though the exact response shape and multi-connection ordering remain 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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?

Specific verb+resource: "Liste les connexions actives de Quantower" and it clarifies the resource by naming it (brokers / flux de données). This cleanly distinguishes it from siblings like quantower_list_accounts and quantower_status without needing to name them.

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

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

Explicitly tells the agent why and when to use it: the returned connectionId is "requis ou utile pour la plupart des autres tools," framing it as a prerequisite/discovery call in a multi-connection setup. No explicit when-not-to-use or named alternative, but the routing intent is clear.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: search is case-insensitive, and it enumerates the returned fields (symbolId, connectionId, tickSize, lotStep, minLot/maxLot) in the absence of an output schema. It omits result ordering/ranking, the only notable gap.

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

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

Two sentences, zero filler: the search scope is front-loaded, then the return contract, then the hand-off instruction. Nothing redundantly restates the name or title.

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

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

With no output schema, the description compensates well by listing the returned fields, and the downstream hand-off tells the agent where the symbolId goes. It leaves ranking/ordering and empty-result handling unexplained, which keeps it just short of fully complete for a search tool.

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

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

Schema description coverage is 100%, so query, limit and connectionId are already documented in the schema with examples and bounds. The description repeats only the case-insensitivity of the query and adds no syntax or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Recherche des instruments Quantower par texte') plus the matching semantics (nom/code, case-insensitive), and it names the follow-up tools to use the result with. An agent can tell this is the symbol-discovery step rather than a quote/history call, even though no sibling overlaps.

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 clearly positions the tool as the first step in a pipeline ('Utilisez ensuite quantower_get_quote / quantower_get_history avec le symbolId exact'), which tells the agent when to call it. It does not state any exclusions or what to do if the search returns nothing, so it falls short of fully explicit when/when-not guidance.

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

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

Annotations only declare readOnlyHint=true. The description adds substantial context beyond that: it reports platform version, server mode (read_only or trading), and active connections — behaviors and return content not derivable from the annotation. It also hints at the diagnostic role first-call ordering.

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

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

Two sentences, front-loaded with the core action and result list, followed by the usage directive. Every clause earns its place; 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?

With zero parameters and no output schema, the description fully describes what the tool returns (version, mode, connections) and when to call it. Nothing an agent needs to invoke it correctly is missing.

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

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

No parameters exist, so baseline is 4. The description correctly implies no input is required; no further parameter semantics are needed.

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 ('Vérifie que... répond'), the resource (QuantowerMcpBridge), and enumerates the exact outputs: platform version, MCP server mode (read_only or trading), and active connections. This distinguishes it from siblings like quantower_list_connections, which lists a single resource, whereas this tool is a diagnostic bridge check.

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

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

It explicitly says 'À appeler en premier pour diagnostiquer un problème de connexion' — telling the agent exactly when to use this tool (first, for connection troubleshooting). No alternatives are named, but for a diagnostic entry point that isn't needed.

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