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

No annotations exist, so the description carries the full burden. It explicitly states this CHANGES the live ad account (destructive behavior), explains permission requirements, enumerates possible return states (applied, verifying/unknown, partial, failed, conflict, rejected), and specifies retry behavior with the same idempotencyKey. This is exemplary disclosure 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?

The description is information-dense but every sentence earns its place: purpose, permission prerequisite, return semantics, and retry guidance. It is well-structured and front-loaded with the core action, followed by caveats and error handling.

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 no output schema, the description fully compensates by explaining the return command states and what to do for unconfirmed or failed states. It covers prerequisites, error cases, and retry behavior, making it complete for an action that modifies a live account.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that retrying with the same idempotencyKey returns the original command instead of double-changing the campaign, which is a behavioral nuance not fully captured by the schema's 'reuse the same value.' This goes beyond the schema's parameter descriptions.

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 begins with a specific verb and resource: 'Pause or resume one advertising campaign (Yandex Direct).' This clearly distinguishes it from sibling tools that perform metrics, search, or read-only operations. The scope is limited to a single campaign, which adds precision.

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 provides clear context for when the tool works: it requires the account owner to grant API key permission and list the campaign as allowed, otherwise a permission error explains what to enable. It also directs the user to poll roasr_command_get for unconfirmed states and explains the retry pattern with idempotencyKey. It does not explicitly name alternatives for the same operation, but the usage conditions are well defined.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read-style status tool and outlines the response contents (state, results, request id, points). It does not cover potential errors, latency, or what happens if the command ID is invalid, but for a status polling tool this is reasonable.

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

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

Two sentences, front-loaded with purpose and key output details. The second sentence gives a concrete use case. No wasted 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?

The tool is simple (one parameter, no output schema) and the description covers purpose, source command, response highlights, and usage guidance. It could mention pagination or exact response shape, but the given context is sufficient for an agent to 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 coverage is 100% with a clear description of commandId as 'command UUID returned by the write tool.' The tool description adds context about how to use it (resolving verifying/unknown commands) but not additional parameter-specific meaning beyond the schema.

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

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

The description clearly identifies the tool as providing status and attempt history of a write command created by roasr_campaign_set_state. It specifies the key returned elements (final state, per-target results, request id, API points), distinguishing it from sibling list/metrics tools.

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

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

Explicitly states when to use it: 'Use it to resolve a command left in verifying or unknown.' It also mentions the originating write tool, implying it's the follow-up tool. However, it does not explicitly state when not to use it or name alternatives.

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

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

With no annotations, the description carries the full burden and does well by disclosing operational behavior: Daily budget enforcement, the report service's lack of unit usage reporting, and the queue limit. This goes beyond a simple list of returned fields, giving the agent actionable context. It could mention return format but is not essential.

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

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

The description is two sentences: first lists what is included, second gives a clear call-to-action with rationale. Every word earns its place, and the key operational warning is placed prominently.

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 zero-parameter nature, the description is fairly complete. It explains the tool's role, its contents, and crucial context for heavy report pulls. Some may expect a description of the output format, but that is not required and would only add length.

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

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

The tool has zero parameters, so the description does not need to explain parameter syntax. Per the rubric, a baseline of 4 is appropriate, and the description does not waste space on parameter details.

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

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

The description clearly states the tool's purpose: it returns subscription plan details, limits, API rate tier, and remaining Yandex Direct daily quota. Although no explicit verb like 'get' is used, the resource is specific and distinct from the listed siblings (e.g., metrics tools, campaign tools), making its function evident.

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

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

Explicit usage guidance is provided: 'Call this before heavy report pulls' and then explains why with concrete constraints (daily unit budget, no unit usage reported by report service, five-report queue limit). This tells the agent exactly when to invoke this tool versus relying on other reporting 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It states what data is returned (clients with context fields) but does not explicitly disclose whether this is a read-only operation, whether it returns all clients, or any edge cases. The lack of any explicit 'returns a list' or side-effect statement leaves room for ambiguity.

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 concise sentence that front-loads the resource and includes useful field details. Every word earns its place; there is no fluff or redundant 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 simple 0-parameter list tool, the description is adequate: it identifies the output (clients with their context) and the intended use case. It doesn't specify the return format (e.g., array of objects), but that is often implied. With no output schema, a bit more detail about the response could improve completeness, but the current level is acceptable for the simplicity of the tool.

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

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

