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

The readOnlyHint annotation already signals a safe, non-mutating operation, and the description adds useful behavioral context by specifying that keys are shown masked, missing keys are identified, and instructions for obtaining them are provided. No contradictions are present.

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 sentences long and every phrase is useful: it states the purpose, the masked output, what to do when missing values are found, and names the companion tool. The front-loaded call-first instruction is prominent without excess wording.

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 status tool with no output schema, the description covers what it does, when to call it, what gaps it reveals, and how to remediate them. No critical information is missing for an agent to correctly select and invoke the 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 tool takes zero parameters, so the description correctly focuses on the output and usage rather than input semantics. The baseline for a zero-parameter tool is 4, and the description satisfies this by explaining what the tool reports.

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

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

The description identifies the tool as reporting XMLStock authorization status: which keys are set (masked), which are missing, and how to obtain them. This clearly distinguishes it from sibling tools like xmlstock_set_credentials, which performs the credential-saving action.

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 explicitly instructs the agent to call this tool first at the start of working with XMLStock, and prescribes the next step if credentials are missing: request values from the user and save them via xmlstock_set_credentials. This is direct, actionable usage guidance with a named alternative.

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 mark it read-only; the description adds useful behavioral context: the call is free, it also validates keys, and it covers daily expense. This goes beyond the structured annotations without contradicting them.

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 deliver the core purpose and a bonus behavior with no filler. The main output ('balance and daily expense') 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 one-optional-parameter, read-only tool with no output schema, the description adequately states the return scope and side purpose. A note about the exact response format or fields would improve completeness, but the tool is simple enough that nothing critical is missing.

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

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

The only parameter, 'account', is fully documented in the input schema, including the multi-account hint and empty-meaning-main behavior. The description adds no parameter-specific detail, but with 100% schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource (XMLStock account), the data returned (balance and daily expense), and a distinguishing side purpose (key verification). It is immediately separable from sibling search and auth tools by its core function.

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 when to use it: when an account balance, daily expense, or key validity is needed. However, it does not explicitly differentiate it from xmlstock_auth_status, which likely overlaps with the 'key check' purpose.

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?

The description adds valuable behavioral context beyond the annotations: calls are paid ('ПЛАТНО за запрос') and the `truncated: true` field indicates when results end earlier than the requested depth. It does not contradict the `readOnlyHint:false` annotation because the paid nature of the call can be considered a consequential side effect even though the operation searches.

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 compact sentences: the first states the purpose and cost, the second describes the return shape and truncation flag. Every clause earns its place, and key 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?

With no output schema, the description correctly documents the return fields and truncation behavior. The schema covers defaults, enums, and cost implications per page. The definition is slightly incomplete around authentication prerequisites and error behavior, but the account parameter hints at *_auth_status, so the gap is minor.

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

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

The input schema already documents most parameters well, with 71% coverage including depth, region, safeSearch, searchDomain, and account. The free-text description adds little parameter-level meaning beyond what the schema provides, and parameters like query and device remain only implicitly understood.

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

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

The description opens with a specific verb and resource: 'Поиск по картинкам Google через XMLStock' (Google image search via XMLStock). This clearly distinguishes the tool from siblings like xmlstock_news, xmlstock_video, and xmlstock_serp without needing to inspect their schemas.

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

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

The description implies its use case through the phrase 'поиск по картинкам' but does not explicitly state when to choose it over alternatives or when not to use it. The paid-per-request warning is useful context, but no exclusions or sibling comparisons are provided.

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

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

Beyond the annotations, the description warns that every request is paid, enumerates the exact return shape, and explains the meaning of 'truncated: true'. These are operationally important behavioral details that annotations alone do not provide. It does not contradict any annotation.

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 short, information-dense sentences: the first establishes purpose, cost, and return fields; the second defines the truncation flag. There is no filler or 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?

For a paid news-search tool with no output schema, the description is largely complete: it states cost, output format, and truncation behavior, while the schema documents most parameters. It does not explicitly state authentication prerequisites, but the account parameter's reference to '*_auth_status' and the sibling auth tools supply that context.

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 itself adds no parameter-level explanation, but the input schema already covers 71% of parameters with meaningful descriptions (depth, region, safeSearch, searchDomain, account). The coverage gap for query and device is minor and largely inferable, so the schema carries the burden.

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 uses a specific verb-resource pair ('Поиск по новостям Google' / search Google News) and clearly identifies XMLStock as the execution channel. This distinguishes it from sibling tools like xmlstock_serp, xmlstock_images, and xmlstock_video by targeting the news vertical.

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 intended use is implied by 'news' — an agent can infer this tool is for Google News results — but there is no explicit guidance about when to prefer it over xmlstock_serp or when it should not be used. The cost warning and return-format hints provide supporting context but not decision rules.

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?

