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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds little beyond restating that this is a read operation and that results are filtered by criteria; it does not disclose pagination behavior, response shape, or any API-specific quirks.

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 with the key purpose. The second sentence restates what the title already conveys, but the documentation link provides useful reference value, so it is not 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?

This is a fairly complex tool with 11 parameters, nested objects, and no output schema. The rich schema covers parameter semantics well, but the description omits contextual guidance such as pagination usage, the relationship between FieldNames and type-specific field arrays, or what the returned group objects look like.

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 already has 100% parameter description coverage, including detailed meaning for SelectionCriteria, FieldNames, Page, and each type-specific field-name array. The description does not need to add parameter detail, so 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 states a specific action — returning parameters of ad groups that match given criteria — and identifies the exact API service and method ('Служба adgroups, метод get (чтение)'). This clearly differentiates it from sibling tools for other resources like ads, campaigns, and keywords.

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 context is implied: an agent can infer this tool should be used when ad group parameters matching selection criteria need to be retrieved. However, there is no explicit guidance about when not to use it or which sibling tool might be better for related operations.

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's 'reading' note is consistent with the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) but adds nothing beyond them. Annotations already cover the safety profile, so there is no contradiction, but the description provides no extra behavioral context such as pagination, rate limits, or response expectations.

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 visible description is short and front-loaded: one clear sentence plus a documentation link. The leading HTML source comment is irrelevant noise for an agent, which prevents a 5, but there is no other wasted 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?

This is a complex 19-parameter tool with nested objects, and there is no output schema to document return values. The description does not mention response shape, how SelectionCriteria interacts with the various type-specific FieldNames arrays, or pagination behavior. The rich schema and annotations prevent a 1, but the description is far from complete on its own.

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 contributes no parameter-level meaning. However, schema description coverage is 100%, with each parameter having an inline description and references to direct_fields/direct_schema, so the schema already carries the parameter semantics. Per the baseline rule, this warrants a 3 rather than a higher score.

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

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

The description states that this is the ads service's 'get' method for reading, which identifies the verb and resource clearly. It does not explicitly differentiate it from sibling get methods like direct_adgroups_get, but the resource name 'ads' makes the target entity 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 gives no guidance about when to use this tool versus alternatives. It only says it is a read method, which is implied by the annotations and tool name, but it does not mention exclusions, prerequisites, or how it differs from direct_campaigns_get or direct_adgroups_get.

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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds 'метод get (чтение)' which aligns with readOnlyHint and provides a documentation link, but no additional behavioral traits like pagination or result limits. Given annotation coverage, this is 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?

The description is two concise sentences plus a documentation link. The main action is front-loaded, with no filler or redundancy. It is appropriately sized for its content.

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

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

Given 16 parameters, nested objects, and no output schema, the description is too minimal. It does not explain the variety of adjustment types (regional, demographic, etc.) or how criteria interact. An agent would struggle to correctly construct a request without external documentation. The description relies heavily on schema and annotations.

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 every parameter has at least a terse description (e.g., FieldNames lists possible values). The tool description itself adds no parameter semantics, but the schema carries the load. This meets the baseline for high 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 the tool returns adjustment parameters matching criteria, which is a clear verb+resource. It identifies the service and method (bidmodifiers.get), and the resource is evident from the name. However, it does not explicitly differentiate from sibling getters, though the resource is distinct.

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 on when to use this tool versus the other direct_*_get tools. It does not mention alternatives, exclusions, or prerequisites. An agent would need to infer usage from the name 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'чтение' (read), which is redundant but consistent. No additional behavioral context (e.g., pagination, auth, rate limits) is provided, but the annotation coverage warrants a baseline score.

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 extremely concise: two sentences with the primary action front-loaded, plus a documentation link. There is no filler or redundant information beyond the necessary context.

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 13 parameters, nested objects, and no output schema, the description is inadequate. It does not explain the overall request/response flow, that FieldNames is required to select fields, or how pagination via the Page object works. While the schema descriptions provide per-parameter detail, the high-level description leaves out essential usage context for an agent to call this 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?

