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

Annotations already declare the write, idempotent, and non-destructive profile, so the bar is lower. The description adds real policy context beyond them: the operation is 'guarded' and an uncertain outcome must not be resent, which is a retry-safety nuance not captured by idempotentHint=true. It is vague, though, about what counts as 'uncertain' and which reconcile tool to use afterwards.

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?

It is a single front-loaded sentence with no filler, which is efficient. However, for an 8-parameter guarded write with zero schema documentation, one sentence is under-specified rather than appropriately sized.

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 six required parameters, no parameter descriptions, and no annotation for the confirmation/idempotency workflow, the definition should explain how confirmation_hash and idempotency_key relate to the guard. An output schema exists, so return values need not be described, but the call prerequisites are effectively undocumented.

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

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

All 8 parameters (name, radius, points, geo_segment_type, confirmation_hash, idempotency_key, period_length, times_quantity) have 0% schema description coverage, and the description mentions none of them. Nothing explains radius units, points format, allowed geo_segment_type values, or what confirmation_hash and idempotency_key must contain.

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 gives a specific verb+resource ('geo-circle create') and the name itself distinguishes it from the sibling audience_create_geo_polygon. It stops short of naming or contrasting any sibling explicitly, so the agent must infer the circle-vs-polygon distinction from the tool name rather than the prose.

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?

'Run one guarded geo-circle create' implies a single invocation, but there is no guidance on when to pick this over audience_create_geo_polygon, audience_validate_create, or the prepare/apply/reconcile family. The 'uncertain outcomes are not resent' line hints at a no-retry policy without saying what to do instead.

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

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

Annotations already cover write (readOnlyHint=false), open-world, idempotent, and non-destructive behavior. The description adds that it is a single guarded create, that `last` is refused, and that unknowns are not resent, but 'guarded' is undefined and the other terms are cryptic, so the added context is limited.

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 single sentence is front-loaded with the core purpose and avoids padding. However, it is under-specified for a 7-parameter guarded create tool, so brevity veers into obscurity rather than clear conciseness.

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 complex 7-parameter write operation with 5 required fields, 0% schema description coverage, and a confirmation/idempotency guard, the description is severely incomplete. Output schema and annotations reduce the return-value and safety burden, but the agent still lacks enough information to invoke 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?

Schema description coverage is 0% across 7 parameters, including required confirmation_hash and idempotency_key. The description explains none of them: it never defines polygons, geo_segment_type, period_length, times_quantity, or what confirmation_hash is for. It does not compensate for the coverage gap.

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: 'geo-polygon create'. Distinguishes from sibling audience_create_geo_circle and audience_create_pixel through the geo-polygon noun. 'guarded' and 'one' add scope but are not fully clarified.

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 when-to-use or when-not-to-use guidance. It does not say when to choose this over audience_create_geo_circle, audience_validate_create, or the audience_manage_prepare/apply flow. The notes about `last` and unknowns are constraints rather than selection 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 idempotentHint=true and destructiveHint=false, so the safety profile is partly covered. The description does add a nuance beyond that: a timed-out/uncertain call must not be blindly retried. But it leaves 'guarded' undefined and never explains the confirmation mechanism or whether the pixel is usable immediately.

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

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

A single compact sentence with the operation front-loaded and no filler. It loses a point because the compressed phrasing ('guarded') is cryptic rather than informative at this length.

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

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

An output schema exists so return values need not be explained, but for a write tool with three fully undocumented required parameters, no prerequisite flow, and no recovery path for uncertain outcomes, the description is far too thin to let an agent invoke 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 description coverage is 0% and all three parameters (name, idempotency_key, confirmation_hash) are required and undocumented anywhere. The description only obliquely gestures at idempotency semantics and says nothing about what confirmation_hash is, where it comes from, or the format/uniqueness rules for idempotency_key.

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 concrete verb+resource ('create' a 'tracking-pixel'), which distinguishes it from the geo_circle/geo_polygon/pixel_viewers siblings. However, it never distinguishes itself from the closely related audience_validate_create or audience_reconcile_create, which an agent would need to sequence around this call.

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 explicit when-to-use guidance, no mention that a validate step or confirmation_hash must be obtained first, and no pointer to audience_reconcile_create for ambiguous outcomes. The phrase 'uncertain outcomes are not resent' is a behavioral note, not usage 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?

Annotations already declare readOnly=false, idempotent=true, openWorld=true, destructive=false, so the safety profile is covered. The description reinforces this with 'guarded' and 'uncertain outcomes are not resent', adding nuance about non-resend on ambiguity, but says nothing about the confirmation_hash flow or required auth.

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

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

A single front-loaded sentence with no filler, which is efficient. But the terseness tips into under-specification rather than precision for a 7-parameter mutation 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 7-required-parameter mutation tool with an output schema present, the description should at least orient the agent on the confirmation/idempotency parameters, yet covers none of them. Return-value explanation is not needed given the output schema, but the parameter and selection gaps leave the definition substantially incomplete.

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% across 7 required parameters, so the schema provides no help either. The description offers no meaning for opaque fields like confirmation_hash, idempotency_key, or times_quantity_operation, only faintly implying a guarded/confirmation flow via 'guarded'.

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 verb ('create') and a resource ('pixel-viewer segment'), so the core action is identifiable. However, the odd phrasing 'Run one guarded pixel-viewer segment create' reads like an internal label and offers no differentiation from siblings such as audience_create_pixel or audience_validate_create.

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 versus audience_validate_create, audience_create_pixel, or audience_reconcile_create. The only contextual hint is 'uncertain outcomes are not resent', which speaks to retry behavior rather than tool selection.

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 fully covered. The description only adds the notion that the result is derived from an authoritative list, which is marginal context rather than substantive behavioral disclosure (no error or auth behavior).

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

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

One short sentence, front-loaded with the verb and resource. It is efficient, but the dangling 'documented authoritative pixel list' clause adds words without adding clarity, keeping it out of the top band.

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

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

An output schema exists, so return-value explanation is not required, and the tool is a simple single-param read. However, the description leaves pixel_id semantics and the source of authoritative pixels unexplained, which an agent would need to call it confidently.

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 parameter pixel_id has no description anywhere. The description does not say where pixel_id comes from, its format, or what happens if it is unknown — it fails to compensate for the coverage gap, though one required id param keeps the impact limited.

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

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

States a specific verb+resource ('Read one pixel') and implicitly distinguishes itself from the sibling audience_list_pixels by scope (one vs. many). The trailing phrase 'by filtering the documented authoritative pixel list' is unusual and slightly muddles the operation, but the core purpose is clear.

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

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

Usage is only implied: the singular 'one pixel' signals this is a by-id lookup rather than a listing, so an agent can infer it belongs after user has an id. But no explicit when-to-use, when-not, or prerequisite (e.g. 'use after audience_list_pixels') is stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds only a hint that retrieval is a filter over the authoritative segment list, implying a deterministic read with no side effects, but discloses nothing about behavior on missing/invalid ids or result shape.

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

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

A single short sentence with the action and scope front-loaded; nothing is padded. The phrasing 'documented authoritative segment list' is slightly redundant, keeping it just short of a 5.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The gap is provenance of the id and the sibling relationship to audience_list_segments, which the description leaves unaddressed for a lookup 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?