There are no parameters, so the schema is trivially complete. The description adds useful context about the returned fields, which is more than necessary given the zero parameter count. Baseline of 4 applies.

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

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

The description clearly identifies the resource (workspace clients) and the specific context fields (name, niche, margin, status). Though it lacks an explicit verb like 'List', the tool name and the description make the purpose unambiguous. It is distinguishable from sibling tools like roasr_list_findings, though it doesn't explicitly differentiate itself.

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

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

The description gives an implied use case—'for analysis scoped to a specific client'—but does not provide explicit when-to-use guidance or mention alternatives. There is no exclusion criteria or comparison to other tools, so the guidance is only implicit.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses key output characteristics (priority ranking, stable status) and scoping behavior, which is useful. It does not mention read-only nature, auth, rate limits, or error conditions, but for a list tool this is moderate transparency.

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, well-structured sentence that front-loads the main purpose and provides essential details without wordiness or repetition.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers purpose, output ordering (severity), and scoping. It omits details like pagination or exhaustive list guarantees, but these are not critical for this use 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?

The only parameter, clientId, is fully described in the schema as an optional client UUID with instructions to omit for workspace-wide results. The description's 'Can be scoped to one client' merely restates the schema comment without adding new semantic meaning, so baseline 3 applies due to 100% schema coverage.

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

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

The description explicitly states the tool returns AI audit findings across connected ad accounts (Meta, Google, Yandex Direct), with issues ranked by severity (high/med/low) and a stable status. It also mentions optional client scoping, which clearly distinguishes it from sibling metrics/spy tools.

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

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

The description implies usage when audit findings are needed and clarifies that scope can be limited to one client. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusionary 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?

With no annotations provided, the description carries the full burden. It discloses a critical behavioral trait: 'Buckets are NOT additive: engagement is an aggregate and reactions/comments/shares are its components (summing them double-counts).' It also explains raw vs buckets. This is valuable context, though it omits other behaviors like auth or rate limits.

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

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

Two sentences, front-loaded with purpose, followed by output options and the critical caveat. No wasted words, but the second sentence is dense and could be split for easier reading.

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?

No output schema exists, so the description explains both return formats (raw and buckets) and the non-additive caveat. It lacks explicit definition of 'value' units and pagination behavior, but the core functionality and key data semantics are 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 100%, so the schema already documents all parameters well. The description adds general context about date windows but does not provide per-parameter semantics beyond what the schema offers. Baseline 3 is appropriate.

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

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

The description clearly states the purpose: 'Workspace conversions broken down by action type for a date window.' It specifies the resource (workspace conversions), the breakdown dimension (action type), and the scope (date window). It is distinct from siblings by its focus on action-type breakdowns, though it does not explicitly name alternatives.

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

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

Usage is implied from the description: use when you need action-type breakdowns of conversions. However, there is no explicit guidance on when to use this tool versus siblings like roasr_metrics_summary or roasr_metrics_breakdown, nor any when-not-to-use notes.

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?

Despite lacking annotations, the description provides key behavioral details: it returns segments with metrics, explains that reach/frequency are Meta-only and null for other data, and clarifies that data is as of the latest snapshot date (asOf) within the window. This gives useful context about data freshness and limitations without repeating schema information.

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

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

The description is two sentences long and immediately conveys the core purpose and key nuances. It is front-loaded with the primary function and dimension list, and the second sentence adds essential caveats without fluff. Every word 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?

Given the absence of an output schema, the description adequately describes what is returned (segments with metrics) and includes important caveats (Meta-only reach/frequency, snapshot date). It also covers the main dimension options. It does not explicitly address pagination or potential error cases, but for a breakdown tool this is reasonably complete.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds context about what the metrics include and the snapshot date behavior, but it does not add meaning beyond the schema for individual parameters. The baseline of 3 applies because the schema fully covers parameter semantics.

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

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