Schema description coverage is 100%—every parameter has a detailed description listing allowed values and references to direct_fields. The tool description itself adds no parameter-specific information beyond the general purpose, so it does not exceed the 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?

The description clearly states it returns campaign parameters matching criteria, with the verb 'Возвращает' (returns) and resource 'кампаний' (campaigns). The resource is unambiguous and distinct from sibling tools like direct_ads_get or direct_adgroups_get, though it doesn't explicitly name alternatives.

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

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

There is no guidance on when to use this tool versus alternatives such as direct_ads_get or direct_keywords_get. The description only states what it does, not the context or prerequisites. The documentation link is a resource but not inline guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that it lists both declared and hidden methods and shows how to enable them, which is useful behavioral context beyond the annotations. It doesn't contradict anything.

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, front-loaded with the core action ('Lists ALL API methods') and then adds usage guidance and rationale. Every word earns its place; 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?

The tool has no parameters and no output schema. The description tells the agent what it does and when to use it, but doesn't describe the output format. Given the tool's simplicity, this is adequate but could mention the structure of the returned list. Slight 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 tool has zero parameters, and the schema coverage is 100% (empty object). Per the rubric, the baseline is 4 for zero-parameter tools. The description doesn't need to add parameter info since there are none, and it doesn't.

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 explicitly states the tool lists ALL API methods of Direct, shows which are declared vs hidden, and how to enable them. It clearly distinguishes from sibling get methods by being the catalog of all methods, not a specific data retriever.

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 an explicit trigger condition: 'call when the needed tool is not visible among available ones' and explains that the tool likely exists but is hidden to save context. This tells the agent exactly when to use it, and implicitly when not (when the tool is already visible).

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 carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest context about what data is returned, but does not disclose auth requirements, rate limits, or any behavioral edge cases. 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 short and front-loaded: the first sentence gives the core purpose. The service/method sentence is partly redundant with the title but adds a read cue, and the documentation link is useful. No unnecessary padding.

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

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

For a read-only getter with six well-documented parameter arrays and a pointer to the full field list via direct_fields, the description gives adequate orientation about the intended data. There is no output schema, but the response is essentially the requested fields, so the main gap is more explicit guidance on choosing FieldNames values.

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

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

Schema description coverage is 100%, with each parameter property documented and allowed values listed. The tool description itself adds no parameter-level meaning beyond the overall return content, 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 uses a specific verb 'Возвращает' (returns), names the resource (advertiser/agency parameters and user settings for the representative), and explicitly labels it as clients.get (read). This is enough for an agent to distinguish it from the sibling *_get tools by resource.

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 reading client/agency parameters and user settings, and labels it as a read method. However, it does not explicitly say when to prefer it over sibling tools, does not name alternatives like direct_fields for expanding field lists, and gives no exclusion criteria.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it's a read operation ('чтение') and lists the types of data returned, which is useful context. However, it doesn't disclose behavior like pagination, response size, or that DictionaryNames accepts a limited set of values (though the schema mentions 15 values). 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 concise: two sentences plus a documentation link. The first sentence front-loads the purpose with a clear list of examples. The second sentence identifies the service/method and provides a link. No wasted words, though the list is somewhat long.

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 tool with one parameter and full schema coverage, the description is mostly adequate. It explains what data is returned and provides a documentation link. However, it doesn't mention that DictionaryNames values are limited to a specific set (the schema says 'полный список: direct_fields' but doesn't link it), and there's no output schema, so the return structure is not described. The description could be more complete by enumerating valid dictionary names or pointing to the direct_fields 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 the schema already documents the single parameter DictionaryNames. The description adds context by listing example dictionary names (Currencies, MetroStations, GeoRegions, GeoRegionNames) and mentions '15 значений', but it doesn't fully enumerate the valid values or explain the format. The description adds some value but the schema carries the main 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 clearly states the tool's purpose: it returns reference data (dictionaries) from the Yandex Direct API, listing concrete examples like regions, time zones, currencies, metro stations, parameter restrictions, external networks (SSP), and Crypta segments. It identifies the service and method (dictionaries, get) and provides a documentation link. It doesn't explicitly differentiate from siblings, but the resource (dictionaries) is distinct from the other get_* tools.

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: it's a read-only method for retrieving reference data. It doesn't explicitly state when to use this tool versus alternatives, but the resource name 'dictionaries' and the list of data types make it clear it's for reference data, not for ads, campaigns, or reports. The documentation link provides additional context, but no explicit when/when-not guidance is given.

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

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