One parameter with 0% schema description coverage and no enum, so the schema gives only a name and integer type. The description does not explain where segment_id comes from, its expected form, or its relationship to the ids returned by audience_list_segments, leaving the parameter effectively undocumented.

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 (Read) and resource (one segment), scoped to a single item, which implicitly distinguishes it from audience_list_segments. The trailing phrase about 'filtering the documented authoritative segment list' is odd but does not obscure the core purpose.

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 when-to-use, when-not, or named alternative. The agent must infer that this is the single-item counterpart to audience_list_segments; nothing states that segment_id must come from that list, nor what happens when the id is unknown.

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 adds a genuine behavioral detail beyond them — the result set is scoped to credential visibility — but says nothing about pagination, ordering, or result volume, which matters for an unspecified-size listing.

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

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

A single sentence with the resource name and the scope constraint front-loaded. No filler, no restatement of the title, every clause carries information.

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

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

An output schema exists so return values need not be described, and annotations carry the safety semantics. Purpose and scope are covered for a no-argument list tool; only routing guidance relative to sibling list/get tools is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The credential-visibility note functions as an implicit scoping rule for results rather than a 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?

States a specific verb (List) and resource (Audience tracking pixels), which distinguishes it from audience_get_pixel (single-pixel retrieval) and audience_list_segments (different resource). It does not explicitly name those siblings, but the verb+resource combination is 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 clause 'visible to the server-side credential' scopes when results apply, implying this is an enumeration call for the authenticated account. However, it never states when to prefer it over audience_get_pixel or audience_list_segments, leaving 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and purity profile is fully covered by structured data. The description's only added behavioral fact is that results are scoped to the server-side Audience credential, which is useful but thin given a zero-parameter, no-side-effect call.

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

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

A single sentence with no filler, and the resource and scope are front-loaded. It stays within budget for a no-argument list call, though the brevity borders on being too sparse to guide an agent.

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 an output schema present, return values need no explanation, and with zero parameters the schema burden is nil; annotations cover safety. The only real gap is the absence of any cue about result volume, pagination, or relationship to audience_get_segment, which is minor for a simple low-complexity list 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 baseline of 4 applies; there is no parameter syntax for the description to document. Schema coverage is reported at 100% and the empty object schema is unambiguous.

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 (List) and resource (Audience segments), and adds a real scope qualifier: visibility is limited to what the server-side Audience credential can see. That distinguishes it from sibling readers like audience_get_segment and audience_list_pixels, though it does not name those siblings explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives (e.g., use audience_get_segment for a single segment). The credential-scope phrase implies the tool returns everything visible rather than a filtered subset, but that is inference, not stated 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 idempotentHint=true and destructiveHint=true, so the safety profile is covered. The description adds genuinely new behavior: a read-back after the write, and that replaying the same key returns the stored result rather than re-executing. It still does not say what the write destroys or what authorization the approval_id carries.

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

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

Front-loaded with the verb and kept to three short fragments. The trailing 'Writes.' is largely redundant with the first sentence, but overall there is little waste for a terse mutation 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?

An output schema exists, so return values need not be explained. For a destructive, 4-param mutation with 0% schema coverage, though, the description omits what operation does and what args contains, leaving gaps an agent must guess at before invoking.

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% for 4 parameters, so the description must carry the semantics. It names approval_id and idempotency_key and hints at a 'write flag' for operation, but never explains what operation accepts or what the args object carries. The primary payload parameter is left completely ambiguous.

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: executing an accepted Audience write once, with the read-back follow-up. This distinguishes it from audience_manage_prepare (which stages the write), though it does not name that sibling explicitly. The purpose is clear without opening the schema.

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

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

The word 'accepted' and the required approval_id imply this is the apply step after a prepare/approval flow, so usage context is implied. However, it never explicitly says when to use this versus audience_manage_prepare or audience_manage_reconcile, leaving the agent to infer the workflow.

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 readOnlyHint=false and destructiveHint=false already given, the description adds genuinely useful behavioral context: the approval is 'Bound to principal, account and exact request' and 'nothing is sent'. That dry-run scope is non-obvious and cannot be inferred from the annotations, which would otherwise leave the safety profile ambiguous.

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

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

A single dense sentence with the core action front-loaded and the safety constraint after a semicolon. No filler; every clause carries information.

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

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

An output schema exists, so return values need not be described, and the annotations cover the mutation profile. However, for a two-phase-commit entry point the description omits the approval lifecycle (what happens after, which tool applies it) and the operation vocabulary, leaving gaps an agent must guess at.

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 carry the parameter meaning. It partially does by listing the arg keys ('ids, query, body, csv'), but the required 'operation' parameter and its allowlisted values are never explained, leaving the required field undocumented in both schema and description.

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 pairs a specific verb with a specific resource: 'Open an approval for one allowlisted Audience write/upload'. This tells the agent it stages a request rather than performing it, distinguishing it in spirit from the apply/reconcile siblings. It stops short of explicitly naming the sibling tools it hands off to.

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 explicit statement of when to use this versus audience_manage_read, audience_manage_apply, or audience_manage_reconcile. The prepare/apply pattern is only implied by the word 'approval'. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so 'Read-only' in the text is redundant. The one piece of added behavior is that the 'catalog' operation resolves locally, which tells the agent a discovery call costs no network round-trip.

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 terse sentences, front-loaded with the dispatch model and followed by the discovery hint. Dense and mostly waste-free, though the telegraphic 'args = path ids, query{...}' phrasing is cryptic enough to cost readability.

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

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

An output schema exists so return values need no explanation, and the 'catalog' operation covers operation-name discovery. However, for a dispatcher over a large surface, the description gives no sense of scope or which operations exist, leaving the agent dependent on an extra discovery call before it can act.

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 'operation' is an unconstrained string with no enum, so the description carries the burden. It does explain that args holds path ids plus a query{...} object and that operation='catalog' enumerates valid names, which is useful, but the actual operation-name vocabulary and arg shapes remain undiscoverable without a prior call.

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 domain (Audience management/report reads) and the mechanism (dispatch by operation name), but never states concretely what is read — no resource list, no example operation beyond 'catalog'. It distinguishes itself from audience_manage_prepare/apply/reconcile only implicitly through the word 'Read'.

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 hints at a discovery workflow by noting operation='catalog' lists all operations with docs, which is real usage guidance, but it never says when to use this tool versus audience_manage_prepare/apply/reconcile or the direct audience_list_* / audience_get_* siblings. Usage is implied rather than stated.

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

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

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds real value beyond them by explaining the mechanism: it settles state by reading the provider rather than retrying the write ('never resends'). That is a behavioral trait an agent cannot derive from the annotations alone.

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

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

A single compact sentence that front-loads the action and mechanism with no filler. It is efficient, though the extreme terseness leaves the reader to unpack 'uncertain' and 'settle'.

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

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

An output schema exists so return-value semantics need not be described, and the annotations cover the safety profile. The remaining gap is parameter documentation (0% coverage) and the absence of explicit routing among the several sibling reconcile/apply tools, leaving the definition minimum-viable rather than 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 none of the three parameters ('operation', 'idempotency_key', 'args') are mentioned or clarified in the description. For a tool requiring an idempotency_key, the description offers no explanation of how the key is used or what 'operation' should contain, so it fails to compensate for the coverage gap.

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 ('settle') and resource ('an uncertain Audience management write') plus the mechanism ('by reading the provider'). This clearly separates it from the prepare/apply siblings and from the webmaster_/metrika_ variants of the same reconcile pattern. It stops short of naming an alternative sibling 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?