The description discloses critical behaviors beyond annotations: every request is billed, pagination creates additional paid requests, empty results still cost money, mobile responses omit hlword/PAA/related, and yandex_xml returns different stats and fields. No statement contradicts the annotations; readOnlyHint=false is consistent with paid side effects.

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 dense but front-loaded with purpose, billing, and response shape. Some paid-request warnings are repeated, and the single-block format could benefit from headings or bullet separation, but every section serves a functional purpose and no filler is present.

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 17 parameters, the description carries the full burden of explaining return values and constraints. It covers found/truncated/count/results/serp_features, empty-result behavior, engine-specific output fields, pagination, and source limitations. This is complete enough for reliable invocation and interpretation.

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?

Even though schema coverage is high at 82%, the description adds substantial parameter-level meaning: depth pagination behavior, region working across all engines, mobile-specific restrictions, non-applicable parameters for yandex_xml, and safeSearch-to-filter mapping. This goes well beyond what the JSON 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 tool as a snapshot of Google/Yandex SERP via XMLStock and immediately distinguishes it from image/news/video siblings by describing organic results and serp_features. It also explicitly names engine variants and their semantic differences. This is a specific verb-resource pairing that an agent can act on without ambiguity.

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 strong selection guidance between engine values, especially yandex_xml versus yandex (live), listing non-applicable parameters and safeSearch mapping. It does not explicitly tell the agent when to choose this tool over sibling tools like xmlstock_images or xmlstock_news, so it falls just short of a 5.

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

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

Goes well beyond the readOnlyHint=false annotation by disclosing the exact file path, the 600 permission mode, live application without restart, multi-account suffix behavior, and response masking. This gives an agent a precise model of the side effects without needing to inspect the environment.

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 dense sentences carry the core action, side effects, usage rule, and response behavior with no filler. Critical information is front-loaded at the beginning, and every clause earns its place.

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

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

For an optional-parameter mutation tool with no output schema, the description covers persistence location, permissions, activation behavior, updates-only guidance, multi-account handling, and output masking. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds value by clarifying update semantics ('only fields to update'), the account profile suffix behavior, and that user-supplied values are masked in responses, which the schema does not convey.

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?

Description opens with a specific verb and resource: 'Сохранить ключи xmlstock в /root/.config/seo-tools-mcp/.env (права 600)' and adds the immediate-apply behavior. It clearly identifies this as the credentials-setting tool among siblings that are all data/query tools, so there is no ambiguity.

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

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

Gives clear operational guidance: 'Передавать только обновляемые поля' and explains the account parameter's role in multi-account profiles. It does not explicitly say when to prefer this over alternatives, but no sibling performs credential writing, so the usage context is already unambiguous.

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

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

Beyond the sparse annotations, the description discloses the paid-per-request nature, explains the truncated flag's meaning, and specifies the returned object shape. This is valuable behavioral context that annotations cannot convey, and nothing in the description contradicts the annotations.

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

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

Two compact sentences front-load purpose and cost, list only relevant output fields, and define an important edge case. Every sentence carries useful information without 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 no output schema, the description compensates by listing the return fields and explaining truncated behavior, while the schema covers parameters well. It does not explicitly state credential prerequisites, but the sibling *_auth_status/set_credentials tools and the paid-request warning provide enough operational context for an agent to proceed.

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 71%, and the description does not add substantial parameter-level meaning beyond mentioning 'requested depth' indirectly through truncated. Most parameter semantics (depth pagination, region mapping, safeSearch behavior) are already well documented in the input schema, so the description adds little beyond the schema baseline.

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?

Description states a specific action and resource: 'Поиск по видео Google через XMLStock', clearly distinguishing this video-search tool from siblings like xmlstock_serp, xmlstock_images, and xmlstock_news. It also enumerates the exact return fields, making the tool's function unambiguous.

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 clearly signals a critical cost condition ('ПЛАТНО за запрос') and explains truncated=true, helping an agent interpret when results are incomplete. It does not explicitly name sibling alternatives or provide when-to-use vs. when-not-to-use guidance, but the video-specific focus supplies enough contextual direction.

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 are present (readOnlyHint: false, openWorldHint: true), so the description's burden is lower. The description adds key behavioral context: it is a paid service (~19₽/1K) and provides the exact return shape, including both 'results' (top phrases) and 'associations' (similar phrases). This goes beyond what annotations convey. No contradiction with annotations.

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

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

The description is compact yet information-dense. It front-loads the cost warning, then the return structure, then the operator syntax — all in three sentences. No filler; every sentence earns its place.

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

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

For a paid tool with no output schema, the description covers the essential behavioral details: cost, return format, and query language. It does not mention error handling, rate limits, or authentication requirements, but the sibling *_auth_status and set_credentials tools cover auth. Given the openWorldHint and annotations, the description is quite complete for an agent to call it correctly.

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

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