Beyond the annotations, the description discloses a critical behavioral caveat: the list is generated from a schema that lags behind the live API, so it may be incomplete, and a value absent from the list must not be treated as invalid. This materially affects agent behavior and is more than the annotations alone provide.

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

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

Three short sentences deliver purpose, rationale, and an essential caveat without redundancy. The 'ВАЖНО' marker effectively highlights the one warning the agent must not miss.

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, idempotent lookup with two optional parameters fully documented in the schema, the description covers what the tool returns, why it exists, and the most important edge case. No output schema is provided, but the nature of the output ('list of valid values') is stated clearly.

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. The description adds value by showing what kinds of enumerations can be requested (report columns, FieldNames sets, campaign types), which helps the agent form a valid value for the 'name' parameter beyond the schema's example.

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: 'Перечисляет допустимые значения перечисления' (lists valid values of an enumeration), and names the concrete domains ('колонки отчётов, наборы FieldNames, типы кампаний'). This makes the helper's role clear and separates it from the sibling CRUD/dictionary tools, even without explicitly naming alternatives.

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

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

The phrase 'Нужен потому, что полные списки в описания инструментов не помещаются' gives a clear use case: consult this tool when a parameter accepts enumeration values that are too long to be documented inline. It does not name explicit alternatives or when-not-to-use conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds behavioral nuance: it reveals that report-only rows represent campaigns that are running but not listed via API and cannot be managed, which is crucial for an agent to understand the tool's output semantics.

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

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

The description is moderately long but each paragraph serves a distinct purpose: purpose, usage guidance, and caveat about report-only rows. It is front-loaded with the core function and structured logically, though it could be trimmed slightly without losing value.

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

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

Given there's no output schema, the description adequately explains what the tool returns (merged table with source labels) and the key nuance of report-only rows. It also justifies why this tool exists relative to a sibling, providing enough context for correct invocation.

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

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

Both parameters are fully documented in the schema with descriptions (DateFrom/DateTo with formats and defaults), so schema coverage is 100%. The description adds no extra parameter information, but the baseline of 3 applies since the schema carries the load.

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 returns the full cabinet composition by merging campaigns from the list and report, with source labels per row. It explicitly contrasts itself with the sibling campaigns.get, making the purpose and differentiation 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?