'Settle an uncertain ... write' implies the usage context (a prior write whose outcome is unknown), which is reasonable guidance. However, no explicit when-to-use condition, prerequisites, or alternatives (e.g. audience_manage_apply, audience_reconcile_create) are named, so the agent must infer the trigger.

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 non-read-only, idempotent, non-destructive, open-world. The description adds one genuinely useful behavioral fact: it does not emit another POST, so it avoids duplicate side effects. It does not explain what state the operation requires (a previously pending create) or what it mutates, so the added value is real but thin.

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

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

A single front-loaded sentence with no filler; the key constraint ('without sending another POST') appears immediately. Brevity here tips into under-specification rather than verbosity, but structurally it is efficient.

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

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

An output schema exists, so return values need not be described, but for a mutating, open-world tool with 0% parameter coverage and a required nested payload object, the description leaves too much unanswered about what to supply and what state must exist first.

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% across three required parameters (payload is a free-form nested object), so the description must carry the load, and it does not. It references a 'saved object id' that corresponds to no declared property, leaving operation, payload and idempotency_key entirely 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?

States a specific verb ('reconcile') and resource ('one owned pending create'), which separates it from generic siblings like audience_manage_reconcile. However, 'reconcile a pending create' is jargon that leaves the actual effect on the saved object unclear, and the phrase 'by saved object id' does not map cleanly to any declared parameter, so an agent cannot be fully confident what it does.

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 clause 'without sending another POST' implies the intended situation: resolving an uncertain/duplicate create instead of re-issuing it. That is useful implied routing, but there is no explicit when/when-not and no named alternative (e.g. vs audience_manage_reconcile or audience_validate_create).

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 openWorldHint=false, so the safety profile is covered structurally. The description's own additions ('offline', 'immutable confirmation hash') largely restate what openWorldHint=false and the existing output schema already convey, so it adds only marginal new context.

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

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

A single dense sentence with the verb and outcome front-loaded and no filler; nothing to trim.

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

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

For a two-parameter, nested-payload validation step, the agent still lacks the allowed 'operation' values, the expected payload shape, and where the resulting hash is consumed downstream. The presence of an output schema excuses it from describing return values, but the input-side and workflow gaps are significant.

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% for both required parameters, and the nested 'payload' object is opaque with additionalProperties=true. The description says only 'Audience create payload' and says nothing about the 'operation' parameter or what keys the payload must contain, so it fails to compensate for the coverage gap.

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 (validate) and resource (Audience create payload) plus the result (confirmation hash), so the agent knows this does not create anything. It does not, however, distinguish itself from nearby siblings like audience_create_geo_circle, audience_reconcile_create, or audience_manage_prepare.

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?

'Validate ... offline' implies this is a pre-flight check before a create/reconcile step, which is usable guidance. But no explicit when-to-use, no statement of which create tool's payload this validates, and no mention of the alternative paths (audience_reconcile_create, audience_manage_prepare).

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 the write/idempotent/destructive/openWorld profile, but the description adds real value beyond them: 'exactly once', a re-read verification step, that it 'spends units', and that it fails closed without approval. The only gap is that cost magnitude and rollback behavior on partial failure are not described.

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

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

A single dense sentence followed by two short constraints; the trigger, key parameters, and failure mode are all front-loaded with no filler. Every clause carries information.

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

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

For a destructive, idempotent write with an output schema (so return values need no explanation), the description covers trigger, gating, cost, and verification. The unexplained `service`/`method` params keep it from being fully self-sufficient.

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 carry parameter meaning, and it only partly does: it tells the agent that approval_id gates the operation and idempotency_key enforces exactly-once, and hints 're-reads campaigns' relates to campaigns. The required `service` and `method` parameters are left entirely 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?

States a specific verb (Apply) and resource (an accepted Direct change set) and explicitly names the upstream producer, `direct_prepare_changes`. This cleanly separates it from its prepare sibling and from the generic `direct_write`/`direct_apply_write` group.

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 trigger context: the change set must come from `direct_prepare_changes` and be operator-approved, and 'Fails closed without approval' states a refusal condition. It does not, however, differentiate itself from the sibling `direct_apply_write`, so a routing agent still has an ambiguity to resolve.

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=false, destructiveHint=true, and idempotentHint=true, so the description's 'Same key replays the stored result' largely restates idempotency. It does add one genuine trait beyond annotations: 'spends units' discloses a billing/cost dimension, and 'then read back' hints at sequencing. It says nothing about what a destructive execute actually changes or what authorization is needed.

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, front-loaded sentences with no filler: the action comes first, then replay semantics, then the cost warning. Compact and readable, though the parenthetical parameter list and the dangling 'write flag' mention add slight ambiguity rather than clarity.

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

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

An output schema exists, so return values after the read-back need not be explained. But for a destructive, open-world, five-parameter mutation that spends units, the description is thin: it omits the meaning of service, method, and items, does not describe what gets mutated, and does not fully explain the prepare-to-apply handoff relative to 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%, so the description carries the full burden of explaining five required parameters. It names only approval_id and idempotency_key (plus an ambiguous 'write flag'), leaving service, method, and items completely undocumented in both schema and description. The partial naming of two of five required fields is inadequate compensation.

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: execute an accepted Direct write once, then read back. The word 'accepted' signals this is the commit half of a prepare/apply pair, and 'then read back' clarifies the post-write behavior. It does not differentiate itself from the closely related siblings direct_write, direct_apply_changes, or direct_prepare_write, 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?

Mentioning 'an accepted Direct write' and requiring approval_id implies a prior prepare/approval step, and 'Same key replays the stored result' implies retry safety. However, it never explicitly says when to use this tool versus direct_prepare_write, direct_write, or direct_apply_changes, nor what constitutes an 'accepted' write. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description's 'Read-only' is largely redundant. It does add the timestamp format expectation (UTC ISO, Z) and the incremental-sync framing, which is modest but real value beyond 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?

Front-loaded with the core question ('what changed') followed by method enumeration and the one usage rule. Compact with little waste, though the parenthetical method glosses are dense.

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

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

An output schema exists so return values need no explanation, but for a 6-parameter, 0%-documented tool the description is only partially complete: the id/field parameters remain undocumented, leaving the agent to infer which combinations are valid.

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% across 6 parameters, so the description carries the full burden. It explains the method enum values (checkCampaigns/check/checkDictionaries) and the timestamp format, but leaves ad_ids, campaign_ids, ad_group_ids and field_names entirely unexplained, including which ids pair with which method.

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

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

States a specific resource ('what changed in Direct since timestamp') and enumerates the three Changes methods, so the agent knows this is a changes/delta query, not a full listing. It does not name a sibling tool to differentiate against, but the verb+resource is 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?

Gives one clear usage rule ('use for incremental sync instead of re-reading everything') but no explicit tool alternatives and no guidance on which method or id parameter to pick for a given task. Usage is implied rather than fully specified.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the 'Read-only' tail adds little. What does add value is the disclosed limit of 'up to 10000 phrases' and the guarantee that 'nothing is saved', which are concrete behavioral constraints not present in the annotations. It still says nothing about failure modes when the limit is exceeded.

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 with the core action front-loaded and the constraints trailing; nothing is padded. The trailing 'Read-only' is redundant with the annotations but costs only a few words.

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

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