The description clearly states the tool's function: 'Metrics broken down by dimension' followed by a specific list of possible dimensions. It distinguishes itself from sibling tools like roasr_metrics_summary and roasr_metrics_daily by focusing on breakdown by dimension, including explicit dimension values.

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 usage is implied through the description ('Metrics broken down by dimension'), making it clear this is for dimension-level analysis rather than summary or daily metrics. However, there is no explicit when-to-use vs alternatives, no exclusion criteria, and no mention of when a different tool would be more appropriate.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It usefully discloses that results are sorted by spend, that reach/frequency are Meta-only and null elsewhere, and that windows earlier than dataSince return empty. However, it does not mention pagination, auth, or output format, so it is not fully transparent.

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

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

Two sentences with high information density. The description front-loads the core purpose and then adds key behavioral caveats without verbose explanation.

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 no annotations and no output schema, the description covers primary functionality, sorting, platform-specific nulls, and empty-window behavior. It lacks explicit sibling differentiation but is otherwise reasonably complete for a 7-parameter 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 coverage is 100% for all 7 parameters. The description adds the important dataSince context, which is not in the schema, clarifying behavior of date windows. It also reinforces the 'level' parameter's meaning (campaign/adset), though this is already in the schema. This extra semantics elevates it above baseline.

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

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

The description explicitly states the tool returns per-campaign or per-adset metrics and KPIs for a date window, with a list of example metrics and sorting by spend. This is a specific verb+resource combination that clearly distinguishes it from sibling metrics tools by granularity and ordering behavior.

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

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

No guidance is given on when to use this tool versus alternatives like roasr_metrics_summary, roasr_metrics_daily, or roasr_metrics_breakdown. The description implies campaign/adset-level analysis but does not mention exclusions or alternative use cases.

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

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

With no annotations, the description carries the transparency burden. It discloses important behavioral details: reach/frequency are Meta-only (null for older/non-Meta data) and daily reach must not be summed across days. This exceeds minimal expectations, though it omits other potential traits like auth or rate limits.

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

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

Two sentences, front-loaded with the tool's purpose, followed by crucial caveats and a parameter hint. No filler or redundancy; every sentence earns its place.

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

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

The description lists the returned metrics, warns about data caveats, and clarifies the entityRef behavior. Combined with the fully documented schema (all 6 parameters), it gives the agent enough context to invoke the tool correctly, though it does not describe the exact response structure.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds 'entityRef narrows to a single campaign/adset,' which largely repeats the schema's own description. It does not materially enhance parameter understanding beyond what the schema already provides.

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

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

The description clearly states that the tool returns daily metric series over a date window for the workspace, listing specific metrics. It distinguishes itself from sibling metrics tools by the word 'daily' and the focus on trends/charts, but does not explicitly name alternatives, so it stops short of a 5.

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

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

The phrase 'for trends and charts' provides a clear usage context, and the entityRef parameter is explained as narrowing to a single campaign/adset. However, it does not explicitly compare with sibling tools (e.g., summary, breakdown) nor state when not to use it, leaving the choice to the agent.

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

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

With no annotations, the description carries the full burden and does well: it discloses that reach/frequency are Meta-only, null for older/non-Meta data, and that frequency is not additive across days. It also clarifies the entityRef narrowing behavior, adding meaningful context beyond the 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?

The description is two sentences, immediately front-loaded with the core purpose, and packs essential caveats without redundancy. Every clause adds 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?

For a summary tool with no output schema, the description covers the key metrics, date-window behavior, important data caveats, and how entityRef works. It doesn't describe the exact return structure, but that is less critical given the aggregate nature and complete parameter schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal param-specific info (entityRef narrowing is already in the schema) and does not compensate with extra parameter-level guidance, though the metric caveats are useful.

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

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