It explicitly instructs to call this tool instead of campaigns.get when needing 'what is currently running', and explains why campaigns.get is inadequate (doesn't return Master Campaigns). This gives clear when-to-use guidance and names the 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description only repeats 'чтение' and adds no behavioral details beyond that, such as pagination behavior, rate limits, data freshness, or consequences of omitted parameters.

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 first sentence is dense but informative, covering the core purpose and return data. The second sentence is mostly redundant with the title and annotations, though it adds a documentation link. Overall it is compact and front-loaded, with little wasted 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?

The description captures the tool's core function and high-level return values, which matters because there is no output schema. However, it omits details like pagination/Page behavior, exact output shape for the requested fields, and any error or permission context, leaving a moderately complex 5-parameter tool 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 100%, so the schema already documents all parameters and their allowed values. The description adds high-level context about returned bid data but does not elaborate on SelectionCriteria, Page, or the field groups beyond what the schema provides, matching the baseline for fully described schemas.

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 starts with a specific verb and resource: 'Возвращает ставки для ключевых фраз и автотаргетингов' (returns bids for keywords and autotargetings), making the tool's function clear. It is distinguishable from sibling tools like direct_keywords_get by the 'keywordbids' resource and the concept of 'ставки', though it does not explicitly name or contrast a sibling.

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 the tool: when keyword/autotargeting bids or auction data are needed, and it explicitly labels the method as 'get (чтение)'. However, it gives no exclusions, no prerequisites, and no comparison with alternatives such as direct_keywords_get or direct_bidmodifiers_get.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is the keywords.get read operation and enumerates the kinds of returned data, but it does not disclose pagination behavior, response envelope, or status-value semantics. 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 main sentence is front-loaded and efficient, and the documentation link provides practical follow-up. The second sentence 'Служба keywords, метод get (чтение)' is mildly redundant with the tool name and title, but it is short and does not introduce meaningful bloat.

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 getter with 100% schema coverage and strong annotations, the description covers the selection-criteria concept and the main returned fields, while the schema fully documents the nested parameters. It lacks an explicit return-shape description, but that is partly a structural limitation since no output schema is provided.

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 Page, FieldNames, SelectionCriteria, and autotargeting settings in detail. The description only loosely maps returned content to field values and adds no additional parameter-level formatting or usage detail, which matches the baseline for full schema 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 clearly states the operation ('Возвращает'), the resource ('ключевых фраз или автотаргетингов'), and the returned data categories (substitution values, status/state, stats, bids). However, it does not explicitly distinguish this from sibling direct_keywordbids_get, which also involves bids, so it is clear but not fully sibling-differentiating.

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 guidance on when to use this tool versus alternatives such as direct_keywordbids_get or other read tools. The sentence 'Служба keywords, метод get (чтение)' restates the read-only nature but does not provide selection criteria, prerequisites, or explicit exclusions.

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 convey read-only, idempotent, and non-destructive behavior. The description adds non-obvious behavioral context beyond annotations: Master Campaign campaigns are absent from campaigns.get with no error or marker, the report sees everything that was served, and monetary amounts are returned in account currency (rubles), not micro-units.

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 with the core purpose, followed by high-value caveats and a documentation link. Each paragraph earns its place, though the account-composition caveat is somewhat long.

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 tool with ten parameters and no output schema, the description covers the essential context: report scope, account composition caveat, currency behavior, and a link to field documentation. It does not describe response structure or potential async behavior, but the schema and docs link cover most invocation needs.

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 ten parameters are already documented in the schema. The description adds useful context about currency for amount fields but does not explain individual parameters; the schema carries the burden, making baseline 3 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 tool as a statistics report covering impressions, clicks, cost, and conversions across campaigns, ad groups, ads, and queries. It also distinguishes it from campaigns.get by explicitly stating that the report sees the full account composition, while campaigns.get omits Master Campaigns.

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

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

It gives explicit routing guidance against a named alternative: account composition must be determined from this report, not from campaigns.get, because campaigns.get silently omits Master Campaigns. It also labels the tool as the primary accounting instrument. It does not address every sibling tool, but the key alternative is covered.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: nested types are not expanded in other tool schemas and types can be enormous, which explains why this schema lookup exists. It does not disclose additional runtime behavior such as output shape or limits, so a 3 is appropriate.

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

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

Two sentences, each earning its place: the first states what the tool returnsconcisely, and the second explains when and why it is needed. No redundant wording or 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, read-only introspection tool with full parameter schema coverage and annotations declaring safety, the description is complete enough to guide correct invocation. It could mention the output format or relationship to direct_fields, but that is not essential for making the call 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 description coverage is 100%: the 'type' parameter is described with examples and 'depth' is described with a default value. The description adds no parameter-level meaning 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 uses a specific verb ('Возвращает') and a clear resource ('точный состав типа Директа'), and elaborates on what the result includes: fields, required fields, and lists. It does not explicitly differentiate itself from siblings like direct_fields or direct_catalog, 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?

The description explicitly states when the tool is needed: 'перед созданием и изменением объектов', and explains the reason — nested types in tool schemas are not expanded because types like CampaignAddItem are very large. It provides clear context but does not give exclusions or name alternative tools.

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