An output schema exists, so return values need no explanation, and the size/save guarantees are covered. The gap is the undocumented operations parameter and the absence of any detail on how cross-negatives are generated, which leaves the tool's transformation behavior only partially specified.

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%, so the description must compensate, and it largely does not. The 'phrases' wording loosely maps to the keywords array, but the 'operations' parameter (array of strings or null, no enum, no description) is entirely unexplained — an agent has no idea what operations are accepted or what omitting it does.

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 gives a specific verb and resource: it merges duplicate phrases and adds cross-negatives to keywords. No sibling tool in the list performs deduplication, but it never names an alternative or counterpart, so it falls short of full sibling differentiation.

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 'before adding keywords' implies this is a pre-processing step in a keyword-creation workflow, which is a genuine usage cue. However, there is no explicit when-not guidance, no prerequisites, and no named alternative tool for agents weighing this against other keyword tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so 'Read-only' is largely redundant. The description does add useful domain context by naming the supported levels (CAMPAIGN, AD_GROUP) and the kinds of adjustments, but says nothing about pagination behavior or the default limit of 1000 that govern result size.

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

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

A single dense sentence with the resource and key constraint front-loaded and no padding. The ellipsis in '(mobile, demographics, retargeting, regional...)' is slightly loose but keeps it compact.

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

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

An output schema exists, so return values need no explanation, and the description identifies the entities and levels. It still omits pagination/default-limit guidance for a tool exposing limit and offset, leaving a minor gap for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the burden, and it partially does: 'levels CAMPAIGN, AD_GROUP' documents the levels parameter values, and 'by campaign/group/id' maps to campaign_ids, ad_group_ids, and ids. However, limit and offset — the pagination controls — are never explained, leaving two parameters undocumented.

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

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

States a specific resource (bid adjustments) with concrete examples of adjustment types and the entities it operates on (campaign/group/id) plus the levels it supports. It is clearly a read operation, though it does not explicitly distinguish itself from the sibling direct_get_bids, which an agent could plausibly confuse it with.

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 indication of when to use this tool versus alternatives such as direct_get_bids, direct_get_campaign, or direct_get_statistics. The only usage signal is the trailing 'Read-only', which is a capability note rather than routing 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 readOnly/idempotent/openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: the one-of selector requirement and the non-obvious unit convention ('Monetary values are micros (×1e6)'). 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?

Compact and front-loaded: the constraint and unit convention come early with no filler. The 'Bids.get:' prefix is slightly API-jargon but harmless.

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

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

An output schema exists so return values need no explanation, but for a 6-param tool with 0% schema coverage the description omits pagination (limit/offset) and the include_auction toggle, and offers no sibling differentiation. Adequate but with clear gaps.

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 carry the load, and it documents only 3 of 6 params (the three id arrays and their one-of rule). The limit, offset, and include_auction parameters are left entirely unexplained, so it only partially compensates.

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 ('Bids.get: current Bid/ContextBid plus optional search auction fields for keywords'), which tells an agent it retrieves bid data. However, it does not distinguish itself from the sibling 'direct_get_keyword_bids', which sounds like it covers a similar area.

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 provides one genuine usage constraint ('One of campaign_ids, ad_group_ids, keyword_ids required') and notes read-only, but gives no guidance on when to prefer this over alternatives like direct_get_keyword_bids or direct_get_bid_modifiers.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is fully structured. The description adds essentially no behavioral context beyond that—no error behavior, auth requirements, or retrieval constraints.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for a simple one-parameter get operation.

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 the simple operation, rich annotations, and existence of an output schema, the description is close to complete. A minor gap remains because it does not explain where campaign ids come from, but the core invocation need is covered.

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 carry parameter meaning. It says the campaign is identified by a 'numeric id', which aligns with the integer campaign_id parameter but provides no additional detail such as how to obtain the id or what format is expected.

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 resource ('one Direct campaign'), and the phrase 'one ... by numeric id' distinguishes it from list-style siblings such as direct_list_campaigns. It does not explicitly name alternatives, but the purpose is immediately clear.

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 explicit guidance about when to use this tool versus alternatives like direct_list_campaigns or other direct_get_* tools. The single known-id retrieval use case is implied, but no conditions, prerequisites, or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' adds nothing new. What the description does add beyond annotations is the content boundary (no phones or representatives) and the underlying call (Clients.get), which heads off expectation mismatch on the returned fields.

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

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

Two tight, front-loaded sentences with no filler; scope comes before the sibling pointer. Minor waste in 'via Clients.get' and the redundant trailing 'Read-only.' which duplicates the annotation.

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-argument getter with an output schema and full annotation coverage, the description supplies everything an agent needs: what is returned, what is excluded, and where to go for the agency case.

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 input parameters, so the baseline is 4; the description correctly spends no space on parameter syntax. The field names it quotes are outputs, not inputs, and the output schema is separately available.

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?

Names a specific verb+resource ('Own Direct account info') and enumerates the return payload (Login, ClientId, currency, type), which lets an agent tell it apart from the many direct_list_*/direct_get_* siblings. The scope qualifier 'Own' and 'via Clients.get' pin down exactly which client record is returned.

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 routes the agent explicitly: agencies should use `direct_list_agency_clients` instead, and it states what this tool will not return (phones/representatives). This is the same when/when-not/alternative pattern as a top-tier definition.

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 'Read-only' in the description is largely redundant. The genuine added value is the 'GeoRegions is large' size warning. Nothing is said about caching, volume of returned data, or how names are resolved, so the disclosure remains thin.

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 fragments, no padding, with the resource list and the usage rule front-loaded. Slightly elliptical in places (no explicit verb, fragment-style sentences), but every clause carries information.

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

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

An output schema exists, so return-shape explanation is not required. For a one-parameter, read-only dictionary lookup with full annotation coverage, the description supplies purpose, workflow context, and a size caveat, leaving mainly the parameter format unspecified.

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 'names' array parameter is never mentioned by name; the parenthetical dictionary list implicitly hints at valid values but does not state that it is the accepted input, nor whether it is case-sensitive or batched. It partially compensates for the coverage gap but does not fully document the 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?

States the resource (reference dictionaries) and enumerates the concrete dictionaries returned (Currencies, GeoRegions, TimeZones, Constants, Interests, AdCategories). The verb is implied rather than stated, but an agent can immediately tell this is a read of static reference data, distinct from the many list_* siblings that return user-owned entities.

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

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

Explicitly gives the use case: 'Use for region ids/min bids before forecasts or writes,' which ties it to the forecast/write workflow. It also warns that 'GeoRegions is large,' which is a useful narrowing caveat. No competing sibling is named, but there is no direct alternative dictionary tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new context beyond them: the 1-10 goal limit and the output column naming convention <Field>_<GoalId>_<Model>. It omits return-shape and pagination details, hence not a 5.

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

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

Three tight clauses, front-loaded with the verb+resource and breakdown scope, then routing guidance, then the column-format hint. The only redundancy is 'Read-only', which repeats an annotation, but it costs almost nothing.

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

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

An output schema exists so return values need not be described, and the goal/model semantics are covered. However, for an 8-parameter tool with 0% schema coverage, the missing date-format, row_limit, report_type, and campaign_ids guidance leaves a real gap.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and only partially does. It meaningfully explains goals (1-10) and attribution models, but leaves date_from/date_to format, row_limit, field_names, report_type, and campaign_ids undocumented.

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 (get) and resource (goal statistics from Direct Reports) and scopes it to breakdowns by Metrika goals and attribution models. It explicitly distinguishes itself from the sibling direct_get_statistics, so an agent can select it without opening either schema.

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

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