Schema coverage is 67%, and the query parameter lacks a description in the schema. The description compensates by explaining Wordstat operators ("...", !, +, -, [ ], |) in the query. Region and account are already described in the schema, so this is a strong contribution. The description makes the query parameter's syntax 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 tool's function: returning Yandex Wordstat frequency and top queries via XMLStock. It specifies the return structure ({ totalCount, results, associations }) and even lists supported Wordstat operators. This distinguishes it from sibling tools like xmlstock_wordstat_dynamics (trends over time) and xmlstock_wordstat_regions (geographic data).

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 states when to use this tool — when you need wordstat frequency and top queries — and includes a cost warning ('ПЛАТНО за запрос'). However, it does not explicitly exclude alternatives like dynamics or regions, nor does it mention when NOT to use it (e.g., for trends use wordstat_dynamics). The 'when' is implied but alternatives are not named.

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?

The description adds valuable context beyond annotations: it states the operation is paid per request, explains that month periods automatically stretch to whole months, and describes the return shape. It does not mention auth prerequisites, rate limits, or error behavior, but the annotations already provide a partial safety profile.

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 cover purpose, cost, period options, date constraints, automatic month stretching, and the return format without filler. The information is logically ordered and every clause contributes.

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 paid time-series query with no output schema, the description provides sufficient operational detail: period values, date format, and the returned object shape. It omits explicit instructions about credentials and the meaning of share, but those are partially covered by the account parameter referencing *_auth_status.

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 67%, and the description adds some meaning for period behavior and output format. However, it largely repeats the date format and enum values already present in the schema, leaves the query parameter implicit, and does not explain count/share 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 clearly identifies the tool's purpose: it returns wordstat frequency dynamics over time, distinguishing it from a static wordstat lookup. It names the resource and data source explicitly, though it does not reference sibling tools by name.

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 explains parameter mechanics, such as period values and date ranges, but does not say when to use this tool instead of xmlstock_wordstat or other siblings. No alternatives or exclusions are mentioned, leaving the choice to the agent's 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 provide little behavioral detail. The description adds critical non-obvious information: the call is PAID and more expensive than top/dynamics, and a cold 24h cache triggers an additional PAID regionsTree request. This is exactly the kind of side-effect disclosure an agent needs, and it does not contradict the annotations.

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

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

The description is compact and front-loaded: core purpose first, return shape second, and a clearly labeled warning about the additional paid request last. Every sentence contributes operational value with no fluff.

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?

Because there is no output schema, the description appropriately includes the return record shape. It also covers caching and cost behavior, which are essential for safe invocation. The main gaps are the lack of an explicit authentication prerequisite and no edge-case details such as empty results, but the schema and sibling tools partially cover these.

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 schema only says 'query' has minLength 1, so the description adds the key meaning: query is the phrase whose regional demand is returned. The account parameter is already described in the schema. Together they cover both parameters reasonably well, though query syntax and formatting are not detailed.

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?

Description states a specific verb-resource pair: returns regional demand distribution for a phrase via Yandex Wordstat/XMLStock. The exact returned record shape is listed, and the region focus clearly distinguishes this from siblings like wordstat_dynamics or wordstat_regions_tree.

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

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

The phrase 'для фразы' implies the tool is used for per-phrase regional breakdowns, and the cost warning is useful context. However, it does not explicitly state when to choose this over xmlstock_wordstat or wordstat_regions_tree, nor does it mention alternatives by name.

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

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

Beyond the annotations, the description adds the important behavioral fact that the request is paid ('ПЛАТНО за запрос') and specifies the returned payload (id + name + path). It does not describe authentication requirements or side effects, but the annotations already cover the safety profile.

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 compact sentence with the key facts front-loaded: what the tree is, what fields it returns, why it matters, and that it is paid. Every clause contributes information; 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?

For a simple parameterless-by-default retrieval tool, the description covers output fields, the region-ID use case, and cost. It does not explicitly state that credentials or authentication are required, but the sibling auth/set_credentials tools and the XMLStock context make this an acceptable 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?

The input schema covers the only parameter (account) fully with its own description, so the baseline applies. The tool description adds no detail about the account field, but none is needed because the schema already explains the multi-account behavior.

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

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

The description identifies a specific resource: the Yandex Wordstat regions tree returned through XMLStock, with id, name, and path fields. It also states its purpose as supplying region IDs for other requests. However, it does not explicitly contrast this tool with the sibling xmlstock_wordstat_regions, so differentiation is left to the name.

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 'id для параметра region в других запросах' gives a clear use case: fetch the tree to obtain region IDs for subsequent queries. It does not state when not to use it or name alternatives such as xmlstock_wordstat_regions, so the guidance is implied rather than explicit.

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