The description clearly states the tool provides workspace ad KPIs for a date window and enumerates the included metrics (spend, impressions, clicks, etc.). This distinguishes it from daily or breakdown tools by its aggregate nature, though it does not explicitly name an alternative or contrast with sibling tools.

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

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

The description provides some context (Meta-only reach/frequency, non-additive frequency, entityRef narrowing) but does not explicitly state when to use this tool over alternatives like roasr_metrics_daily or roasr_metrics_breakdown. There are no exclusions or alternative tool references.

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

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

With no annotations provided, the description carries the full burden and does disclose several key behaviors: 'Per-account latest snapshot inside the window (payloads of different accounts are not aggregated)' and 'response is capped by limit (default 50)'. This goes beyond a simple 'get data' claim and gives the agent useful operational context, though it doesn't detail permissions or per-kind payload schemas.

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

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

The description is compact yet information-dense. It front-loads the core purpose, uses a list to convey many signal kinds without fluff, and includes important behavioral caveats in a single dash-separated clause. Every sentence earns its place with no redundancy.

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

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

Given the tool's complexity (16 enum kinds, 7 parameters, no output schema), the description covers the essential operational semantics: what the tool returns, how it scopes data (date window, per-account snapshot), and the response cap. It doesn't describe the exact output structure for each kind, but the kind names are self-explanatory and the schema covers parameters, making the description adequate for selection.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that 'kind' groups the signal categories, that the window is per-account snapshot with non-aggregated payloads, and that 'limit' caps the response. These are not explicit in the schema's property descriptions and help the agent understand parameter roles.

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

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

The description clearly states the tool provides 'rich signals for a date window by kind' and enumerates the specific signal categories (Google search terms, auction insights, etc.). It explicitly distinguishes itself from siblings by noting 'this is intel the plain metrics tools do not have', which helps an agent differentiate it from the metrics-summary/breakdown tools.

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

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

The description implies use when non-metric diagnostic signals are needed ('intel the plain metrics tools do not have') and when a per-account latest snapshot is desired. It does not name specific alternative tools or state explicit when-not-to-use scenarios, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses the output fields (hook, headline, format, tags, country, ad_archive_id), the empty-input behavior (returns top by days_live), and the meaning of days_live as a proxy for wins. It does not mention rate limits, authentication, or error cases, but for a search tool it is reasonably transparent.

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

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

The description is compact—two sentences—and front-loaded with the core action ('Search stored competitor creatives'). Every sentence provides value: the first explains the search filters, the second covers return fields and the meaning of days_live. No wasteful repetition.

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

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

Given the tool has 3 optional parameters, no output schema, and no annotations, the description is quite complete. It covers the search capability, the output fields, the empty-input case, and the workflow link to Vision analysis. It does not specify the ordering for non-empty queries (e.g., relevance vs. days_live), but that is a minor omission.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by clarifying that 'query' searches hook/headline/tags, and that 'brand' is an exact page-name filter. It also explains the effect of leaving both empty (returns top by days_live), which complements the schema. Thus it goes beyond the existing param descriptions.

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

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

The description clearly states the tool's verb and resource: 'Search stored competitor creatives from the Meta Ad Library.' It specifies the search dimensions (by keyword and/or brand) and explains what the keyword targets ('hook/headline/tags'). This distinguishes it from sibling tools like roasr_spy_tag_leaderboard or roasr_vision_analyze, making the purpose unambiguous.

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

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

The description provides clear context for when to use the tool: to search creatives by keyword or brand, and it notes the empty-input behavior. It also mentions a follow-up Vision analysis, indicating a workflow. However, it does not explicitly contrast with alternatives (e.g., when to use roasr_spy_tag_leaderboard instead), so it stops short of a full when/when-not guideline.

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

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

With no annotations, the description carries the burden. It discloses an important behavioral trait: 'days_live is a proxy for what wins,' and clarifies the data source (Meta Ad Library). It also implies a read-only operation. It does not mention rate limits, caching, or edge cases, but for a simple leaderboard tool this is sufficient 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?

Two concise sentences, front-loaded with the core definition, then adding value by explaining what makes it unique. No wasted words or redundancy.

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

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