Gives an explicit when-to-use (CPA/ROI by goal) and names the alternative for the plain case (direct_get_statistics for cost/clicks). The selection condition is unambiguous rather than inferred.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds one genuinely useful behavioral fact: operations are constrained to an explicit allowlist, meaning non-allowlisted services will be rejected. It does not say what happens on an allowlist miss or whether output mirrors the provider shape.

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

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

A single front-loaded sentence with no filler, but it is too terse for a nested, two-required-parameter passthrough tool. Concision is achieved at the cost of substance rather than by eliminating waste.

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

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

An output schema exists so return values need no explanation, but the tool has two required parameters, a nested free-form object, and 0% schema coverage, and the description does not explain valid services, param shapes, or a usage example. For this complexity level it leaves the agent without enough 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 description coverage is 0% and both parameters are generic and undocumented ('service' string, 'params' free-form object with additionalProperties). The description's mention of an 'explicit allowlist' hints that 'service' is constrained but never enumerates valid values or explains how 'params' maps to the provider call, so the compensation required at 0% coverage is absent.

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 phrase 'provider-native get against the explicit Direct inventory allowlist' largely restates the tool name in jargon rather than naming a concrete resource. It implies a passthrough read restricted to a whitelist of Direct services, but an agent cannot tell what objects it actually returns.

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 this instead of the many typed siblings (direct_list_campaigns, direct_get_campaign, direct_get_statistics, etc.). The only hint is the 'allowlist' framing, which weakly implies a raw escape hatch, but no alternative is 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?

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so safety is covered and 'Read-only' adds nothing new. The description's genuinely additive detail is the one-of-these-ID-filters constraint, which the schema does not encode; it says nothing about pagination behavior or result caps.

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?

Tight, front-loaded sentences with no filler; scope comes first, then mutation and sibling routing. The telegraphic 'Auction data: `direct_get_bids`.' fragment is slightly cryptic but still 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?

With an output schema present it need not describe return values, and annotations cover the safety profile. The critical gap it does fill is the required-one-of rule that the schema (0 required params) fails to express; the only shortfall is unaddressed pagination semantics.

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 carries the burden: it names the three ID filter arrays and their exclusivity rule, which is the most important parameter semantic here. It says nothing about limit/offset (500/0 defaults), leaving a fifth of the parameters undocumented in prose.

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 ('Current keyword bids and serving status') plus the exact scoping keys CampaignIds/AdGroupIds/KeywordIds. It explicitly separates itself from the near-name sibling direct_get_bids ('Auction data'), so an agent can pick correctly without opening 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?

Gives the selection rule ('one required' among the three ID types), routes bid modification to `direct_write` service=bids, and routes auction-price lookups to `direct_get_bids`. Both when-to-use and explicit alternatives are present.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds one useful behavioral fact beyond that: it may return either completed TSV rows or an offline queue status, hinting at an asynchronous path. However, this is cryptic and leaves unclear when queuing occurs or how to retrieve queued results.

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

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

A single front-loaded sentence with no padding. The trailing clause is terse but introduces an ambiguous term ("safe offline queue status") that slightly undermines clarity, though the size itself is appropriate.

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

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

An output schema exists so return values need not be explained, but for a 5-parameter tool with 0% schema coverage and no usage guidance, the description is far too thin. It neither compensates for the undocumented parameters nor clarifies how this differs from the several sibling statistics 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% across 5 parameters. date_from/date_to are self-evident, but field_names, report_type (with its CUSTOM_REPORT default), and campaign_ids have no schema descriptions and no explanation in the description either, so the agent cannot know valid values or semantics for these.

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?

"Read campaign statistics" names a clear verb+resource, but the second clause ("returns completed TSV rows or safe offline queue status") muddies scope and implies an async/offline queue mechanism. It does nothing to distinguish this from siblings like direct_get_goal_statistics or metrika_get_statistics, which an agent must disambiguate by name alone.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as direct_get_goal_statistics or metrika_get_statistics. The agent is left to infer applicability from the name only.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds that output is a forecast broken down by device and region, but says nothing about latency, quota, or what 'search-volume presence' actually returns beyond the output schema.

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

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

A single well-formed sentence with the verb and resource front-loaded and no filler. It is appropriately sized, though the extreme brevity is partly the cause of the missing detail rather than a virtue.

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

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

An output schema exists so return values need not be re-explained, but for a forecasting tool with zero schema description coverage and 2 required params, the description is too thin: it omits what region_ids refer to, any phrase limits, and the significance of the device dimension in the output.

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 carries the burden but only echoes the parameter names conceptually ('phrases', 'regions'). It does not explain that region_ids are numeric identifiers (and where to obtain them), how many phrases are allowed, or any format constraints, so it fails to compensate for the coverage gap.

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 (forecast) and resource (search-volume presence), plus the two dimensions of granularity (device, region) and the input units (phrases, regions). An agent can distinguish it from wordstat volume lookups, though it never names a sibling alternative explicitly, 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as the regional/volume tools (yandex_wordstat_get_top, yandex_wordstat_regions) that an agent might confuse this with. The agent must infer usage purely from the one-line 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the description's "Read-only" merely restates structured data. It adds nothing about pagination behavior (limit defaults to 500), response size, or rate limits for a listing tool, so no new behavioral context is supplied.

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 very short and front-loads the resource, with the sibling pointer kept brief. The parenthetical "(Id, Type, Status, text)" is of questionable value given an output schema exists and its meaning is unclear, but overall there is no 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?

The output schema covers return values, so those needn't be explained, but for a list tool with three entirely undocumented parameters the agent is left without knowing the default page size or how to filter by ids. Combined with no usage context, the definition is under-specified for correct invocation.

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

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

Schema description coverage is 0% for all three parameters (ids, limit, offset), and the description does not compensate — it never explains that ids filters to specific extensions or how limit/offset paginate. The parenthetical field list reads like output fields rather than the actual arguments, adding no real meaning.

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 (callout extensions) and explicitly routes sitelinks queries to the sibling `direct_list_sitelinks`, so the agent can distinguish the two. The listing verb itself lives only in the tool name, and the parenthetical "(Id, Type, Status, text)" is ambiguous about whether those are return fields or filters, keeping it 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?

"Read-only" plus the sitelinks pointer imply this is a query tool for callout extensions and give one alternative, but there is no explicit when-to-use, no condition for choosing this over other direct_list_* tools, and no mention of prerequisites. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the "Read-only" sentence is largely redundant with structured data. The one genuinely added behavior is the 10,000-item cap on the hashes input, which is useful context; no pagination or result-shape behavior is described.

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?

Compact and front-loaded with the resource and returned fields, with no wasted sentences. However the dense "AdImages.get:" notation and comma lists trade away readability for brevity, reading as under-specified rather than crisply concise.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile. What remains missing is the semantics of the limit/offset parameters against a 0% schema coverage gap, which is a meaningful omission for a paginated listing 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 carries the full burden, yet it only touches two of four parameters (hashes with its ≤10000 cap, and associated with YES/NO). The limit (default 500) and offset (default 0) parameters — critical for pagination — are never mentioned, leaving the schema silent and the description incomplete.

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

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

