terminal

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

No annotations are provided, so the description carries the burden of disclosure. It reveals the scope of the output (coverage, corpus size, verification method) and adds useful domain context ('signed, source-bound'). However, it doesn't state the expected response format, whether it is a static text summary, or any limitations.

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

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

The description is a single, tightly written sentence with front-loaded identification and meaningful specifics. Every phrase earns its place, and there is 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?

For a parameterless informational tool, the description covers the essential context: what DTA is, its key attributes, and the expected content topics. It lacks an explicit statement of the return shape or a direct 'use this when...' note, but overall it is sufficient for an agent to call the tool correctly.

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

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

The tool has zero parameters and an empty input schema, so there is nothing for the description to explain. The baseline of 4 is appropriate because no 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 clearly identifies the resource (DTA/dta.mn) and frames the tool as an informational overview covering its coverage, corpus size, and verification. It does not use an explicit action verb like 'returns' or 'describes,' but the intent is unambiguous. It doesn't explicitly distinguish itself from the data-access siblings, though its meta/about nature is 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?

The description implies this is a starting point for understanding DTA before querying data, but it provides no explicit guidance on when to use this tool versus the sibling tools like search_series or get_datum. There are no stated exclusions or alternative routing conditions.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses little: 'signed' hints at an authentication or signing requirement but is never explained, and there is no statement about read-only nature, freshness guarantees beyond embedded phrases ('today's', 'last 30 days'), or result shape. For a tool with zero annotation coverage this is a meaningful 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?

Everything in the description earns its place — no filler — but it is a single run-on sentence built from nested parentheses, which makes the value-to-content mapping harder to scan than a short list would be. The resource is front-loaded, though the verb is not.

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

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

With no output schema and no annotations, the description does cover the breadth of content per board, which is the main thing an agent needs to choose a value. It still leaves out what 'signed' means for invocation, whether results are live or cached, and any guidance relative to the ten sibling tools.

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%, but the sole parameter is an enum whose five values are each given concrete content and scope: khural is member-by-member and summarised, auctions is lot-by-lot, auction_results covers the last 30 days, rail is today's departures from Ulaanbaatar, and fuel_stations is pump prices by station. This is real meaning added beyond a bare enum list; only the 'signed' aspect of the input remains 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?

The description enumerates the five board types and what each contains, so the resource is identifiable, but the leading phrase 'A signed board:' never states what the tool actually does — fetch, render, or aggregate — and 'signed' is left unexplained. It also doesn't distinguish itself from data-oriented siblings like get_panel, get_family, or get_series.

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

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

There is no statement of when to use get_board versus the many sibling retrieval tools (get_panel, get_series, get_bulk, get_family). The only implicit guidance is the sub-topic labels themselves, which describe contents rather than selection conditions.

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

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

With no annotations, the description discloses substantial behavior: gzipped CSV output, full-record scope, sha256 and size per file, and a download URL. It still leaves authentication, rate limits, and exact return mechanics unstated, so it falls short of 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?

The description is a single front-loaded sentence with no filler; it packs scope, format, integrity details, and the download URL into one concise statement.

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 tool with no output schema, the description gives enough about content and delivery (CSV, checksums, sizes, URL) to call it correctly. It could clarify whether the tool returns metadata versus initiating a download and any access requirements, so it is not perfect.

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 are zero parameters, so the baseline is 4. No parameter semantics are needed, and the description introduces nothing misleading about inputs.

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

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

The description names the resource (bulk release) and specifies its scope: the whole record as gzipped CSV, every value, every vintage, the catalogue, plus sha256 and size per file. It is clearly distinct from sibling getters for individual series/topics, though it uses a noun-led phrasing rather than a direct verb.

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 tool is for full-record retrieval ('the whole record') as opposed to the individual getters in the sibling list, but it never explicitly states when to choose this over get_series/get_datum or whether there are prerequisites. Usage is inferable from 'bulk' but not 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?

No annotations exist, so the description carries the burden. It discloses the returned data composition, including a cryptographic signature and verification recipe, which is useful behavioral context. However, it does not state side effects, error behavior, permissions, or whether the operation is strictly read-only.

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

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

The description is a single dense sentence that front-loads the tool's purpose and then lists the returned items. Every phrase adds value, there is no repetition or fluff, and the structure is 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?

For a one-parameter read-oriented tool with no annotations or output schema, the description covers the essential input and output composition. It stops short of detailing return structure, error conditions, or how the verification recipe should be used, but an agent can correctly invoke the tool with the provided information.

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 only gives shortid as a string. The description adds meaning by indicating shortid is the lookup key for a single observation, but it provides no format, constraints, or example. It compensates partially but not fully for the missing schema description coverage.

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 'get' and a clear resource: a single signed observation's passport keyed by shortid. It enumerates the returned contents (value, vintage, source URL, schema, Ed25519 signature, verification recipe), which distinguishes it from sibling tools that deal with panels, movers, or series.

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

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

No explicit guidance is given about when to use this tool versus alternatives. The description implies use when a shortid is available, but it does not mention when not to use it, nor does it point to siblings like search_series or get_movers for broader retrieval needs.

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?

With no annotations, the description carries the full burden and does supply two real behavioral facts: results are capped at 400 and each series is returned with its latest value. It omits ordering, anchoring of the pattern, and what happens on a malformed pattern or zero matches.

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 contract (pattern match, latest value, 400 cap) is front-loaded before the examples. The trailing list of six example families is dense but each illustrates a distinct domain, so it mostly earns its place; splitting the run-on single sentence would improve scannability.

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 with no output schema, the description covers the input syntax, the return shape ('each with its latest value'), and the result cap. Only ordering and edge-case behavior are absent, which are minor for this 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 compensate, and it does: '% any run, _ one character' defines the LIKE syntax the bare 'string' type leaves unexplained, and the example patterns demonstrate real values. It stops short of saying whether the pattern is matched against the full code or a prefix.

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: it returns every series whose code matches an SQL LIKE pattern, each with its latest value. The LIKE-pattern semantics plus the 'family' framing let an agent distinguish this from get_series or search_series without opening a schema, though no sibling is named 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 via the six example family patterns, which show the intended shape of a call. There is no explicit statement of when to prefer this over get_series, search_series, or get_datum, and no guidance on invalid patterns.

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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the result is a 'signed movers:v0 snapshot' and that ordering is by delta z-score, which is useful. However, it does not mention whether the data is live or cached, what the return shape looks like, or any rate/access constraints, though as a read-only getter the risk is modest.

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?

Single sentence, front-loaded with the key concept, and contains no filler. 'Today's biggest movers across the archive' immediately conveys scope, while the parenthetical adds precision about the snapshot and ranking metric without bloating the definition.

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

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

For a parameterless tool, the description is sufficient to know what the tool conceptually returns and how it is ordered. However, since there is no output schema, the description does not fully specify the returned item structure, so an agent cannot precisely anticipate field names or types. This is a clear gap, but not a severe one for such a simple tool.

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

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

The input schema has zero parameters, so there is nothing for the description to add about parameter meaning. The baseline for a parameterless tool is 4, and the description enriches context by explaining the snapshot and ranking criteria, which is more than the schema alone 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 clearly identifies the resource ('today's biggest movers across the archive') and the key aspect of the data ('ranked by delta z-score'). It lacks an explicit verb like 'list' or 'get,' but the tool name and phrasing make the purpose obvious. It does not explicitly distinguish itself from get_datum or get_panel, though the movers snapshot concept is sufficiently unique.

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 this tool is for retrieving today's movers, but it gives no explicit guidance about when to choose it over siblings such as search_series or get_datum. There are no stated conditions, exclusions, or alternatives, leaving the agent to infer usage from the name and phrasing alone.

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?

No annotations are provided, so the description carries the full burden. It does disclose real behavioral traits: vintage selection ('latest vintage per date'), point tuple ordering [date, value, shortid], and the batch cap. It omits the outer return container (map keyed by code vs. list of series), ordering, and behavior for unknown codes.

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 dense sentences with no filler, and the core scope is front-loaded. The missing verb makes the opening slightly telegraphic, but nothing 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 no annotations and no output schema, the description must cover behavior and returns. It gives the per-point shape but not the overall response structure, ordering across series, or missing-data handling — gaps an agent will hit on the first call.

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

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

Schema coverage is 50%: `limit` is documented in-schema, while `codes` has only a bare array type. The description compensates by naming what `codes` are (series codes) and restating the 8-item cap, which is the meaningful semantic for that parameter.

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

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

The resource and scope are concrete: time series for up to 8 series codes, latest vintage per date. The verb is elided (it reads as a noun phrase), but an agent can still tell this is a multi-series fetch. It does not explicitly contrast with get_series or get_bulk, so sibling differentiation is only partial (via the get_datum hand-off note).

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 the batch constraint ('up to 8 series codes') and by the follow-up hint that shortid feeds get_datum. There is no explicit statement of when to choose this over get_series or get_bulk, nor any exclusion or precondition.

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?

No annotations are provided, so the description must carry the behavioral burden. It lists the returned facts, which helps, but says nothing about read-only safety, error behavior for an unknown code, authentication, or rate 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?

One front-loaded sentence lists the returned fields with no filler. The enumeration is dense but every item is relevant to selecting and understanding the 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?

For a simple one-parameter getter with no output schema, the description does a reasonable job of enumerating return fields. However, it leaves the required 'code' parameter completely undocumented and gives no usage context, so it is only minimally complete.

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

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

Schema description coverage is 0% and the sole parameter 'code' is never mentioned in the description. The agent gets no indication of what 'code' is, such as the identifier format, source, or expected value.

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

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

The description identifies the resource ('One series') and enumerates the specific facts returned, so the agent knows this is a single-series metadata lookup rather than a search or data-point fetch. It does not explicitly name siblings or state how it differs from get_datum/search_series, so a 4 rather than 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?

No guidance is given on when to call this versus search_series (to find a series) or get_datum (for a data point). The agent must infer usage from the name alone; there are no prerequisites, exclusions, or alternative-tool routing.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the response payload (concepts, series, latest value), which is the key behavioral fact, but says nothing about response size, whether 'latest value' can be stale or missing, or behavior on an invalid code.

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 waste: the return shape is front-loaded and the code-value guidance follows. The enumeration is long but earns its place given 0% schema coverage on an unconstrained string parameter.

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 one required param, no output schema, and no annotations, the description covers what the tool returns and where codes come from — the two things an agent actually needs. Error behavior and result-size expectations are the only notable omissions.

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% and the single 'code' parameter is untyped beyond 'string', so the description must compensate — and it does, naming list_topics as the source and enumerating concrete valid codes (inflation, fx, money, rates, ...). What's missing is whether codes are case-sensitive or how to handle unlisted ones.

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 resource and return shape: a topic's concepts, their series, and each series' latest value. It implicitly distinguishes itself from list_topics (which supplies the codes) but doesn't explicitly differentiate from get_family or get_series, 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?

'each [code]... from list_topics' implies the prerequisite lookup step, which is genuinely useful workflow guidance. However, it never says when to choose get_topic over get_family, get_board, get_panel, or get_series, leaving the sibling selection 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the shape of each returned record (code, names, shape, series count), but says nothing about result size, ordering, or whether the catalogue is exhaustive or filtered — the kind of context that matters for a discovery 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?

Two short sentences, front-loaded with what you get and followed by the next step — no waste. The terseness borders on cryptic ('shape'), costing a point.

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

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

With no output schema, the description must explain return values, and it only gesture toward them — 'shape' is undefined jargon and there is no indication of how many topics come back or their structure. Adequate as a signpost, thin as documentation.

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 no parameters and the schema is an empty object, so there is nothing to disambiguate. Baseline of 4 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 the resource (the catalogue's topics) and its returned fields — code, names, shape, series counts — which is specific enough to tell it apart from get_series or search_series. Sibling differentiation is only implicit via 'then get_topic', so it stops 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?

'Start here, then get_topic' gives an explicit sequential entry point and names the concrete follow-up tool. It does not state any exclusion or when *not* to use it, but for a zero-parameter discovery tool the routing guidance is clear.

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

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

With no annotations, the description carries the transparency burden. It discloses the result limit (up to 15 series) and the presence of codes, but it does not describe the return format, potential error cases, or whether the operation has any side effects. Since it is a search function, the lack of side-effect disclosure is acceptable, but the description could be more detailed about output structure.

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

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

The description is two concise sentences with no redundant information. It efficiently conveys the tool's purpose, scope, and output without unnecessary elaboration.

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

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

The description provides sufficient context for an agent to understand what the tool does, what it returns, and how it fits into a larger workflow (use with get_panel). It does not specify the exact output schema or edge cases, but given the simplicity of the tool and the absence of an output schema, the description is adequately complete.

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

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

The description of the only parameter 'q' is highly informative: it specifies that it is a substring with a minimum length of 2 characters and provides multiple examples in both English and Mongolian. This goes well beyond the schema's basic type definition and makes the parameter's semantics completely clear.

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

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

The description clearly states the action (search), the resource (series catalog), and the search criteria (by code or name in English or Mongolian). It also mentions the return of up to 15 series with codes, which differentiates it from other tools like get_panel and supports its intended downstream use.

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 usage by stating it returns codes for use in get_panel, giving clear context for when to employ this tool. It does not explicitly mention alternatives or when not to use it, but the purpose is specific enough to guide appropriate use.

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