For a simple one-parameter tool with no output schema, the description explains the essential return content (formats/angles/offers used, days_live) and its interpretive meaning. It does not provide a field-level breakdown, but the tool's low complexity makes this 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?

The input schema covers the single parameter (limit) with a full description and default value (100% coverage). The description adds no additional parameter semantics, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb ('Leaderboard') and resource ('competitor creative tags from the Meta Ad Library'), and details what it shows (formats/angles/offers, days_live). It distinguishes itself from siblings by explicitly noting this is intel 'the plain metrics tools do not have.'

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 provides clear context on when to use this tool: to get competitor creative tag intelligence that standard metrics tools lack. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the video transcript is only returned 'when available' and that the tool does not initiate analysis itself ('if it has not been analysed yet, start the analysis inside the app'), implying a read-only retrieval behavior. It lacks details like error behavior or rate limits, but for an analysis tool the key behavioral traits are conveyed.

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 only two sentences, with each sentence earning its place: the first defines what the tool does, and the second provides the prerequisite workflow. There is no fluff or repetition beyond the source reference, and the phrasing is direct and scannable.

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 a single parameter and no output schema, the description covers the essential contexts: what the tool returns, a conditional output (transcript), and the prerequisite step (spy_search + analyze inside app). It does not detail return formatting or edge cases, but for a tool of this complexity the description is sufficiently complete to set expectations.

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

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

The schema already provides the parameter description 'creative ad_archive_id (from roasr_spy_search)', which fully explains the parameter's meaning and source. The description repeats this by telling the user to find the creative with roasr_spy_search first, adding no new semantic detail beyond what the schema already provides. Thus the baseline of 3 is appropriate.

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

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

The description clearly states the tool performs vision analysis on a competitor creative referenced by ad_archive_id, listing specific output types (hook, angle, format, strengths, risks, transcript). It also distinguishes itself from the sibling metrics tools by stating it provides 'Analysis the plain metrics tools do not have', which helps differentiate from the surrounding tools.

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

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

The description offers actionable workflow guidance: first find the creative using roasr_spy_search, then use this tool. It also implies a precondition (the creative must already be analyzed, otherwise start analysis inside the app). While it does not explicitly list when not to use the tool, the contrast with metrics tools and the explicit prerequisite provide clear context for selecting this 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?

With no annotations, the description carries the full burden. It discloses read-only behavior, Yandex-only compatibility, and an error condition for non-Yandex accounts. These are meaningful behavioral traits beyond what the schema provides, though it omits return-format details and pagination, keeping it from 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?

The description is three sentences, front-loaded with the key constraints ('Yandex Direct only, read-only'), then lists output fields concisely, gives use cases, and notes error behavior. Every sentence contributes meaningful information with no redundancy.

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

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

Given 5 parameters, full schema coverage, and no output schema, the description is quite complete: it lists output fields, use cases, and error behavior. It lacks an explicit return structure (e.g., 'returns array of ads') but the field list gives a solid picture. The default date window is in the schema, so the description remains sufficiently 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 coverage is 100%, so baseline is 3. The description adds semantic value by explaining the accountId error condition ('Errors if accountId points to a non-Yandex account') and framing parameters around a date window. This extra context justifies a 4.

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

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

The description clearly identifies the tool as returning Yandex Direct ads with moderation status and metrics, listing specific fields (state/status/statusClarification, second headline, sitelinks, etc.). It distinguishes from siblings by specifying 'Yandex Direct only' and the focus on ads, making its purpose unambiguous.

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

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

The description explicitly states when to use the tool: 'Use it to find rejected ads, or ads missing a second headline or link markup.' It provides clear context but does not explicitly mention alternative tools or when-not-to-use scenarios, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses read-only nature, the error condition for non-Yandex accounts, and the data content for each dimension. While it doesn't mention pagination or rate limits, it provides solid behavioral context beyond just 'gets breakdowns'.

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

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