States a specific verb+resource ("AdImages.get: uploaded ad images") and even enumerates the returned fields (hash, name, type, subtype, associated), so an agent knows it lists image assets. It is readily distinguishable from the sibling direct_list_ad_videos by the resource noun, though it never explicitly contrasts with it or other list_* siblings.

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

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

The description implies how to narrow results ("Optional hashes (≤10000) or associated YES/NO"), giving filter semantics but no explicit when-to-use vs alternatives or when-not conditions. Usage is largely self-evident from listing images, but no alternative tool is named or routed to.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the trailing 'Read-only.' merely repeats structured data and earns no credit. No additional behavior is disclosed (no note on pagination limits, result ordering, or what happens when ids are omitted despite the API-required claim).

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 clauses, front-loaded with the resource and no filler. Its sparseness is a completeness problem rather than a verbosity one, so it scores well here.

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

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

An output schema exists, so return values need not be explained, but a listing tool with pagination params and an unclear ID requirement needs more than one cryptic sentence. The '(required by the API)' note conflicts with a schema where ids is nullable, defaults to null, and no parameters are required, leaving the agent unsure how to call it.

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 carry the parameter burden. It only touches 'ids' (claiming they are API-required, which usefully nuances the schema's default null) and says nothing about 'limit' or 'offset', so pagination behavior is undocumented in both places.

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 (ad videos) and the key dimension returned (status), but the verb is implied rather than stated and the phrase 'Ad video status by video Ids' reads awkwardly. Against a sibling set full of 'direct_list_*' tools (ad_images, creatives, ad_extensions), it does not clearly distinguish itself as the video-specific lister.

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 when-to-use guidance and no alternatives are named. The only hint is the parenthetical '(required by the API)', which gestures at an input requirement but never says when an agent should pick this tool or what it should pick instead.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new context: it is agency-token scoped and has an explicit cost ('10 units + 1/client'), which helps an agent budget the call.

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

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

Front-loaded with the core purpose and resource, then the auth constraint and cost. Dense but no filler sentences; the parenthetical field list is the only mildly expendable element.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. With auth scope and pricing conveyed, the remaining gap is the undocumented pagination/filter parameters, which is a modest omission for a list 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 carry parameter meaning. It clarifies how the login value should be used, but limit, offset, and archived receive no explanation at all, leaving three of four parameters undocumented.

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 (List) and resource (an agency's Direct clients), enumerates the returned fields (Login, ClientId, ClientInfo, Currency), and even names the underlying API method. It is clearly a bulk-list operation, though it does not explicitly contrast itself with the sibling direct_get_client.

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

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

Provides a concrete gating condition ('agency tokens only') and explains how to supply the Login (as YANDEX_DIRECT_CLIENT_LOGIN). This tells the agent when the tool is applicable, though it never names an alternative tool for the non-agency case.

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, so the trailing 'Read-only' adds no new information. Nothing is said about pagination defaults, result volume, or the shape/limits of the listing, so the description contributes essentially no behavioral context beyond 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 short sentences, front-loaded with the resource and scope, with zero filler. The trailing 'Read-only' is redundant given the annotations, which is the only wasted clause.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. But for a 5-parameter, unfilterable-required listing tool, the description omits pagination behavior, filtering semantics, and any usage routing, leaving it only minimally sufficient.

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% across 5 parameters, so the description must carry the load; it does identify the three ID-based filters (ids, ad_group_ids, campaign_ids), which is real added meaning. However, the limit/offset parameters and the mutual exclusivity or combination rules between the ID families are left completely 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 names the resource (audience targets / retargeting-interest targets) and the three ID families used to scope the listing, so an agent knows what it returns. It does not differentiate itself from similarly named siblings such as direct_list_dynamic_feed_ad_targets or direct_list_smart_ad_targets, which is the only gap.

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 when-to-use statement, no prerequisite, and no named alternative. The only guidance-adjacent text is 'Read-only', which is a trait rather than a usage condition, leaving the agent to infer when this listing should be preferred over the other audience/target list tools.

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, and 'Read-only' in the description merely repeats that. The only added behavior, that Phone/Address are omitted by default, implies an include-switch that the schema does not actually expose, so it borders on misleading with no pagination or auth context.

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

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

It is short and front-loads the resource and fields, which is good. But the brevity is under-specification rather than economy: whole sentences are missing on inputs and paging for a tool that has three unfiltered-when-omitted parameters.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What is missing is any guidance on the three inputs or pagination behavior, leaving an agent unable to use ids/limit/offset correctly from the definition alone.

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?

Three parameters (ids, limit, offset) exist at 0% schema description coverage, and the description mentions none of them — not the meaning of ids filtering, not the default limit of 500, not offset paging. The description describes the response entity rather than the inputs, so it fails to compensate for the coverage gap.

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 (Yandex Business profiles) and enumerates the returned fields (Id, Name, IsPublished, Rubric), so the agent knows roughly what comes back. However, the verb is only implied by the tool name, and there is no differentiation from the many other direct_list_* siblings. Adequate but not sharp.

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 this tool, when not to, or which sibling to prefer for related queries. The 'no Phone/Address by default' clause hints at scope but never tells the agent when this listing is the right call.

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 structurally. 'Strict read allowlist' adds a mild guardrail nuance beyond the annotations but does not disclose pagination, result volume, or whether selection_criteria narrows results server-side.

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

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

A single short sentence with the resource front-loaded and no padding. The phrase 'strict read allowlist' is slightly jargon-y for the space it occupies, 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?

An output schema exists so return values need not be described, but the description leaves the only input parameter's format and semantics unexplained, and gives no guidance on scope or usage. For a tool whose sole filter is schema-opaque, this is under-specified.

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 is one parameter, selection_criteria, with 0% schema description coverage and a free-form object type, yet the description says nothing about its expected shape or meaning. With no params the baseline would be 4, but here the sole undocumented parameter is left entirely opaque.

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 ('List Direct campaigns'), which is unambiguous and clearly distinct from the singular sibling direct_get_campaign. However, it never names or contrasts with that sibling, so the differentiation is implicit rather than stated.

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 when-to-use guidance, no mention of when to prefer this over direct_get_campaign or the other Direct list tools, and no stated prerequisites or conditions. The only implicit hint is the read-only framing.

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, and openWorldHint=true, so the appended 'Read-only' is redundant. The description adds no behavioral context beyond the annotations (no pagination behavior, no rate limits, no auth needs).

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?

Extremely compact and front-loaded, with no filler. It reads as a fragment rather than a sentence, but every token is informational and nothing is buried.

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

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

An output schema exists, so return fields need not be re-explained, and annotations cover the safety profile. The remaining gap is significant: zero parameter documentation and no usage guidance for a tool with three exposed parameters.

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% for all three parameters (ids, limit with default 500, offset), and the description explains none of them. The conventional names make them partially guessable, but the default page size of 500 and the ids filter semantics are left entirely undocumented.

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?

Names the resource (creatives) and enumerates the subtypes it covers (image/HTML5/video/smart), plus the fields returned (Id, Type, Name, size). It is clearly a listing tool, though the verb itself is only implied by the name and there is no differentiation from siblings like direct_list_ad_images or direct_list_ad_videos.

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 this tool versus the many other direct_list_* siblings, no prerequisites, and no mention of what ids/limit/offset are for. An agent must infer usage entirely.

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, and openWorldHint=true, so the trailing "Read-only." adds nothing new. The description does not disclose pagination behavior (limit/offset), result ordering, or open-world scope beyond what annotations state, leaving the behavioral picture thin.

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, and the resource is stated first. It is efficient, though bordering on under-specified rather than wasteful.

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 an output schema present, return values need not be explained, and annotations cover the safety profile. Still, 0% parameter coverage plus near-identical siblings mean the description should do more to explain filters and disambiguate; it is barely adequate.

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 carries the full burden. It loosely maps campaign/ad_group/ids to the campaign_ids, ad_group_ids, and ids parameters but gives no array semantics, no mention of limit/offset, and no defaults, leaving two of five parameters undocumented in both places.

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 (DynamicFeedAdTargets) and the filtering dimensions (campaign/group/id), so an agent knows it lists dynamic feed ad targets. However, "Dynamic feed ad filters" is slightly ambiguous about whether it lists filters or targets, and it never distinguishes itself from the near-identical siblings direct_list_smart_ad_targets and direct_list_dynamic_text_ad_targets beyond the entity name in parentheses.

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 stated when-to-use or when-not-to-use guidance. Given three sibling tools that list different ad-target types, the description should route the agent to the correct variant, but it offers no comparison or condition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read-only' merely repeats structured data. No added context is given about pagination behavior (limit/offset exist), auth needs, or default result size, so beyond the annotations it contributes almost nothing.

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 fragments, purpose front-loaded before the safety note, with no filler. It is efficient, though the extreme brevity is also what leaves the usage and parameter gaps.

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

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

An output schema and rich annotations are present, so return format and safety profile need not be restated. Yet for a 5-parameter listing tool with 0% schema coverage, the description omits pagination semantics and how multiple filters combine, leaving it only minimally viable.

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%, so the description must carry parameter meaning. It names three of the five filters (campaign/group/id), loosely mapping to campaign_ids, ad_group_ids, and ids, but gives no format or semantics for them and completely omits limit and offset.

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 (list) and resource (dynamic text ad targeting conditions) with filter dimensions, so the agent knows what it retrieves. However, it does not distinguish itself from the nearly identical sibling direct_list_dynamic_feed_ad_targets, leaving ambiguity about which variant applies.

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 'by campaign/group/id' implies the tool is used to scope targets to specific campaigns, ad groups, or IDs, giving some usage context. But there is no explicit when-to-use vs when-not guidance and no routing to the sibling feed-targets tool, so the agent must infer the choice.

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, and openWorldHint=true, so the description's 'Read-only' merely restates them and adds no new behavioral context. It says nothing about pagination behavior, filtering scope, or rate limits beyond the structured hints.

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 two-word-plus-fragment format is extremely compact and front-loaded with the resource. It is efficient, though the brevity is part of the under-specification problem rather than a virtue.

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

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

An output schema exists, so return values need not be explained. But for a list tool with three undocumented parameters and no routing guidance among dozens of siblings, the description leaves key operational information (filtering, pagination) entirely unaddressed.

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

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

All three parameters (ids, limit, offset) have 0% schema description coverage, and the description mentions none of them. The only named fields ('status, item count, update time') are response attributes, not the inputs, so the description does not compensate for the coverage gap at all.

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 fragment names the resource (product feeds) and hints at the returned attributes (status, item count, update time), so an agent can infer it is a list operation. However, there is no verb and no differentiation from the many sibling list tools (webmaster_list_feeds, direct_list_campaigns, etc.), leaving the exact scope ambiguous.

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?

'Read-only' is a safety trait, not usage guidance. Nothing states when to call this versus webmaster_list_feeds or webmaster_get_feed, and no preconditions or context of use are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered structurally. The description adds the non-obvious behavioral fact that form data is PII-gated behind include_data=true, which an agent could not infer from annotations or schema defaults (include_data defaults to false). It does not mention pagination behavior or result size 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 dense sentence plus a short read-only assertion; the PII caveat is front-loaded alongside the filter. 'Read-only' duplicates the readOnlyHint annotation and is the only non-earning clause.

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?

Every required element for a correct call is present: the filter input, the PII gate, and the read-only nature. An output schema exists so return values needn't be described, and the only real gap is pagination/limit guidance for a tool that defaults to limit=500.

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 carry the burden. It does explain turbo_page_ids (filter key) and, crucially, why include_data matters (PII exposure), but limit and offset — both with defaults — get no explanation of range, ordering, or pagination 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?

Names a specific resource (Turbo page leads) and the filter dimension (TurboPageIds), which separates it from the adjacent direct_list_turbo_pages. It doesn't explicitly name that sibling as an alternative, so the differentiation is inferable rather than stated.

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 clause 'form data (PII) only with include_data=true' tells the agent when the sensitive mode applies, which is real conditional guidance. However, there is no when-to-use vs when-not-to-use framing against siblings such as direct_list_turbo_pages, so usage remains implied.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Read-only' merely repeats structured data. The description adds nothing about pagination behavior (limit/offset defaults of 500/0) or ordering, which are the meaningful behavioral gaps here.

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?

It is short and front-loads the resource, but it reads as an under-specified fragment rather than an efficiently complete statement. The parenthetical '(required by the API)' is noise that adds confusion instead of 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?

An output schema exists, so return values need not be described. Still, for a 3-parameter read tool with 0% schema coverage, the description leaves the ids/limit/offset semantics and their interaction unexplained, and it misstates the requiredness of ids.

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%, so the description must carry parameter meaning but only hints at 'Ids'. Worse, it claims Ids are 'required by the API' while the schema marks ids optional with default null and lists zero required parameters, which is misleading. limit and offset are entirely 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 names a specific resource ('shared negative keyword sets') filtered by Ids, which distinguishes it from the many other direct_list_* siblings (campaigns, sitelinks, creatives). However it is a noun phrase with no explicit verb, so the 'list' action is only inferred from the tool name rather than stated.

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 when-to-use guidance and no mention of alternative tools or conditions. The agent gets no signal about when this is preferred over other listing endpoints or how to reach it via prepare/apply flows.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Read-only' adds no new behavioral information. The description discloses no pagination behavior despite limit/offset parameters, and the field list it provides is return-shape detail rather than operational context.

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

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

It is a single compact sentence plus a fragment, with the resource named first and no wasted words. The brevity is appropriate even if the content is thin.

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

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

An output schema exists, so return values need not be explained, but with three undocumented parameters (including paging controls) and no usage context, the definition leaves an agent guessing how to call it correctly. For a read-only list tool with defaults of limit=500 and offset=0, more guidance is warranted.

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% across three parameters (ids, limit, offset), and the description never mentions any of them. The listed fields (Id, Type, Name, IsAvailable) describe output entities, not the input parameters, so the description does not compensate for the schema gap.

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 a specific resource (retargeting and audience-selection lists) and its returned fields, so an agent can tell it apart from unrelated list tools such as direct_list_creatives. However, it never explicitly names a verb and offers no differentiation from close siblings like direct_list_audience_targets or audience_list_segments.

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 when-to-use guidance, no exclusions, and no pointer to alternative tools for overlapping list needs. The agent must infer usage context purely from the tool 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and 'Read-only' merely restates that. The description adds no behavior beyond the annotations: no pagination semantics, no result-set size behavior, no note on what the limit default of 500 implies.

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 terse fragments are front-loaded and easy to scan, but 'Read-only' is pure repetition of the annotations and the field enumeration duplicates the output schema, so not every phrase 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 read-only list tool with rich annotations and an existing output schema, return values and safety need not be explained, so the core is covered. However, two of three parameters and all pagination behavior are left undocumented, which is a real gap for a listing tool that defaults to 500 items.

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 carry the parameter burden, yet it only addresses ids ('Optional Ids filter'). limit and offset are never mentioned, so an agent gets no statement about pagination or what the defaults mean.

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 (sitelink sets) and enumerates the returned fields (Id, Title, Href, Description), so an agent knows exactly what it retrieves. It lacks an explicit verb, but the 'direct_list_' prefix plus the field enumeration makes the intent unambiguous and clearly distinct from the other list siblings.

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

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

'Optional Ids filter' is the only guidance and it is about a parameter, not about when to choose this tool over alternatives. There is no when-to-use, when-not-to-use, or named alternative anywhere in the description.

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/destructiveHint, and the description's 'Read-only' simply restates that. It says nothing extra about pagination behavior, how filters combine, limits on the id arrays, or dataset size — the kind of context that would add value beyond structured fields.

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, resource and filter axes front-loaded with no padding. The trailing 'Read-only' sentence is redundant with the annotations, a small waste.

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 5-parameter, fully undocumented schema, the description should clarify filter combination rules and pagination expectations. An output schema exists so return values need not be explained, but the query-construction gaps leave an agent guessing how to build a correct 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 description coverage is 0% for 5 parameters. The description maps 'campaign/group/id' to campaign_ids, ad_group_ids and ids, but omits limit and offset entirely and gives no semantics for the array filters (combined with AND? mutually exclusive? empty means no filter?). Partial compensation only.

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?

Names the resource precisely (SmartAdTargets / smart-banner feed filters) and the dimensions it filters on (campaign/group/id), so an agent can tell it apart from the adjacent direct_list_dynamic_feed_ad_targets. It relies on the tool name for the verb rather than stating 'list' explicitly, so it falls just 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?

No when-to-use guidance, no statement of prerequisites, and no explicit routing to or away from the dynamic-feed or audience-target siblings. 'Read-only' hints at safe retrieval but does not tell the agent when this tool is the right choice.

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

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

Annotations already declare readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered; the description adds 'with paging' and the concrete API version, which are real behavioral facts beyond the annotations. It stops short of stating default page size behavior or whether strategy_ids/archived are applied server-side.

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 clauses, front-loaded with the core operation, followed immediately by the routing alternatives. No filler sentences and nothing redundant with the schema.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. However, for a paged, filter-capable list tool with four undocumented parameters, the absence of any filter/paging semantics leaves a meaningful gap in what an agent needs 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 description coverage is 0% across 4 parameters, so the description must carry the semantics and largely does not. 'With paging' loosely implies limit/offset, but the `archived` YES/NO filter and the `strategy_ids` selector — the two parameters that most affect the result set — are never explained.

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

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

States a precise verb+resource ('List Direct shared (portfolio) strategies') and even names the underlying API call (Strategies.get v501), which disambiguates it from the many other list_* siblings. An agent can identify the exact operation without opening the schema.

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

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

Explicitly routes two neighboring needs to alternatives: a campaign's own strategy goes to `direct_get_campaign`, and type-specific fields go to `direct_get_inventory` with service=strategies. That is clear when-not-to-use guidance, though it does not state the positive trigger condition (e.g., 'use this when you need portfolio-level strategies across campaigns') or any prerequisites.

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, destructiveHint=false and idempotentHint=true, and the description's 'Read-only' simply restates that. The field enumeration (Id, Name, Href) is already conveyed by the output schema, so nothing beyond structured data is added – no mention of pagination behavior, total counts, or scope of the list.

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

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

A single compact line with the payload shape front-loaded and the cross-tool hint second. Every clause is short and readable, though the semicolon-packed style leaves no room for the missing parameter/pagination 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?

An output schema exists, so return values need not be explained, but with 3 undocumented parameters at 0% coverage and only annotations covering safety, the definition omits how to filter (ids) and page (limit/offset) – essential operational detail for a list endpoint that can return up to 500 records.

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 carries the full burden for `ids`, `limit` (default 500) and `offset` (default 0). It never mentions filtering by ids or pagination, leaving an agent to guess from parameter names alone; only the 'use Id for direct_list_leads' phrase hints that ids are entity identifiers.

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?

Names the resource (Turbo pages) and enumerates the returned fields (Id, Name, Href), and points to the sibling consumer `direct_list_leads`, so the agent can tell what it retrieves and where its output goes. It lacks an explicit verb, but 'list_turbo_pages' plus the field list is 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?

Gives one concrete downstream usage rule ('use Id for direct_list_leads'), which is genuinely helpful routing. It does not say when to call this tool versus other list siblings, nor any prerequisites (agency client, account scope); usage is only implied.

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

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

With annotations flagging readOnly=false, idempotent=false, destructive=false, the description adds meaningful context the annotations cannot: the draft is unaccepted and expiring, it carries a diff hash and approval_id, and execution is gated on human acceptance. It stops short of describing failure modes or what invalidates the draft.

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

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

Two tight sentences, front-loaded with the action and followed by the lifecycle constraint. No filler and nothing redundant across the sentences.

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 approval lifecycle is well covered and an output schema exists so return values need no explanation. However, the complete absence of documentation for the `changes` payload — the one thing the caller must construct — leaves a significant gap for a mutation 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 single required parameter `changes` is an untyped array of free-form objects with 0% schema description coverage, and the description says nothing about its shape or contents. A mutation tool whose only input is opaque leaves the agent guessing at what a valid change set looks like.

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 ('Draft a Direct change set and open ... approval') and explicitly distinguishes the operation from its executor by naming `direct_apply_changes`. An agent can tell this is the prepare/draft half of a two-step flow without opening the schema.

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

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

Clear context: use this to draft, then a human must accept the approval before `direct_apply_changes` executes. It names the dependent tool and the gating condition, but gives no explicit when-not guidance or differentiation from sibling prepare flows like `direct_prepare_write`.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false). The description adds genuinely useful context beyond that: 'Nothing is sent' clarifies that despite looking like a write it is purely preparatory, and the 'allowlisted' constraint plus account/endpoint binding disclose scoping behavior. It still omits approval lifetime, what consumes the approval, and any 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?

Two tight sentences, front-loaded with the core action and immediately followed by the key 'Nothing is sent' guarantee. No filler, though the account/endpoint clause adds a small amount of ambiguity for parameters not present in the schema.

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

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

An output schema exists, so return values need not be described. For a 3-parameter, prepare-phase operation with 0% param coverage and no annotations about auth/prerequisites, the description is adequate about intent but leaves meaningful gaps in parameter meaning and the prepare→apply handshake.

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 carry the parameter burden. It names service, method and items (plus account/endpoint, which aren't surface parameters) but explains none of their semantics or formats — 'items' is an untyped array of free-form objects with no guidance on shape, and 'allowlisted' is never defined.

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

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

States a specific verb+resource: 'Open an approval for one allowlisted Direct write'. The prepare/apply split is hinted at via 'yandex://guide/prepare-apply', which implies the counterpart apply tool. It stops short of naming direct_apply_write explicitly, so sibling differentiation is inferential rather than direct.

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?

'Open an approval for one allowlisted Direct write' plus 'Nothing is sent' implies this is the first step before an apply. However, the crowded sibling set (direct_prepare_changes, direct_write, direct_apply_write, direct_apply_changes) is not differentiated, and 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.