The description is dense but every sentence adds value. It front-loads the key scope ('Yandex Direct only, read-only'), then maps dimensions to their content, states the error condition, and provides alternatives. No redundant phrases; the length is justified by the complexity.

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 tool's moderate complexity (6 params, no output schema, no annotations), the description covers platform restriction, safety, dimension semantics, error cases, and sibling alternatives. It does not explicitly describe return format, but the dimension descriptions convey what data to expect. Could mention aggregation/row structure, but overall it is complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds meaningful semantics for the 'dimension' parameter by elaborating on each enum value (e.g., 'search_queries (search terms with spend/conversions)'), and clarifies accountId's Yandex-only requirement. This goes beyond the schema's terse enum descriptions, though other parameters are left to the schema.

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

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

The description clearly states the tool's purpose: it returns Yandex Direct breakdowns for specific dimensions (search_queries, keywords, ads, bidding), with detailed explanations of what each dimension contains. It also distinguishes from siblings by noting 'same data as roasr_yandex_search_queries' and 'same data as roasr_yandex_ads', and clarifies it is Yandex-only.

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 says when to use alternatives: 'For campaign/adset totals or device/region/audience/placement splits on a Yandex account, use roasr_metrics_campaigns / roasr_metrics_breakdown instead'. Also warns 'Errors if accountId points to a non-Yandex account', giving a clear exclusion. This provides strong guidance on when to select this tool vs siblings.

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

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

With no annotations, the description fully handles behavioral disclosure. It explicitly declares read-only, explains the semantic meaning of empty goals (conversions cannot be attributed), warns about the error condition for non-Yandex accounts, and clarifies that this is current configuration rather than a time series. This is comprehensive for a read-only tool.

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

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

The description is four short sentences, front-loaded with essential scope and safety information ('Yandex Direct only, read-only'). Every sentence adds unique value: scope, purpose, empty-goal interpretation, and error behavior. No redundancy or filler.

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

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

The description covers purpose, scope, interpretation of empty goals, and error conditions. It is missing an explicit description of the return format (e.g., a list of goal names/IDs), but since this is a config-read tool and the semantics are clear, it is mostly complete. The lack of output schema makes a slight gap, but not critical.

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

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

The schema already provides 100% coverage for both parameters with clear descriptions. The tool description adds the context that accountId must be a Yandex account and that omitting it means 'all Yandex accounts', but this is already in the schema. No additional syntax or formats are needed beyond this.

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

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

The description clearly states the tool retrieves which Yandex.Metrika goals are selected for an account, with a specific implied action (listing/getting). It distinguishes itself from siblings by emphasizing 'current config, not a metric series,' which sets it apart from metrics-focused tools.

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

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

It explicitly states 'Yandex Direct only, read-only' and provides a key caveat about empty goals meaning conversions are untrustworthy. It also warns about errors for non-Yandex accounts. It doesn't name specific alternatives, but the 'not a metric series' phrase implies when not to use it.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is read-only, lists the data fields returned, and warns of an error for non-Yandex accounts. These are meaningful behavioral traits beyond the schema, though it does not mention pagination or rate limits.

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

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

The description is three sentences: purpose, use case, and error condition. It is front-loaded with 'Yandex Direct only, read-only' and every sentence contributes essential information without 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?

Given no output schema, the description adequately lists return fields and provides a business context. It also notes an error condition. However, it lacks mention of pagination, limits, or how results are ordered, which keeps it from a perfect score.

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

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

Schema coverage is 100%, so all five parameters have descriptions. The tool description adds little beyond reiterating the date-window concept (since/until/sinceDays). Per guidelines, baseline is 3 when schema does the heavy lifting, and this is exactly the case.

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

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

The description clearly states the tool retrieves search queries for a date window, listing specific fields (query text, campaign/ad group, match type, impressions, clicks, spend, conversions). It distinguishes itself with 'Yandex Direct only' and 'read-only', setting it apart from sibling tools like yandex_breakdown or yandex_ads.

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 a concrete use case: 'use it to find what share of spend went to queries with zero conversions.' It also notes an error condition (non-Yandex account), implying when to use via platform constraint. However, it does not explicitly name alternative tools or say when not to use it.

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