yandex-direct-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.3.0
Disambiguation3/5
Most tools have distinct targets, but the many budget/strategy write tools (set_max_conv, set_strategy, set_daily_budget, set_network_weekly_budget, set_search_weekly_budget) overlap in purpose and could confuse an agent. Some list/get tools are also similar, though descriptions help.
Naming Consistency4/5
The vast majority follow direct_verb_noun (e.g., list_campaigns, set_keyword_bids, delete_keywords). A few anomalies like direct_ping, direct_rpc, direct_account_summary, and direct_client_info deviate from the verb-first pattern, but the overall convention is clear and predictable.
Tool Count1/5
With 80 tools, the server is far beyond the typical well-scoped range. Even for a complex API, this number is excessive and will likely overwhelm agents, making tool selection harder rather than easier.
Completeness5/5
The tool set covers the full lifecycle of Yandex Direct campaigns: creation, management, bidding, budgets, extensions, reporting, and even a raw RPC escape hatch. There are no obvious dead ends; nearly every operation an agent could need is present.
Average 3.7/5 across 80 of 80 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral disclosure is the 'READ:' prefix, implying a non-destructive read operation. There is no mention of return format, pagination, scope, authentication, rate limits, or any side effects. With no annotations to supplement, the description carries the full burden and fails to provide meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, and the 'READ' prefix is front-loaded. However, it is under-specified to the point of being cryptic; the phrase 'Metrika audience lists in cabinet' is vague and would benefit from elaboration without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and minimal parameter descriptions, the description should provide more context. It fails to explain what the tool returns, how optional parameters affect results, or what 'cabinet' refers to, leaving significant gaps for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows 'ids' (array of integers) and 'limit' (integer) with no descriptions, and the description adds no parameter explanations. It does not clarify what 'ids' refer to (e.g., retargeting list IDs) or how 'limit' controls pagination. With 0% schema coverage, the description was expected to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates a read operation ('READ') and the resource ('retargeting lists'), with the API method 'retargetinglists.get' providing specificity. It distinguishes from siblings like 'direct_list_audience_targets' by focusing on retargeting lists rather than audience targets, though 'Metrika audience lists in cabinet' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any exclusions. The description mentions no context for selecting this tool over sibling tools like 'direct_list_audience_targets' or other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is responsible for disclosing side effects. It does state 'WRITE' and mentions 'allow_write=true', which signals a mutating operation requiring explicit consent. However, it omits crucial behavioral details such as potential duplicate creation, validation of retargeting list IDs, idempotency, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally brief and front-loaded with the WRITE label, but it uses telegraphic syntax that sacrifices clarity. It conveys the core purpose in a compact form but omits necessary elaboration, making it more under-specified than properly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a sparse description, leaving many gaps. It does not disambiguate from sibling tools, explain return values, or mention prerequisites like the need for existing retargeting lists and valid ad groups. For a write operation, this level of context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'project' and 'allow_write', but the nested fields (adgroup_id, retargeting_list_id, context_bid_rub) have no descriptions. The description merely lists these field names, adding no semantic meaning such as what adgroup_id refers to or how context_bid_rub is used. The question mark on context_bid_rub only reflects optionality already encoded in the required array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels this as a WRITE operation for 'audiencetargets.add' and lists the expected fields, clearly indicating it adds audience targets. This distinguishes it from read-only or state-modifying siblings. However, it relies heavily on the tool name and API endpoint naming rather than a natural-language statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like direct_list_audience_targets or direct_audience_targets_state. The mention of 'allow_write=true' is a safety flag, not usage context. The agent must infer from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose safety traits. It labels the operation as WRITE and notes mode=merge|replace and the need for allow_write=true, but it omits details about destructive effects, whether replace overwrites all existing negatives, or permissions. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loads the WRITE flag, which helps triage. However, it is more of a parameter summary than a coherent explanation. Still, no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with 7 parameters, no output schema, and no annotations, the description is drastically under-specified. It lacks return value information, side effects, and essential usage context. This is inadequate for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (29%), with only project and allow_write described. The description adds mode and project hints but fails to explain key parameters like phrases, adgroup_id, adgroup_ids, and dry_run. The differentiation between adgroup_id and adgroup_ids is critical and missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as 'adgroups.update NegativeKeywords', clearly indicating this tool modifies negative keywords on ad groups. The WRITE: prefix reinforces the mutation intent. However, it does not differentiate from sibling tools like direct_set_negatives, which may handle campaign-level negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to choose this tool over siblings. The description is a technical shorthand rather than usage instructions. There is no mention of alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It only indicates 'WRITE' and 'allow_write=true', but does not disclose side effects (e.g., whether callouts are appended/overwritten, reversibility, or live cabinet impact). The dry_run parameter is not explained in the description, and no return behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the 'WRITE:' prefix front-loading the action and constraints. It is a single sentence with no redundant words, though the UI/EPK phrase is somewhat vague. Overall, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations, yet the description is extremely sparse. It omits critical context like dry_run behavior, what the response looks like, and how this differs from direct_attach_callouts. The description is inadequate for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only allow_write has a description). The description repeats the maxLength constraint for callouts (already in schema) and mentions allow_write=true, but does not explain dry_run at all. It adds little meaning beyond what the schema already provides, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('WRITE') and resource ('adextensions callouts'), with the constraint of ≤25 chars. It distinguishes from list tools but does not explicitly differentiate from direct_attach_callouts, which is a close sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only hints at UI/EPK limitations ('Attach via UI/EPK may be limited') but does not state when to use this tool versus alternatives like direct_attach_callouts. There is no explicit when/when-not guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the operation as 'READ' and notes that spend fields are available 'where available on get', suggesting conditional availability. However, it omits other behavioral details such as pagination, error handling, or permission requirements, and there are no annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant content, front-loading the read intent. While brief, it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is too sparse to fully convey the tool's behavior, input requirements, or return value. It leaves the agent without enough context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention either parameter. Schema coverage is 50% (project has a description, campaign_ids does not), and the tool description does not compensate for the missing parameter semantics, leaving the agent without guidance on how to populate campaign_ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('campaign funds / shared account spend fields') and uses the verb 'READ', making it clear this is a read operation. It is distinct from sibling tools like direct_list_campaigns which list campaigns, though the phrase 'where available on get' adds slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; the description does not specify when to use this tool over direct_list_campaigns or direct_get_campaign, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that this is a WRITE operation and that allow_write=true is needed to perform the mutation, which is useful. However, it lacks key behavioral details: it does not mention what happens if allow_write is false (e.g., dry run), whether the operation replaces only specified fields or all fields, error behavior, or any rate limits/permissions. The cryptic 'No ₽·— VPN' adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence and front-loads 'WRITE', which is good. However, the inclusion of the garbled phrase 'No ₽·— VPN' detracts from clarity and wastes space. It is not fully polished, though it is arguably still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, a nested 'ads' object, no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, partial success behavior, or how to construct the ads array correctly. The description fails to provide a complete picture for an agent to safely use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'ads' parameter by listing the updatable fields (Title/Title2/Text/Href/DisplayUrlPath/AdImageHash/SitelinkSetId), which are otherwise undocumented in the schema. This partially compensates for the 40% schema description coverage. However, it does not mention 'clear_image', 'dry_run', or explain the 'project' parameter beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'WRITE: ads.update TextAd Title/Title2/Text/Href/DisplayUrlPath/AdImageHash/SitelinkSetId.' This specifies the verb (update), the resource (TextAd), and the exact fields to update. However, it does not explicitly compare against sibling tools like direct_update_ad_href, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions 'allow_write=true' as a requirement and 'optional moderate_after', but does not explain when to prefer this over alternatives such as direct_update_ad_href or direct_add_ads. There are no exclusions or explicit alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does state that this is a write operation and that allow_write=true is needed to actually mutate live cabinets, plus mentions optional moderation. However, it omits side effects, permission requirements beyond allow_write, behavior when creative_id is reused or invalid, error handling, and whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the 'WRITE' signal and packs essential workflow steps into minimal words. Every phrase earns its place, but the density makes it cryptic; a slightly more structured or plain-language version would improve readability without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not describe return values, how multiple ad_ids are handled, failure modes, or why project is restricted for writes. This leaves an agent uncertain about critical behaviors when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low at 43%, so the description must compensate. It adds value by showing that video_id is used in creatives.add, creative_id allows skipping creative creation, and moderate_after is optional. However, it does not clarify ad_ids, dry_run, or the project key restriction, leaving significant gaps for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a write operation that attaches a video extension by creating a VideoExtensionCreative and updating ads with the creative ID. This distinguishes it from sibling tools like direct_upload_advideo, which only uploads videos. However, the use of internal API call names (creatives.add, ads.update) makes the purpose less immediately accessible to someone unfamiliar with the API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as direct_attach_callouts or direct_upload_advideo. It only notes the write nature and allow_write=true requirement, leaving the agent to infer appropriate use from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It labels the operation as 'READ', which implies non-mutating behavior, but says nothing about return format, error conditions, or whether the schedule is for a specific date range. The word 'READ' is largely redundant with the 'get' in the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise line with no filler. It is front-loaded with the action, though the 'READ:' prefix could be seen as slightly redundant with the tool name. Overall, it is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the return value looks like. It only says 'READ: campaign TimeTargeting schedule', leaving out details such as the structure of the schedule or potential empty results. This is inadequate for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single required parameter, campaign_id. The description mentions 'campaign' but does not explain the parameter's meaning or expected values beyond what the schema already shows, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('READ') on a specific resource ('campaign TimeTargeting schedule'). It distinguishes itself from sibling tools like direct_set_time_targeting by indicating the read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not mention that direct_set_time_targeting should be used to modify the schedule, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden; it does state 'READ' which indicates a read-only operation. It also discloses the specific data returned (autotargeting rows, categories, bid). However, it provides no further behavioral context such as filtering, pagination, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is telegraphic but contains all key elements: operation (READ), resource, and relevant parameters. It's front-loaded and avoids filler, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with two parameters and no output schema, the description provides the return components but leaves ambiguity around parameter usage (e.g., whether campaign_ids are needed when project is set, and what 'all' or 'unknown' mean for project). It lacks context on how the parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely echoes the parameter names 'project/campaign_ids' without adding meaning. The schema already documents 'project' in Russian, but 'campaign_ids' remains undocumented. The description does not clarify whether parameters are required, optional, or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the explicit verb 'READ' and specifies the exact resource: autotargeting keyword rows, AutotargetingCategories, and Bid. This clearly distinguishes it from write tools like direct_set_autotargeting, though it doesn't explicitly compare with sibling get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like direct_get_keyword_bids or direct_get_negatives. It only states the operation, leaving selection to the agent based on the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly labels the operation as 'READ:', which communicates that it is non-mutating. Since no annotations are provided, this is valuable transparency. However, it does not disclose other behavioral traits such as pagination behavior, whether results are scoped by project or campaign/adgroup, or any potential performance implications, so the description only partially covers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is extremely concise and front-loaded with the key 'READ:' indicator. There is zero redundancy, and every word contributes to conveying the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, this description is too brief. It omits details about response format, parameter relationships (e.g., whether campaign_ids and adgroup_ids are ANDed or ORed, whether 'project' is required), and the nature of the 'retarget conditions'. The description is a minimal placeholder rather than a complete guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%), with only 'project' having a description. The description text adds 'for campaign/adgroup', which gives some semantic context to adgroup_ids and campaign_ids, but it says nothing about 'limit' or the 'project' parameter's use in read context. This is insufficient compensation for the schema's sparse parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as a read of audiencetargets for campaign/adgroup, and the parenthetical 'retarget conditions on groups' adds specificity that distinguishes it from sibling tools like direct_list_retargeting_lists. However, it relies on the tool name for the verb 'list' and uses an API-style reference ('audiencetargets.get') rather than plain language, slightly reducing clarity for unfamiliar users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that mutation of audience targets is handled by direct_add_audience_targets or direct_audience_targets_state, nor does it state any prerequisites or exclusions. The 'READ:' prefix implies read-only usage, but this is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'READ-ONLY', which conveys safety, but it does not disclose output format, pagination, error behavior, or any other operational details that an agent would need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that state the purpose and a key behavioral trait. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is minimal for a 3-parameter tool. It does not explain what the response contains, how the parameters interact, or any constraints (e.g., whether campaign_id is optional). This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'project' having a description. The tool description mentions 'campaign(s)' but does not explain the relationship between campaign_id and campaign_ids, their formats, or how they are used. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('ExcludedSites') scoped to 'campaign(s)', clearly distinguishing it from sibling tools like direct_set_excluded_sites. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The READ-ONLY tag hints at a read operation, but the description does not mention when to prefer this over other getters like direct_get_negatives or direct_get_group_negatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions the tool is an 'OPTIONAL READ' and that it is 'disabled with setup hints' by default, which gives some behavioral context. However, it does not disclose potential side effects, permissions needed, or behavior when disabled beyond vague hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and to the point. It packs setup requirements, a differentiator, and default state without excessive verbosity. However, it uses jargon and lacks formal structure, which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description leaves significant gaps: no explanation of what the tool returns, what the 'days' parameter means, or practical usage examples. It also lacks details on how the setup hints behave or what exactly the SQL should output. For a tool with no output schema and minimal annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'days' with no description, and schema description coverage is 0%. The tool description does not mention 'days' at all, so it provides no meaning beyond the bare schema definition. Since coverage is low, the description should compensate, but it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool performs an 'OPTIONAL READ' of the product database using custom SQL, distinguishing it from 'soft Metrika Conversions'. While the exact resource is somewhat vague ('your product DB'), the verb and scope are specific enough to differentiate it from sibling tools like reporting or campaign management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit setup requirements and default state: 'Enable PRODUCT_ATTRIBUTION_ENABLED=true and set PRODUCT_ATTRIBUTION_SQL or use built-in only if you customized it.' It also notes this is 'not soft Metrika Conversions,' which helps exclude an alternative. However, it does not explicitly state when to prefer this over other attribution methods or sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the absence of annotations, the description carries the full burden for behavioral disclosure. It adds useful context with 'READ' and 'Polls offline report,' indicating a read-only and asynchronous operation. But it does not explain the polling lifecycle, return format, or any prerequisites, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded, using fragments to convey distinct pieces of information. It is appropriately sized for a simple read tool, but the cryptic language (e.g., 'RSYA junk') slightly reduces its accessibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, yet the description does not cover output format, default date ranges, or how to handle the offline report polling. Given the presence of many sibling report tools, more context is needed to ensure correct usage and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description must compensate. It only conceptually covers the 'breakdown' parameter and adds a tip about Placement, but it ignores limit, date range, campaign_ids, and project (whose schema description is in Russian). This is insufficient for an agent to correctly populate all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a READ operation for a performance report with a breakdown dimension and lists several valid breakdown values. However, jargon like 'Soft Conversions' and 'RSYA junk' may confuse an agent, and it does not explicitly distinguish it from sibling report tools like direct_report_raw or direct_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an in-tool parameter recommendation ('For RSYA junk use Placement') and notes that it polls an offline report, implying a use case. However, it does not state when to prefer this tool over sibling report tools or give any exclusions, so guidance is only partially developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the critical allow_write=true requirement (dry run vs live mutation) and the Network SERVING_OFF default. However, it does not mention prerequisites, reversibility, rate limits, or what happens to existing strategy settings, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, packing key facts into a compact list of hints. No redundant words or filler. However, the telegraphic style sacrifices readability and some information is presented in a fragmented way (e.g., 'Unified/Text auto.'), making it less structured than an ideal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters and no output schema, the description is incomplete. It does not describe return values, error behavior, prerequisite conditions (e.g., campaign state), or the full effect of the operation. The few contextual hints are useful but leave large gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, but the description adds little beyond what is already in the schema. It maps 'GoalId' and 'WeeklySpendLimit' to parameters, and provides extra guidance on goal selection, but fails to explain dry_run, project constraints, bid_ceiling_rub, or campaign_id semantics, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly signals a write operation for setting a maximum conversion rate strategy, referencing the specific strategy type (WB_MAXIMUM_CONVERSION_RATE) and key fields (GoalId, WeeklySpendLimit). However, it lacks an explicit verb phrase like 'sets' and the cryptic notation requires domain knowledge to fully parse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some usage context (applicable to Search campaigns, Unified/Text auto, network serving off by default) and a selection heuristic ('Prefer payment goals over form alone'). But it does not explicitly state when to choose this tool over siblings like direct_set_strategy or direct_set_network_weekly_budget, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It does declare 'READ:' to signal a non-mutating operation, and 'snapshot' implies a point-in-time view. However, it does not disclose the exact account format, limitations of the sample, or any requirements, so transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the read operation and the target data. No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params, no output schema). The description gives a reasonable purpose but lacks any mention of response shape or relationship to other account-level tools. Given the system does not provide annotations or an output schema, the description should offer more context for the agent, though it is sufficient for a minimal read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so schema description coverage is trivially 100%. Per the rubric, a zero-parameter tool gets a baseline of 4; the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'READ:' and specifies the exact resources (client financial flags, campaign Funds/SharedAccountFunds), with 'cabinet balance snapshot' clarifying the output kind. It distinguishes the purpose from siblings like direct_list_campaign_funds by combining financial flags with a balance snapshot, though the phrase 'sample' is slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when this tool should be chosen over siblings such as direct_account_summary or direct_list_campaign_funds. The description only states what it does, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the tool is a write operation, but provides no context on consequences, irreversibility, required permissions, or return behavior. The 'allow_write=true' hint is more about a parameter than a behavioral guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key operation ('WRITE: feeds.delete by ids') and includes the critical flag 'allow_write=true'. It is efficient, though it omits some important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is under-specified. It does not disclose what happens on success/failure, whether the delete is permanent, or the role of dry_run. The existing text leaves significant gaps for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only allow_write having a schema description. The tool description mentions 'by ids' but does not explain the dry_run parameter or further elaborate on ids. It adds minimal value beyond the schema for the required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'feeds.delete by ids' with a 'WRITE:' prefix, making it unambiguous that this tool deletes feeds by their IDs. It distinguishes from sibling read tools like direct_list_feeds and other write tools like direct_delete_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting feeds by IDs, and the 'WRITE:' prefix indicates it is a mutation tool. However, it does not explicitly state when to use this tool instead of alternatives, nor mention exclusions or prerequisites beyond 'allow_write=true'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the write intent via 'WRITE:' and explains that allow_write=true is required to mutate live cabinets, implying a dry-run mode otherwise. However, it does not describe other behavioral aspects such as side effects, validation errors, or the behavior of the dry_run parameter, which is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: it front-loads the action ('WRITE:'), lists the enum values, and then gives the key parameter hints. Every phrase earns its place with no fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations, but the description covers only a fraction of the operational context. It does not explain return values, error conditions, prerequisites (e.g., campaign existence), or detailed effects of the strategy preset. While simple, the description is insufficient for an agent to safely invoke the tool without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (project and allow_write have descriptions), so the description must compensate. It mentions weekly_rub, goal_id, and bid_ceiling as 'as needed,' adding some semantic hint, and repeats allow_write=true. However, it does not explain how these relate to specific modes, nor does it clarify campaign_id or dry_run. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a WRITE operation to set a Search strategy preset, and the enum values in the schema—highest_position, max_conv, max_clicks_network, serving_off_search—are explicitly listed. This distinguishes it from sibling set_* tools like direct_set_max_conv or direct_set_daily_budget, though it could be more explicit about the resource (e.g., 'for a campaign').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage context. It says 'weekly_rub/goal_id/bid_ceiling as needed' but does not explain when these are needed or how they relate to specific modes. It also does not mention when to use this tool instead of alternative strategy setters or other campaign update tools, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does indicate this is a write operation via 'WRITE:' and notes that allow_write must be true, which is a key behavioral requirement. However, it does not mention permissions, side effects, reversibility, return values, or what happens with dry_run, which is significant for a mutation tool. The description adds some context but leaves major behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise, packing essential information into a single line. It is front-loaded with 'WRITE: feeds.add' immediately signaling the operation type. Every word contributes meaning, with no filler. The structure is highly efficient for an API-focused tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is incomplete. It explains the primary input modes and business_type/source_type, but omits critical context such as what the tool returns, how dry_run behaves, whether the operation is reversible, and any preconditions. For a write operation with multiple parameters, this level of information is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is very low (14%), with only allow_write documented. The description compensates by clarifying the semantics of key parameters: name + url for HTTP feeds, file_path for uploads, business_type with 'RETAIL|…' (indicating an enum-like set), source_type as URL|FILE, and the requirement for allow_write=true. This adds substantial meaning beyond the schema. However, dry_run is not mentioned in the description, so it does not cover all seven parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a write operation for adding feeds ('WRITE: feeds.add'), specifying that it can use a URL or file_path. The verb 'add' is implicit in 'feeds.add' and the tool name, making it distinct from sibling tools like direct_delete_feeds or direct_list_feeds. However, it does not literally say 'adds a feed' in plain language, relying on the API method name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage context by distinguishing the two input modes: 'name + url (HTTP feed) or file_path (upload)'. This implies when to use URL vs file upload. However, it does not explicitly state when to use this tool versus alternatives like direct_upload_advideo or direct_add_sitelinks, and no exclusions or conditions are mentioned. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that this is a write operation and that allow_write must be true, but it does not explain the destructiveness of 'delete', reversibility of 'suspend'/'resume', or return behavior. The dry_run safety mechanism is only in the schema, not highlighted in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence. It front-loads 'WRITE' and immediately follows with the key actions and target. No wasted words; every token contributes to understanding core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description is under-complete. It omits expected return behavior, error semantics, and the purpose of dry_run. The presence of safety params in the schema is not echoed in the description, leaving the agent without enough behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description needs to compensate. It clarifies that 'ids' are the target and lists valid actions, which helps for the required params. However, it does not explain the 'dry_run' parameter (undocumented in schema) or the 'project' restriction beyond what schema already says. Value added is limited to the two core parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation type ('WRITE') and the specific resource ('audiencetargets') with three explicit actions ('suspend|resume|delete') and the targeting mechanism ('by ids'). This distinguishes it from sibling tools like direct_list_audience_targets or direct_add_audience_targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WRITE' prefix signals a mutation tool, and the action list implies when to use it (changing state of existing audience targets). However, it does not explicitly contrast with alternatives or state when not to use it. The guidance is clear but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'WRITE' and 'allow_write=true', which already implies mutation. It does not warn that deletion is destructive, irreversible, or that dry_run should be used for a dry plan. The description adds minimal behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: 'WRITE: bidmodifiers.delete by ids. allow_write=true.' Every word is informative, with no fluff or redundancy. It efficiently communicates the core operation and a key prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is incomplete. It lacks critical context such as the destructive nature of deletion, the role of the project parameter (required for write per schema), and the availability of a dry_run preview. The agent cannot fully assess side effects or prerequisites from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (project and allow_write are described, ids and dry_run are not). The description repeats 'by ids' but does not clarify the meaning of the IDs (e.g., where they come from) or the purpose of dry_run. It adds little value beyond the schema, failing to compensate for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'bidmodifiers.delete by ids' — a specific verb (delete) with a specific resource (bidmodifiers) and method (by ids). This distinguishes it from sibling tools like direct_list_bidmodifiers and direct_set_bidmodifiers, so the agent can immediately understand the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it's a delete operation for bid modifiers, and the 'allow_write=true' requirement gives a prerequisite for actual mutation. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to use direct_set_bidmodifiers or direct_list_bidmodifiers), nor does it mention the optional dry_run parameter as a safe preview mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses a read-only behavior via the 'READ:' prefix and hints at return fields ('ids + text'). However, it does not explain filtering behavior, pagination, or whether an empty ids parameter returns all callouts. It adds some context beyond the schema but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the read nature and the resource. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description must provide sufficient context. It identifies the resource and hint at output fields, but omits behavior for optional parameters, response format, and any constraints. For a simple list tool, it is minimally acceptable but leaves significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It mentions 'ids' but not as a filter parameter, and does not explain the 'limit' parameter or how 'ids' controls the result set. The parameter names are self-explanatory to a degree, but the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a read operation for the callouts library, using 'READ: adextensions.get' and specifying the content as 'ids + text'. This distinguishes it from sibling list tools like direct_list_sitelinks and direct_list_advideos, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives such as direct_add_callouts or direct_attach_callouts, nor does it mention any exclusions or prerequisites. The context is implied by the name and short description, but there is no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It clearly states READ-ONLY, which is valuable, and hints at a nuance with 'ACCEPTED OFF may be pool, not ban', but this is vague. It omits behavior such as pagination, return format, auth requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is concise and front-loaded, but the 'UNIFIED' clause consumes space without conveying clear meaning. The overall structure is acceptable but the cryptic jargon reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete. It does not explain the return structure, how filters interact, or how to interpret the 'ACCEPTED OFF may be pool, not ban' behavior. An agent would likely need additional context to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds minimal semantic value beyond naming the filters. It does not clarify that limit controls page size, how IDs are combined, or what 'project' values are valid beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('ads') with clear filter dimensions (campaign_ids/adgroup_ids/project). This distinguishes it from sibling tools like direct_get_ad or direct_list_adgroups, and the READ-ONLY label further clarifies its non-mutating nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have campaign/adgroup/project identifiers to list ads), but it does not explicitly mention alternatives or exclusions. The cryptic 'UNIFIED: ACCEPTED OFF may be pool, not ban' adds no practical usage guidance and may confuse an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'READ-ONLY', which is useful given no annotations are provided, but the verb 'list' already implies a read operation. It does not disclose whether at least one filter is required, how filters combine, or what happens when no filters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short fragments, front-loads the core purpose, and contains no unnecessary words. It is highly concise while still conveying the primary scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the presence of 5 optional parameters, the description is too minimal to fully support correct invocation. It fails to clarify default behavior, filter conjunction semantics, or valid values for states, leaving important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema description coverage and 5 parameters, the description should compensate by explaining limit and states, but it only names three of the five parameters. It does not clarify valid states, the relationship between filters, or the meaning of omitting filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists keywords and specifies the three filtering contexts (campaign_ids, adgroup_ids, project). This differentiates it from sibling list tools like direct_list_campaigns and direct_list_adgroups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools such as direct_get_keyword_bids or direct_get_negatives. It only mentions filtering contexts, but does not explain preconditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the write nature and required allow_write flag, but lacks detail on reversibility, dry-run behavior (though schema covers this), or side effects beyond mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The 'WRITE:' prefix immediately categorizes the operation, and every phrase contributes (mode, phrase formatting, allow_write). It is efficient though slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter write tool with no annotations and no output schema, the description is too sparse. It does not explain how to specify target campaigns (campaign_id vs campaign_ids), the purpose of dry_run, or the project parameter, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful meaning for 'phrases' (formatted as Direct expects, avoid bare '+') and 'allow_write' (must be true for mutation), which schema does not fully provide. However, it leaves campaign_id, campaign_ids, and project unexplained, and schema coverage is low (29%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a write operation for campaign-level negative keywords, with the 'WRITE:' prefix distinguishing it from read tools and the 'campaign' qualifier differentiating it from group-level alternatives. It is specific but does not explicitly contrast with sibling tools like direct_set_group_negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the 'WRITE' prefix and mode=merge|replace, but it offers no explicit guidance on when to choose this tool over alternatives or exclusions. It gives operational hints (allow_write=true) but not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It discloses that this is a WRITE operation and that the API does not support REMOVE, plus states allow_write=true as a required flag. However, it does not explicitly state that setting goals will overwrite existing ones, which is a critical behavior for a SET operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. However, the final sentence 'Prefer payment-heavy; avoid max-conv on form alone' is somewhat disconnected and could be considered extraneous for tool invocation, though it does provide useful guidance on choosing goals.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema and low schema coverage, the description is incomplete. It does not explain what happens when the tool executes (e.g., whether existing goals are replaced), how 'dry_run' interacts, or any prerequisites or error conditions. The 'no REMOVE' limitation is noted, but overall an AI agent would lack sufficient context to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), so the description must compensate. It does add meaning for the 'goals' parameter by specifying the array structure of {goal_id, value_rub} and that weights are in rubles. However, it does not explain 'dry_run' or 'campaign_id' beyond the schema, and it repeats 'allow_write=true' which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a WRITE operation for PriorityGoals, and provides the structure of the goals parameter. It differentiates from direct_set_max_conv by mentioning 'no REMOVE in API' and by advising to 'avoid max-conv on form alone', though this is more about goal selection than tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to set priority goals via the WRITE label and allow_write=true, but it does not explicitly state when to use this tool versus alternatives like direct_set_max_conv. The advice 'Prefer payment-heavy; avoid max-conv on form alone' is about goal values, not tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the write nature via 'WRITE' and the 0=exclude semantic, which adds some behavioral context. However, it repeats the allow_write requirement already present in the schema and does not discuss overwrite/merge behavior, error handling, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, front-loaded with 'WRITE' and the data format. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the one-liner is insufficient for a 4-parameter mutation tool. It omits when to use this tool, what the response looks like, and how dry_run/project interact, leaving critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the important '0=exclude' semantic for bid_modifier, going beyond the schema's numeric range. However, it mostly repeats schema details (array structure, allow_write) and does not compensate for the 50% schema coverage by clarifying dry_run or project parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'WRITE: bidmodifiers.set' with the payload structure and bid_modifier range, clearly identifying the operation and resource. It distinguishes from sibling tools by naming the bidmodifiers resource and the set operation, even though it doesn't describe the exact target entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like direct_set_device_bid_modifiers or direct_set_retargeting_bid_modifier. The description only states the operation and write guard, leaving tool selection and any preconditions unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses a key behavioral trait ('READ-ONLY') and an output characteristic ('Includes RegionIds'). However, it does not mention pagination, error behavior, or authentication. For a simple read-only list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a fragment, front-loading the purpose and adding only useful specifics (RegionIds, READ-ONLY). Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 parameters and no output schema, the description provides the essential purpose and safety hint, but it does not explain the response structure beyond mentioning RegionIds, nor does it clarify pagination via the limit parameter. Given no annotations, more detail would improve completeness, but it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'project' has a description). The description adds semantic value by indicating that 'campaign_ids' and 'project' are alternative filters ('for campaign_ids or project'). However, it does not clarify the meaning of 'limit' or the relationship between the filters beyond 'or', leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('ad groups'), and clarifies the filtering scope ('for campaign_ids or project'). It distinguishes from sibling list tools by naming a distinct entity, though it doesn't explicitly compare to siblings. The mention of 'Includes RegionIds' adds slight ambiguity but doesn't detract from 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need ad groups for specific campaigns or a project, but it does not explicitly state when to prefer this tool over alternatives like direct_list_campaigns or direct_list_ads. No exclusions or alternatives are mentioned, so guidance is limited to the implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of revealing behavior. It signals read-only via 'READ', but does not disclose return format, error behavior, or what happens with invalid names. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with an example list. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter dictionary getter, the description is adequate: it states the purpose and gives examples. However, it lacks details about exact string matching, case sensitivity, response structure, and error handling, which limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'names' as 'DictionaryNames list', but the description adds concrete valid examples (SupplySidePlatforms, AudienceCriteriaTypes, etc.), giving the agent a clearer sense of what to pass. This meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('READ') and resource ('dictionaries.get'), and provides concrete examples of valid DictionaryNames. This distinguishes it from sibling tools that operate on campaigns, ads, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says to supply DictionaryNames and gives examples, but offers no guidance on when to use this tool vs. alternatives, nor any exclusions or prerequisites. Usage context is minimally implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is READ-ONLY, notes that conversions use 'soft Metrika' definitions, and warns that it may poll for about 1 minute. With no annotations provided, these behavioral details are valuable and go beyond a simple statement of purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, conveying key information in four short sentences. Every sentence adds value: purpose, conversion definition, read-only status, and latency warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, read-only safety, conversion nuance, and latency, which is helpful for a report tool. However, with no output schema and no mention of response structure or parameter filtering behavior, it is only partially complete for an agent to fully understand invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only references 'date range' and lists metrics, but does not explain the parameters campaign_ids or include_archived. The input schema provides descriptions for project and date formats, but with 60% coverage, the description compensates incompletely, leaving parameter semantics largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a campaign performance report, listing specific metrics (cost, clicks, impressions, CTR, CPC) and a date range. It distinguishes itself from sibling report tools like direct_report_raw and direct_report_breakdown by focusing on standard campaign metrics, though it lacks an explicit verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving campaign performance metrics over a date range, but it provides no explicit guidance on when to choose this tool over siblings like direct_report_raw, direct_report_breakdown, or direct_report_search_queries. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing write behavior. It explicitly marks the operation as 'WRITE' and notes that allow_write=true is required, which gives some safety context. However, it does not explain that existing bids will be overwritten, whether changes are reversible, or how dry_run interacts with allow_write. This is minimal but not completely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence that packs the operation type, target resource, currency, API method, required fields, and a key precondition. There is zero fluff; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema and only partial schema coverage, the description is incomplete. It omits important context like the effect of dry_run, the role of the project parameter, the exact bid array format, and potential side effects. While it does flag WRITE and allow_write, it leaves significant gaps that could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (project and allow_write have descriptions; bids and dry_run do not). The description adds little beyond the schema: 'keyword_ids required' is already encoded in the schema's required fields, and 'allow_write=true' is present in the schema description. It does not clarify the structure of the bids parameter or the purpose of dry_run, which are undocumented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set', the resource 'keyword search bids', and the currency (₽), which distinguishes it from sibling tools that set bid modifiers or keyword states. It also names the underlying API method keywordbids.set, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WRITE:' prefix and 'keyword search bids' phrasing imply the tool is for setting keyword bid amounts, but no explicit exclusions or alternative tools are mentioned. For example, it does not contrast with direct_set_bidmodifiers or direct_set_keyword_states, so an agent must infer when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 labels the operation as 'WRITE' and mentions allow_write=true, but does not disclose the dry-run behavior, potential side effects, or required permissions. The schema description for allow_write explains dry plan, but that is not in the tool description and the description itself does not elaborate on safety or mutation consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the action and resource. It uses code-like notation that is efficient, though the 'allow_write=true' hint is somewhat redundant with the schema. Overall, it avoids fluff and communicates the core purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is far too minimal. It does not explain return values, error behavior, the role of dry_run, or how the operation fits into the broader workflow. For a write tool with 4 parameters, this lacks essential context for an agent to use it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a compact item structure with optional markers, which partially compensates for the 50% schema coverage. However, it does not explain the meaning of user_param1/2 or strategy_priority beyond their names. The schema already defines types and enums, so the description adds marginal value by showing the intended array structure but lacks semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: keywords.update' which clearly identifies the action and resource. It specifies the exact fields to update (user_param, strategy_priority) and distinguishes from the sibling tool for autotargeting. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'For AT use set_autotargeting', which is a direct alternative for a different resource. While it doesn't enumerate all sibling tools for keyword updates, the narrow purpose (user_param/strategy_priority) implies when to use it. More explicit exclusions would improve, but the AT note provides concrete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'READ' and the listed return types (SearchBid/ContextBid/AuctionBids) disclose the non-destructive nature and expected output. But it omits behaviors like pagination, limit semantics, or what happens with no filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with a clear READ prefix and no filler. All words earn their place, efficiently conveying method, resource, data types, and filter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the core purpose and filter inputs, but lacks details on default behavior (e.g., no filters), limit effects, and return format. It's adequate for a simple getter but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'project' has a description). The description mentions keyword_ids and campaign_ids/project but does not explain the 'limit' parameter or clarify the optionality semantics. It adds some value by indicating 'and/or' combination, but insufficiently compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a READ operation for keyword bids (SearchBid/ContextBid/AuctionBids), with a specific resource. It distinguishes from sibling direct_set_keyword_bids by using 'READ' and naming the keywordbids.get method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on which parameters to pass ('keyword_ids and/or campaign_ids/project'), which helps select and invoke. However, it doesn't state when to prefer this over alternatives like direct_list_keywords or direct_get_campaign, nor does it mention any exclusions or fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 state 'READ-ONLY,' which is a key safety trait. However, it does not explain how the include_archived parameter affects behavior, what 'live' means, or any details about permissions or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and safety profile efficiently. However, 'projects.json' is somewhat cryptic, and the structure could be improved by separating the mapping rules from the live list explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is thin. It does not explain the output format, the role of the include_archived parameter, or how this relates to sibling tools like direct_register_project_campaign. The missing parameter information and lack of differentiation guidance make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to mention the include_archived parameter. The phrase 'non-archived list' only hints at the default behavior, leaving the parameter's effect and semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Show' and identifies a unique resource: 'campaign→project mapping rules (projects.json) + live non-archived list.' This clearly distinguishes it from sibling tools like direct_list_campaigns or direct_register_project_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'READ-ONLY,' which clearly signals that this tool is for viewing without mutation. It provides a clear context for when to use it, though it does not explicitly name alternatives or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses this is a write operation and hints at a behavioral consequence ('May need moderate after'), but it does not explain side effects, authentication needs, or behavior when dry_run is enabled. The disclosure is minimal but present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the write nature, includes a compact parameter format, and notes moderation. Every element adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is too brief. It lacks essential details such as project requirements, dry_run behavior, return values, or prerequisites. The short hints are insufficient for an agent to safely and fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, so the description must compensate. It provides a helpful format for the main parameter ad_hrefs=[{ad_id, href}] and mentions allow_write=true, but does not explain dry_run or moderate_after beyond the hint. The schema covers project and allow_write, so partial compensation is achieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates TextAd Href (landing/UTM) for ads, using a specific verb and resource. The 'WRITE:' prefix and the parameter format distinguish it from sibling tools like direct_update_ad_text, which updates ad text instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (updating ad hrefs) and includes relevant context like the write intent and potential moderation, but it does not explicitly contrast with sibling tools or state when not to use it. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It labels the operation as 'WRITE', describes the UI effect, and implies irreversibility by suggesting suspend for reversible cases. But it does not disclose potential side effects, permissions, or what happens in dry_run mode, which could be important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: one line with a clear action prefix, a brief effect, and a usage note. Every part earns its place, and the critical information ('WRITE') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a write operation with no output schema and no annotations, so the description needs to cover behavior more fully. It lacks information about dry_run behavior, return values (if any), or when to use archive vs unarchive (though it does mention suspend). The sibling set includes many campaign-related tools, and this description does not fully situate the tool within that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (project and allow_write are described), but the description adds no value beyond that: it only restates 'allow_write=true' which is already in the schema. The dry_run and campaign_ids parameters are left unexplained in the description, and the description does not clarify their role in archiving.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'archive' and the resource 'campaigns', with a clarification of the effect: 'remove from active UI'. It differentiates from the sibling tool 'direct_suspend_campaigns' by explicitly noting the preference for suspend when reversible stop is desired, and from 'direct_unarchive_campaigns' by the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Prefer suspend for reversible stop' gives explicit guidance on when to use an alternative tool (direct_suspend_campaigns). It also hints at the irreversible nature of archiving. However, it does not mention when to use unarchive or other context like requiring the campaign to be active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'READ:' prefix signals a non-mutating operation, which is useful given no annotations are provided. However, the description gives no detail about return format, pagination, or behavior with invalid timestamps or empty results, leaving transparency incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It front-loads the read intent and API method, then explains the core functionality in a compact phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple change-check tool, the description covers the main purpose but omits the role of the project and campaign_ids parameters, which are likely filters. Without an output schema, it also leaves the exact return value ambiguous, though 'which campaigns changed' gives a general sense.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes project and timestamp, and the tool description adds that timestamp can be in ISO or API format. With 67% schema coverage, the description provides some additional meaning for the timestamp parameter but does not clarify the optional campaign_ids filter or its effect on the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads changes to campaigns since a given timestamp, using a distinct 'READ:' prefix and the API method name changes.checkCampaigns. It distinguishes from sibling tools like direct_list_campaigns by focusing on detecting changes rather than listing or fetching. The verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting campaign modifications since the last check timestamp, but it does not explicitly state when to prefer this over direct_list_campaigns or direct_get_campaign, nor does it mention any exclusions or alternatives. The guidance is implicit in the wording 'which campaigns changed since Timestamp' rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly labels the operation as 'READ', indicating a non-mutating behavior, and scopes it to ad group negatives. However, it does not disclose other behavioral aspects such as pagination, permissions, or parameter interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action ('READ') and contains no filler. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about the return format, how filters combine, and what the 'limit' applies to. The current one-liner is not enough for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only the 'project' parameter has a description). The tool description adds no parameter specifics—it does not explain 'limit', 'adgroup_ids', or 'campaign_ids' or their relationships. The adgroup context is inferred from the name, but that is not sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('READ') and specifies the exact resource ('ad group NegativeKeywords'). It also differentiates from campaign-level negatives, distinguishing it from sibling tools like direct_get_negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states that this tool handles ad group negatives and that they are separate from campaign-level negatives, giving an implicit when-not to use it. However, it does not explicitly name an alternative tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the local, non-API nature and the dry_run/allow_write gating. However, it does not mention what happens if the project key is missing, whether existing data is overwritten, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using three short fragments that front-load the action and provide essential context without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple local write tool with no output schema or annotations, the description covers the core operation and write gating adequately, but it omits return values and edge-case behavior (e.g., handling of existing entries), leaving room for misinterpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 25% description coverage, but the description adds meaning for project and campaign_id by explaining they are used as a key-value pair in projects.json. allow_write is already explained in the schema, while dry_run is only hinted at via 'or dry_run' without clear semantics, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('WRITE local'), resource ('projects.json'), and purpose ('pin campaign_id under project key'). The explicit 'No Direct API' distinguishes it from the many sibling direct_* tools that call the Direct API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for local registration rather than API operations, but it does not explicitly name alternatives or provide clear when-to-use/when-not-to-use guidance. The 'No Direct API' exclusion helps differentiate, but no specific sibling is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It explicitly labels the operation as WRITE and mentions the allow_write guard and project scoping, which adds some transparency about authorization. However, it omits details about return values, reversibility, or the effect of dry_run, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the action and key requirement. There is no fluff, and every word adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too sparse for a mutating tool. It does not explain the dry_run parameter's role, the response format, or potential side effects, leaving agents without critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, with project and allow_write described in the schema. The description repeats the allow_write=true requirement but adds no meaning for keyword_ids, action, or dry_run, which remain undocumented in both schema and description. It fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suspends or resumes keywords by ID, with the 'WRITE:' prefix indicating a mutating operation. This distinguishes it from sibling tools like direct_suspend_campaigns (campaigns) and direct_set_keyword_bids (bids), leaving no ambiguity about the resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that a write operation requires allow_write=true and project scope, giving a clear precondition for invocation. It does not name alternative tools, but the WRITE prefix and the focus on keyword state changes imply when to use this tool over related ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that this is a write operation, that the region list is absolute, and that allow_write=true is required, but it does not explicitly state that existing regions will be overwritten (though 'absolute' implies it), nor does it mention permission requirements or the dry_run behavior that is present in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with an example, leading with the operation type 'WRITE'. Every element earns its place, and the example adds immediate clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and the safety flag, but given no output schema and no annotations, it should more explicitly mention the replacement behavior and note that dry_run returns a plan. The example helps, but the tool is a mutation that would benefit from a bit more context about side effects and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps to core parameters via 'specific ad groups' and 'RegionIds', and the example clarifies that negative integers denote negative regions. However, it does not explain dry_run or project, and with schema description coverage at 50%, the description only partially compensates for the missing parameter documentation. allow_write is mentioned explicitly, but dry_run remains undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'WRITE: set absolute RegionIds on specific ad groups (positives + negatives)' with an example [225,-11010]. It identifies the verb (set), resource (ad group regions), and scope (absolute, including positive and negative IDs), which distinguishes it from sibling tools like direct_set_region_excludes and direct_get_group_negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to set absolute region IDs on ad groups) and mentions the allow_write=true requirement, but it does not explicitly contrast with alternative tools or state exclusions. There is no 'when not to use' guidance, leaving the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is READ-ONLY, which is a key safety behavior, and it mentions the optional last-N-days cost calculation. However, with no annotations provided, it does not describe the response format, potential errors, or any operational constraints. The READ-ONLY label adds some value but not enough to fully compensate for the missing annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and ends with READ-ONLY. It contains no filler words, and every phrase adds essential information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only summary with one optional parameter, the description covers the essential behavior and output content (counts by project/state and optional cost). However, without an output schema, it does not detail the response structure, and the term 'cabinet' is not explained, leaving a minor gap for agents unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'days' parameter as 'optional last-N-days cost', providing meaning that the schema lacks (coverage 0%). It clarifies that days is optional and tied to cost calculation, which is useful for invoking the tool correctly. The schema's min/max constraints further supplement this semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it produces a short cabinet summary with counts by project/state and optionally includes last-N-days cost. The READ-ONLY label further distinguishes it from mutating sibling tools, and the specific resource scope (counts by project/state) differentiates it from other reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention other reporting or summary tools, nor does it provide exclusions or recommended use cases beyond the implied 'short summary' nature. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The READ prefix explicitly indicates a non-mutating operation, which is useful. However, with no annotations provided, the description carries the full burden for behavioral disclosure, and it adds no context about authentication, error behavior, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the operation type and resource. Every word contributes value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description adequately lists the returned fields. It could mention that it refers to the current authenticated client, but the tool name and context make that apparent. Overall, it is complete enough for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the schema, so the baseline is 4. The description does not need to explain parameters since none exist, and it adds no parameter-related meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'READ:' and explicitly names the API method 'clients.get', followed by a clear list of returned data fields (login, currency, VAT, shared account flags, restrictions snapshot). This is highly specific and distinguishes it from sibling tools like account_summary or account_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention use cases, exclusions, or provide context for selection among the many sibling read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It labels the operation as 'READ', implying a non-mutating action, which is a key behavioral trait. However, it doesn't disclose other behaviors like error handling, response format, or access requirements, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the operation type ('READ') and includes the key fields. Every word contributes, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no annotations, the description covers the essential operation, return fields, and ID type. However, it omits potential edge cases or error behavior, but given the tool's simplicity, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal detail (ad_id anyOf number/string). The description adds a specific clarification that 'ad_id may be int64 string', which is a useful nuance beyond the schema. However, this is the only parameter-related information, and the description doesn't elaborate on how to format the parameter or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads full ad detail and lists specific fields (titles, text, href, image, state), making the purpose clear. The verb 'READ' and resource 'ad' distinguish it from sibling tools like direct_list_ads or direct_get_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. The 'READ' prefix implies it's for retrieving a single ad's details, but it doesn't mention when to choose it over direct_list_ads or direct_get_campaign, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the critical READ-ONLY behavior and specifies the campaign-level scope. Yet it does not mention pagination, error handling, or what happens when no results exist. For a simple read tool, this gives basic but somewhat limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence that delivers the core purpose, scope, and safety property with zero filler. It is appropriately brief and fully earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers the essential purpose and scope. However, the lack of any guidance on parameter semantics, optionality, or the confusing 'Write' note in the schema leaves notable gaps. The description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description itself adds no explanation of the parameters. The schema only provides a description for 'project' (in Russian) and leaves 'campaign_id' undocumented, resulting in 50% coverage. The description fails to compensate for this gap, and the schema's 'Write' instruction for a read-only tool adds confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and unambiguously identifies the target resource as 'campaign-level negative keywords'. It also explicitly differentiates from 'Group-level negatives', directly distinguishing this tool from sibling tools like direct_get_group_negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'Group-level negatives are separate' gives a clear exclusion and implies that a different tool should be used for group-level negatives. The 'READ-ONLY' qualifier further signals that this tool is for reading only, not for modifications. However, it does not explicitly name the alternative tool or provide a 'when to use' scenario beyond the obvious from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'READ' (read-only) and warns that 'Offline report may poll ~1 min', which is a valuable behavioral trait. It also notes the report is 'Top by cost', disclosing default ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with every clause earning its place: the report name, the data type (real user queries), the metrics (cost/clicks/CTR/CPC + conversions), latency (~1 min), and ordering (top by cost). It is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only 17% parameter schema coverage, the description provides a solid high-level summary of the report contents and behavior, but it omits parameter semantics and the return structure. An agent could invoke the tool based on this description but would need to guess details about filters and result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (6 parameters, only 'project' described), which is low (<50%). The description does not compensate by explaining any parameters such as limit, date ranges, min_clicks, or campaign_ids, leaving the agent to infer semantics from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the imperative 'READ:' and explicitly names the resource as 'SEARCH_QUERY_PERFORMANCE_REPORT', making it clear this tool reads a search query performance report. It further distinguishes itself from sibling report tools by highlighting 'real user queries (not just Criterion keys)' and listing specific metrics (cost/clicks/CTR/CPC + conversions), which is highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by calling this a 'READ' operation for a specific report type, and the 'not just Criterion keys' hint suggests a difference from other report tools. However, it does not explicitly state when to use this tool versus alternatives like direct_report or direct_report_breakdown, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the write nature ('WRITE') and warns about an API 4004 conflict with WeeklySpendLimit, which is valuable. However, it omits details like reversibility, permission requirements, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the verb (WRITE) and resource, then adds critical constraints. Every phrase earns its place: the micros unit, mode, API conflict, and allow_write requirement. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the most essential aspects: mutation, units, mode, a key error condition, and the write-enabling flag. It doesn't explain dry_run's effect, but the schema's allow_write description partially covers the dry-run behavior. For a focused write tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), so the description compensates by clarifying that daily_rub is in micros and listing the mode enum values. It also emphasizes allow_write=true, a critical requirement. However, it leaves dry_run and campaign_id semantics to inference, though these are relatively self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a write operation for the campaign daily budget in rubles (micros), specifying the mode (STANDARD|DISTRIBUTED). It distinguishes from sibling weekly budget tools by explicitly targeting 'DailyBudget'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like direct_set_network_weekly_budget or direct_set_search_weekly_budget. It only includes a constraint about not sending it with WeeklySpendLimit, but lacks explicit selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the write nature, return value, and suggests asynchronous polling, but omits details on permissions, file requirements, or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, densely packed with key information without redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the terse clarity, the description leaves out essential details about the required 'name' parameter and the 'dry_run' flag. Given no output schema and low schema coverage, this is a notable gap for an upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only allow_write has a schema description). The description clarifies that file_path and video_base64 are alternative inputs and that allow_write must be true, but it fails to explain the required 'name' parameter or the 'dry_run' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: advideos.add' which clearly identifies a write operation to add a video. It specifies the input methods (file_path or base64), distinguishing it from sibling tools like direct_upload_adimage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to poll status with list_advideos, providing a clear post-usage step, and requires allow_write=true. However, it doesn't explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing mutation. It does label the tool as 'WRITE' and instructs 'allow_write=true', which is useful. However, it omits other behavioral details like dry-run behavior or reversibility, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with four terse fragments that pack essential information. It is front-loaded with the purpose and includes the critical allow_write requirement without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, yet the description is minimal. It covers the core action and the allow_write requirement, but leaves dry_run behavior unexplained and does not describe return values or side effects, making it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for ad_ids by clarifying that int64 values can be passed as number or string, which is absent from the schema. It does not explain dry_run or elaborate on the 'project' parameter beyond a vague 'via parent campaigns', and schema coverage is only 40%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly starts with 'WRITE:' and lists the actions 'suspend | resume | moderate' on 'ads', clearly defining the tool's verb and resource. This differentiates it from sibling tools like direct_suspend_campaigns or direct_set_keyword_states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the resource ('ads') and the actions, giving an agent strong context for when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls short of a full 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that this is a write operation requiring explicit allow_write=true and flags a safety boundary about needing owner intent for Chat/Skazki. However, it does not describe what happens on execution (status change, cost impact) or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, prerequisites, and a safety warning. No filler, front-loaded with the main action, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers purpose, required conditions, and key exclusions. However, it lacks details on return values, execution behavior, and what 'resume' specifically changes, leaving room for an agent to misinfer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (project and allow_write have descriptions; dry_run and campaign_ids do not). The description adds that allow_write and project/campaign_ids are required for the operation, but does not explain dry_run semantics beyond what one schema field implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: resume suspended campaigns,' providing a specific verb and resource. It clearly distinguishes itself from sibling tools like direct_suspend_campaigns and direct_unarchive_campaigns by precisely targeting the action on suspended campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (resuming suspended campaigns) and provides an explicit warning: 'Do NOT auto-resume killed Chat/Skazki without owner intent.' It also states prerequisites ('Requires allow_write=true + project/campaign_ids'), but does not explicitly compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly labels the tool as 'WRITE' and notes that allow_write=true is needed, which is useful. But it does not disclose side effects such as whether the adjustment overwrites an existing one, whether it is idempotent, or what errors may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the operation type and includes essential context like the write flag and example usage. Every word adds value, with no wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, so a fuller description would help. While the description covers the core operation and safety flag, it omits return behavior, dry_run semantics, and project usage details. For a relatively simple write tool, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description needs to compensate. It names RetargetingConditionId and BidModifier with a range (0–1300) and ties campaign_id to 'on campaign', adding some meaning. However, it does not explain dry_run or project, and retargeting_condition_id is not described beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'bidmodifiers.add RetargetingAdjustment on campaign' with a specific resource and action. It also gives a concrete example ('exclude visitors list'), which distinguishes it from more general bid modifier tools like direct_set_bidmodifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Used e.g. exclude visitors list') and implies it is for retargeting adjustments specifically. However, it does not explicitly mention when not to use it or compare it with sibling tools like direct_set_bidmodifiers, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that this is a WRITE operation, that allow_write=true is required to mutate (otherwise only dry plan), and that it aborts on unexpected live strategy unless force=true. It also clarifies what it does NOT change (DailyBudget). This is solid behavioral disclosure, though it does not mention rate limits or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the operation type ('WRITE:') and packs key constraints. It is concise, but the use of all-caps abbreviations and 'JTBD-style' introduces jargon that may obscure meaning without adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with six parameters and no output schema, the description covers purpose, conditions, safety (allow_write, force), and exclusions. It does not explain return values or dry_run behavior explicitly, but infers that allow_write=false results in a dry plan. This is reasonably complete for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (force, project, allow_write described in schema). The description adds meaning for weekly_rub (₽ denomination) and reinforces the role of allow_write and force. However, dry_run is left completely undefined in both schema and description. The added parameter context is helpful but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a WRITE operation for setting a weekly spend limit on search campaigns with HIGHEST_POSITION strategy and network serving off. It distinguishes itself from siblings by scoping to 'Search' and 'WeeklySpendLimit' and explicitly noting it does not change DailyBudget. However, the phrasing is cryptic with all-caps and abbreviations (JTBD-style) that reduce immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for search campaigns with HIGHEST_POSITION strategy and network serving off. It states the ablation condition: 'Aborts if live strategy is unexpected unless force=true.' It also clarifies that it does not change DailyBudget, guiding against confusion with daily budget tools. However, it does not explicitly name sibling alternatives like direct_set_network_weekly_budget or direct_set_daily_budget.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explicitly says 'READ' and lists the data returned (BiddingStrategy, PriorityGoals, counters), making it clear this is a non-mutating read operation. It does not describe error cases or return format, but for a read-only tool this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence (12 words) that front-loads the read intent with 'READ:' and conveys the essential scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no annotations or output schema, the description covers the core elements: what is read, for which campaign, and the campaign type scope (Text/Unified). It is sufficient for an agent to understand the tool's basic behavior, though more detail on output structure could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies that campaign_id identifies the campaign via 'for one campaign', but it does not explicitly state the parameter's role or any additional requirements. The single integer parameter is fairly self-explanatory, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads full BiddingStrategy, PriorityGoals, and counters for a single campaign. The 'READ:' prefix and specificity distinguish it from siblings like direct_get_campaign, which likely retrieves general campaign info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving strategy-level details for a specific campaign, but it does not explicitly mention when to use this instead of related tools like direct_get_campaign or direct_set_strategy. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It explicitly declares 'READ-ONLY' and enumerates the output fields (project, state, budgets, counts), which is valuable. It does not mention pagination or edge cases, but the core safety trait is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('List campaigns') and lists key output fields. The 'READ-ONLY' flag is a useful, concise addition. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description names the main output fields, which helps set expectations. It does not mention pagination or whether archived campaigns are included by default, but the schema does cover include_archived. Overall, the description is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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's mention of 'project (from projects.json)' adds no new information because the schema already describes the parameter thoroughly. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists campaigns and specifies the included fields (project, state, budgets, negatives/excluded sites counts). It differentiates from sibling tools like direct_get_campaign (which likely retrieves a single campaign) and other list tools by its explicit scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a read-only listing tool and mentions the project source (projects.json), but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No alternative tool names are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the operation is READ-ONLY and that search is by substring. However, it doesn't describe the return format, pagination, or any default behavior. The description adds some behavioral context, but not extensive detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every phrase adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple dictionary search tool with no output schema and minimal annotations, the description covers the core purpose, read-only safety, and a usage hint. It lacks details about output structure or pagination, but these are less critical for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with 'query' and 'type' described in the schema. The description adds context by mentioning 'name substring' (aligning with query) and 'Federation subject IDs' (aligning with a type filter), but it doesn't clarify the 'limit' parameter. The description provides some additional meaning beyond the schema but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Search Yandex Direct GeoRegions dictionary by name substring.' This specifies the verb (Search), resource (GeoRegions dictionary), and method (by name substring), distinguishing it from sibling tools like direct_list_dictionaries or direct_set_region_excludes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: it's a read-only search for GeoRegions, and it gives a specific use case ('Use Federation subject IDs for RegionIds excludes (negative)'). It doesn't explicitly mention alternatives or exclusions, but the guidance is useful for when to apply this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses the mutating nature via 'WRITE:' and the safety mechanism 'allow_write=true'. It also adds semantic detail that 0 signifies exclusion. Missing are details about overwrite vs. merge behavior, but the disclosure is strong relative to typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—and front-loaded with the operation type 'WRITE'. Every piece of information (bid modifier semantics, age examples, allow_write flag) serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward setter tool with 7 parameters but only 2 required, the description covers the essential aspects: the operation type, key parameter semantics, and the critical write-safety flag. It lacks explicit mention of return values, but no output schema exists, and the description is adequate for a simple mutation tool. Some optional parameters like dry_run are not explained, but these are common patterns across sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%), so the description compensates by explaining 'BidModifier 0=exclude' and providing concrete age examples like 'AGE_0_17', which add meaning beyond the schema's bare string types. However, other parameters like campaign_id, dry_run, and gender rely on implicit understanding or the schema's enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a WRITE operation for campaign demographics bid modifiers with age and/or gender scope. The verb 'set' is implied by the tool name and description, and it distinguishes from sibling tools like direct_set_device_bid_modifiers and direct_set_bidmodifiers by specifying the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context such as 'BidModifier 0=exclude' and age examples, and mentions 'allow_write=true' as a prerequisite for mutation. However, it does not explicitly state when to use this tool versus alternatives like direct_set_bidmodifiers, leaving usage slightly implied rather than ruled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly marks this as a WRITE operation, discloses the need for allow_write=true to mutate, and provides concrete rules: maximum 3 ads per group, character limits (Title ≤56, Title2 ≤30, Text ≤81), and content restrictions ('No ₽·— VPN in copy'). This is substantial behavioral disclosure, though it doesn't mention response format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and dense, using a technical shorthand that efficiently conveys the ad structure and rules. It is front-loaded with the core purpose ('WRITE: ads.add TextAd') followed by structured constraints. Slightly unstructured due to the mix of prose and code-like notation, but every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core ads parameter very well, but leaves gaps: the dry_run parameter is undocumented in both schema and description, and the tool's return value/behavior on success is not mentioned. The schema descriptions for project, moderate, and allow_write partially compensate, but with no output schema, some operational context is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'ads' parameter by enumerating its fields, marking optional ones with '?', and imposing length constraints and content restrictions. The schema only provides types for these nested fields, so the description fills a major gap. It also reinforces the allow_write parameter's requirement. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: ads.add TextAd' which clearly specifies the action (adding TextAds) and the API method. It lists the exact fields for the ads array, distinguishing this tool from sibling tools like direct_add_adgroups or direct_add_keywords. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it adds TextAds and includes constraints like 'Max 3 ads/group on UNIFIED' and 'allow_write=true' as a requirement. However, it does not explicitly mention when to use this tool over alternatives or provide exclusions (e.g., for image ads use a different tool). The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation ('WRITE:') and that it does not auto-enable AT, a useful negative behavior. It also highlights the 'allow_write=true' flag as a safety mechanism. However, it does not describe return values or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using compact notation and front-loading the 'WRITE:' label. Every clause adds information: the action, the structure, the bid unit, and the write guard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description covers the core behavior and keyword format but omits response format and error behavior. It also doesn't explain the dry_run parameter, which could be relevant for testing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
It clarifies the keywords parameter structure as [{keyword, bid_rub?}] and notes bid is in micros, adding meaning beyond the schema. The schema only describes project and allow_write, so this fills a gap. It does not explain dry_run or adgroup_id, but those are less complex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'add keywords to ad group' with specific verb and resource, and the 'WRITE:' prefix signals mutation. This distinguishes it from sibling tools like direct_set_keyword_bids or direct_update_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for adding keywords but does not explicitly mention alternatives or when-to-use vs other keyword tools. It does note the 'allow_write=true' requirement, which is a necessary guard for mutation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that this is a WRITE operation, requires allow_write=true to affect the live cabinet, and 'May re-moderate' as a side effect. This is valuable behavioral context beyond the schema. However, it does not clarify whether the operation replaces or appends to existing callouts, nor does it mention permissions or rate limits, so it is not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the action ('WRITE:') and packs essential information: operation, required parameters, source of values, safety flag, and side effect. Every word adds value, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations. The description covers the core workflow, ID sources, and a side effect, but omits important context such as whether the attach operation replaces existing callouts, what the return value is, and how dry_run/moderate_after behave. It is minimally viable but leaves gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only project and allow_write have descriptions). The tool description adds meaning to the required parameters: ad_ids are for TextAds and extension_ids are 'from add_callouts/list', which is crucial. It also reinforces allow_write. However, it does not explain dry_run or moderate_after semantics beyond the schema, leaving gaps for some of the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'ads.update TextAd CalloutSetting AdExtensionIds' – attaching callout extensions to TextAd via ad_ids and extension_ids. It distinguishes itself from siblings like direct_add_callouts (creating callouts) and direct_attach_video_extension (attaching video) by specifying 'CalloutSetting'. The resource (TextAd) and operation (update) are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Pass ad_ids + extension_ids (from add_callouts/list)' implies a prerequisite workflow (create/list callouts first, then attach). 'allow_write=true' is a mandatory condition for mutation. It does not explicitly name alternatives, but the 'WRITE:' prefix and specific CalloutSetting make the intended use distinct from read/list tools and from video extension attachments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the operation is a WRITE (mutation), irreversible, and requires explicit allow_write=true. This is strong behavioral context beyond the schema. It could add more about dry_run behavior or partial failures, but the essentials are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with 'WRITE', and packs essential info: action, target, irreversibility, and prerequisites. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with no annotations and 4 parameters, the description is minimal. It omits the dry_run safety feature, which is critical given irreversibility. It also doesn't mention return behavior. With no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (project and allow_write have descriptions; dry_run and keyword_ids don't). The description adds meaning by emphasizing 'by ids' (keyword_ids) and 'allow_write=true + project scope' (both params). However, dry_run remains unexplained, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('delete'), resource ('keywords'), and method ('by ids'). It also distinguishes from sibling tools like update or add by specifying irreversible deletion. The 'WRITE' prefix reinforces the action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (delete keywords by IDs) and gives prerequisites ('allow_write=true + project scope'). It warns of irreversibility, which guides cautious use. However, it doesn't explicitly mention alternatives like direct_set_keyword_states for pausing, or exclude non-write scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly labels the operation as 'READ', disclosing it as non-mutating, and notes that 'API requires Ids', a key constraint. However, it omits other behavioral details such as response format, error handling, or any rate limits, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with 'READ' to immediately convey the operation type. Every word adds value: the API requirement and the usage order are both essential and clearly stated. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description covers the core usage and context. However, with no output schema and no annotations, it fails to mention what the tool returns or any potential limitations (e.g., maximum number of IDs), leaving some informational gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It does so by naming the parameter ('by ids') and indicating its source ('Use after upload_advideo'), which explains that the IDs are video identifiers obtained from a prior upload. This adds meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'READ: advideos.get by ids' specifies a read operation on ad videos by ID. The addition 'Use after upload_advideo' further distinguishes it from sibling upload tools and clarifies its role in the workflow. The verb+resource+scope combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use after upload_advideo' tells the agent when to invoke this tool relative to a related operation. However, it does not explicitly mention when not to use it or offer alternative tools for similar tasks, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It clearly flags the operation as WRITE and requires allow_write=true, which is critical safety information. It also gives the expected data format for schedule items. However, it omits side effects like whether the existing schedule is replaced or merged, and doesn't mention dry_run behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence with no filler. It front-loads the write intent and packs format specs into minimal space, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (7 params, no output schema, no annotations), and the description explains the main payload and write guard but misses dry_run, project semantics, and the working-weekends option, so an agent might not know how to set those or whether the two modes are mutually exclusive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 29% of parameters. The description defines schedule_items (7 strings day,h0..h23), weekend_pct (0-100), and allow_write (must be true), which adds value for those. But campaign_id, dry_run, project (except schema), and consider_working_weekends remain unexplained in the description, leaving a coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: campaigns.update TimeTargeting', explicitly stating the operation and resource. The 'WRITE' label distinguishes it from read-only siblings like direct_get_time_targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this tool updates time targeting, with two input modes (schedule_items or weekend_pct). It doesn't explicitly compare against sibling tools or mention when not to use, but the write label and API reference make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 this is a write/mutating operation and implies that allow_write=true is needed for actual mutation. However, it does not explain side effects, reversibility, or what happens when allow_write is false (e.g., dry plan). The mention of 'SUSPENDED' vs archived adds some context but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, front-loaded with the core purpose 'WRITE: campaigns.unarchive'. Every word earns its place, and the structure is highly scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description covers the core action and one key alternative, but lacks details about return values, dry_run behavior, prerequisites beyond allow_write/project, and potential side effects. It is minimally viable but has clear gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (project and allow_write are described, dry_run and campaign_ids are not). The description reinforces 'allow_write=true' and 'project scope', but does not clarify dry_run or campaign_ids. It adds some value over the schema but does not fully compensate for the missing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'campaigns.unarchive' and identifies it as a WRITE operation on campaigns. This is a specific verb+resource pair that distinguishes it from all siblings, especially direct_resume_campaigns and direct_archive_campaigns. The phrase 'Prefer resume if only SUSPENDED' further clarifies the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the required conditions: 'allow_write=true + project scope'. It also gives an alternative: 'Prefer resume if only SUSPENDED', which tells the agent when NOT to use this tool and which sibling to prefer instead. This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It explicitly states 'WRITE', indicating a mutation, and requires 'allow_write=true' to perform the mutation, which is an important behavioral safeguard. It also discloses the default region_ids behavior. However, it does not describe the outcome of the write or whether it is reversible, though the add semantics are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single sentence of specification. It front-loads 'WRITE' and packs the essential structure, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate complexity, the description covers the key non-obvious aspects: the group object format, the default region, and the write gating. It doesn't explain campaign_id beyond schema, but that is a required parameter. The lack of output schema means return values are not needed. Overall, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial semantics for the 'groups' parameter by specifying the object structure (name required, region_ids optional) and the default value of [225] for region_ids. This goes beyond the bare schema, which only lists types. It also reiterates the allow_write/project requirements, though those are already in parameter descriptions. With 40% schema coverage, the description partially compensates but does not cover campaign_id or dry_run.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a write operation for adding ad groups, specifying the input format as groups=[{name, region_ids?}]. The verb 'add' and resource 'adgroups' are explicit, distinguishing it from sibling tools that list, update, or delete adgroups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives like direct_update_adgroup_regions or direct_set_negatives, but the 'WRITE' marker and the groups parameter imply it is for adding ad groups. It does mention the condition 'allow_write=true + project scope' which gives context for invocation, but no when-not or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It declares 'WRITE' and 'allow_write=true', indicating a mutating operation and a safety flag. It also reveals channel-specific behavior (search has HP and Network OFF, rsya uses Network max-clicks and Search OFF), which is useful context beyond the schema. However, it doesn't discuss auth, rate limits, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and highly information-dense. It front-loads the core action ('WRITE: campaigns.add from zero') and then quickly covers channels, optional parameters, and follow-up steps with efficient shorthand. There is no redundancy; every element serves a purpose, though some shorthand like 'HP' may require domain knowledge.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no annotations or output schema, the description covers the essential context: purpose, channel differences, key optional settings, and the immediate next steps. It omits some parameters (start_date, dry_run) and doesn't state return values, but the critical workflow is clearly outlined, making it sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 36% (5 of 14 params have descriptions). The description compensates partially by listing optional parameters (daily_rub, weekly_rub, bid_ceiling_rub, negatives, counter_id, utm TrackingParams, timezone) but doesn't explain their semantics further. Some params like dry_run, project, and pin_to_project are left entirely to the schema or omitted, so the description adds moderate value but doesn't fully bridge the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'WRITE: campaigns.add from zero', specifying the exact operation (creating a campaign) and the resource (campaigns.add). It also distinguishes between two channel types (search and rsya) and lists key parameters. This clearly separates it from sibling tools that handle different aspects of campaign management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'After add use add_adgroups/keywords/ads or direct_launch_pack', which provides clear follow-up actions and implicitly indicates this tool is the first step in campaign creation. It doesn't mention when to use an alternative like direct_launch_pack instead, but the workflow is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It explicitly states 'READ-ONLY' and discloses that negatives are only a 'sample', which is an important limitation. However, it does not mention other details like response structure or error behavior, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the purpose and key limitations without waste. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with one parameter, the description adequately lists what will be returned (detail, strategy, excluded sites, negatives sample). No output schema exists, but the listed components provide sufficient context. It could mention the return format in more detail, but overall is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'Yandex campaign Id' already explains the single parameter. The description repeats 'by Yandex Id' without adding further meaning, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one campaign by Yandex Id'), and explicitly lists the returned components (detail + strategy + excluded sites + negatives sample), distinguishing it from sibling tools like direct_get_strategy, direct_get_excluded_sites, and direct_get_negatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to retrieve a single campaign with associated strategy, exclusions, and negatives. It does not explicitly state alternatives or exclusions, but the composite nature is evident from the listed components and the presence of separate getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that this is a write operation, includes moderation steps, optional age ban, resume behavior, and the use of allow_write flag to gate mutations. It also clarifies that 'content' is used in utm_content. While it doesn't detail error handling or idempotency, it offers substantial transparency for a complex orchestration tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and compact, using arrow notation to convey flow and inline schema-like syntax for groups. It is front-loaded with the primary purpose. However, terms like 'pin projects.json' are cryptic and could be clearer, so it loses a point for slightly sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 22-parameter tool with no output schema, the description covers the overall workflow and key parameters but omits return value, prerequisites (e.g., does project need to already exist?), and potential failure modes. It explains the happy path well but lacks the completeness needed for an agent to fully anticipate behavior in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low at 23%, but the description explains the groups structure (name, phrases, ads, image_path), ads limits (max 3), and the semantics of 'content' as utm_content. It also clarifies channel values and the match mode logic ('phrase+"[exact]"'). This adds meaningful context beyond the sparse schema descriptions, though many parameters like sitelinks and budgets remain undocumented in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'WRITE FULL LAUNCH from zero in one call' and enumerates the exact sequence of operations (create campaign, excluded sites, adgroups, keywords, ads, moderation, optional bans/resume). This is highly specific and distinguishes the tool from the many granular sibling tools like direct_create_campaign, direct_add_adgroups, and direct_add_ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use this tool for a complete end-to-end campaign setup from scratch, as opposed to using the individual sibling tools. It also advises 'Prefer dry_run first' and explains that 'allow_write=true' is required for actual mutation, providing practical usage guidance. However, it does not explicitly state when NOT to use this tool or mention alternatives for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'READ-ONLY', which is a clear behavioral disclosure of no side effects. It also scopes to campaign-level and device categories, though it doesn't detail return format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with verb and resource, then READ-ONLY. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers the essential purpose and read-only nature. It doesn't explain the output format, but the enumeration of categories implies what is returned. A small gap is the lack of explicit parameter explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The parameter name campaign_id and the description's 'campaign-level' make the meaning inferable, but the description doesn't explicitly explain the parameter, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'campaign-level bid modifiers' with the scope 'mobile/tablet/desktop/demographics'. This clearly distinguishes it from sibling set/delete tools like direct_set_bidmodifiers and direct_delete_bidmodifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The READ-ONLY flag and 'List' verb clearly indicate this is for reading, not modifying. However, it doesn't explicitly name alternative tools for modifications, so it lacks explicit exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the read-only nature with 'READ' and the mandatory ID prerequisite, which is useful. However, it lacks details about error handling, response format, or behavior with invalid IDs, leaving some gaps for a tool without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, then provides the critical requirement (IDs) and source. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For this simple one-parameter read tool, the description covers the core behavior, the need for IDs, and where to get them. It doesn't describe return structure, but with no output schema and a straightforward API call, the description is reasonably complete, though a note on what it returns would push it to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explicitly states 'Pass feed ids from create/add or UI,' giving semantic meaning to the `ids` parameter beyond its type definition. It clarifies what IDs to pass and where to obtain them, which is essential for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'READ: feeds.get', clearly identifying it as a read operation for feed objects, and distinguishes it from sibling tools like direct_add_feed and direct_delete_feeds. It states the API requires IDs, making the specific scope (get by IDs) clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that IDs are required and tells the agent to source them from create/add operations or the UI. However, it doesn't explicitly mention exclusions or alternatives, though the read-only nature and ID requirement are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The 'READ:' prefix clearly signals a read-only operation, and listing the retrievable items adds context. It does not detail error handling or output format, but for a health check this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('READ: health check') and then lists the specific checks. No excess verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema health check, the description adequately covers the tool's purpose and the information it retrieves. It could mention the return format or an example, but the current description is sufficient for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms no inputs. The description does not need to explain parameter semantics, and the baseline for zero parameters is 4. No additional info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a health check tool, specifying the exact data it returns (token presence, units remaining, campaign count by project). It is distinct from sibling tools, which focus on specific entity operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as a health check for authentication and quota status, but does not explicitly state when to use it vs. alternatives or provide exclusions. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly labels the operation as 'WRITE', specifies the state change 'State→SUSPENDED', and discloses the permission requirement 'allow_write=true' and the effect of stopping spend. It does not mention reversibility or dry_run behavior, but it covers key behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the operation type ('WRITE') and action ('suspend campaigns'), then adds essential requirements and effects. Every phrase earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write operation with no output schema, the description effectively covers purpose, prerequisites, and outcome. It does not describe the return value or edge cases (e.g., what happens if both dry_run and allow_write are true), but given the moderate complexity and schema detail, it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 75% coverage, so the description doesn't need to explain every parameter, but it adds value by clarifying that 'project or campaign_ids' are required (implicitly), which is not evident from the schema's lack of required fields. It does not further explain dry_run or allow_write beyond the schema, but the addition of the 'or' constraint improves understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'suspend campaigns' with an explicit state transition '(State→SUSPENDED)'. This clearly distinguishes it from sibling tools like direct_resume_campaigns or direct_archive_campaigns, and the effect 'Stops spend' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Requires allow_write=true + project or campaign_ids', and notes the consequence 'Stops spend.' However, it does not explicitly state when to choose this over alternatives (e.g., suspend vs archive) or when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly labels the operation as WRITE, discloses the allow_write=true requirement, and notes the input must be from server FS or raw base64. It also mentions the return value. It does not explain the dry-run behavior when allow_write is false, but the schema parameter description covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the operation type (WRITE: adimages.add) and includes only essential details: input sources, return value, and the allow_write flag. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward upload tool, the description covers the operation, input constraints, return type, and write requirement. Combined with the schema, it provides sufficient context even without an output schema or annotations. Minor details like failure handling are absent but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is 3. The description adds the 'or' relationship between file_path and image_base64, and reiterates allow_write=true, but it does not add deeper meaning for parameters like name or dry_run beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the operation as 'WRITE: adimages.add', names the resource (adimages), details input via local file path or base64, and states the return (AdImageHash for TextAd.AdImageHash). This distinguishes it from siblings like direct_upload_advideo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for uploading ad images from a local file path or base64, and requires allow_write=true for actual mutation. It does not explicitly name alternatives or exclusions, but the input constraints effectively guide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It explicitly says this is a WRITE operation, explains that positive IDs are converted to stored negatives, states it preserves existing positives, and notes the allow_write=true requirement. Missing details like how existing negatives are handled and exact scoping are gaps, but the core behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the 'WRITE:' flag and purpose. It delivers essential information in two sentences with no filler, making it easily scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and 5 parameters, the description covers the core behavior but leaves ambiguity about how campaign_ids scopes the operation, what project keys are valid, and the exact dry-run semantics. It is sufficient for a basic understanding but incomplete for nuanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds critical meaning to the primary parameter region_ids by explaining the positive-to-negative conversion, beyond the schema's simple 'Positive GeoRegionId of subjects to EXCLUDE'. It also references allow_write. However, dry_run, project, and campaign_ids are not explained in either description or schema (60% coverage), so it doesn't fully compensate for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'WRITE: add negative RegionIds on all ad groups of campaigns'. It includes a concrete example ('exclude subjects under Russia 225') and distinguishes itself from sibling tools by specifying 'all ad groups' and the negative-region focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('exclude subjects under Russia 225') and implies the tool is for adding negative regions across campaigns. It doesn't explicitly mention alternatives or when not to use it, but the context and sibling names suggest its specific role without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the write nature, length constraints (Title≤30, Desc≤60), and the need for allow_write=true to mutate live cabinet. It adds context beyond the schema, though it doesn't discuss error cases or side effects like overwriting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and front-loaded. The description starts with 'WRITE:' to immediately signal mutation, then packs essential details (structure, constraints, return value, flag) in two short sentences with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no output schema, the description covers the main parameter, constraints, and return value. It doesn't explain dry_run's behavior, which is a notable gap, but overall it's sufficient for an agent to understand the tool's core function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, but the description explains the sitelinks array structure with title, href, optional description, and length limits. It mentions allow_write but does not clarify dry_run; however, the schema provides a description for allow_write, partially compensating. The missing dry_run explanation is a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('sitelinks.add set') and the resource being manipulated, with a 'WRITE:' prefix indicating mutation. It distinguishes itself from sibling tools like direct_list_sitelinks by specifying an add operation, and includes return value (SitelinkSetId).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context as a write operation and mentions the allow_write=true requirement for live actions. It doesn't explicitly name alternatives or exclusions, but the intent is unambiguous given the sibling list of tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the read-only nature via 'READ:' and the API requirement for Ids, which is non-obvious. It doesn't mention return format or pagination, but for a list tool this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with 'READ', no filler. Each part adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description gives enough context to invoke it correctly: identifies the API method, the required argument pathways, and the read-only nature. Slightly vague on how campaign_ids discover IDs, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, and the description compensates by explaining the relationship between sitelink_set_ids and campaign_ids/project: one is the direct ID list, the other serves to discover IDs. It clarifies that IDs are mandatory. The 'limit' parameter is not covered, but the schema's type/range is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'READ: sitelinks.get' which clearly indicates a read operation for sitelinks, distinguishing it from mutation tools like direct_add_sitelinks. It also specifies two methods of identification (sitelink_set_ids or project/campaign_ids), making the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: either supply sitelink_set_ids directly or use project/campaign_ids to discover them. The note 'API requires Ids' tells the agent that at least one of these must be provided. However, it doesn't explicitly contrast with sibling tools, though the name and READ prefix already differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly discloses the write-protection mechanism (allow_write=true for mutating methods) and the generic 'call any' nature, which implies a raw passthrough with limited validation. It does not mention error behavior or return format, but for an escape hatch tool, this is a reasonable level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Escape hatch: call any Direct API service.method'), then provides necessary guardrails and examples. Every phrase adds value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's raw RPC nature, lack of annotations, and absence of output schema, the description covers the essential aspects: purpose, write-safety requirement, example services, and guidance to prefer typed tools. It does not describe response formats or error cases, but for an escape hatch, this is not a significant gap. The description is sufficiently complete for an agent to decide whether to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (service and method lack descriptions), so the description must compensate. It adds concrete semantics for service (listing examples like campaigns, keywords, ads) and method (listing verbs like add/update/delete/suspend/resume), and clarifies allow_write's role. The params field remains generic, but the schema's 'API params object' description and the tool's purpose give adequate context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this tool as an 'Escape hatch' for calling any Direct API service.method with params JSON, which is a specific verb+resource combination. It also distinguishes itself from the many typed sibling tools by instructing 'Prefer typed tools,' making the purpose and differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by stating 'Prefer typed tools,' which tells the agent to use this tool only as a fallback. It also specifies that mutating methods require allow_write=true, giving an explicit condition for safe usage. However, it does not enumerate all scenarios when typed tools are insufficient, so it stops short of a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and does so well: it signals the mutation ('WRITE'), names the underlying API method, warns about the array gotcha ('Prefer plain array'), and explains that allow_write=true is required. It does not detail side effects like replacement of existing categories or auth requirements, but covers more than the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the WRITE marker and uses a compact, information-dense structure. Every sentence carries useful information: the API method, categories format and examples, the array gotcha, optional bid_rub, and the allow_write guard. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and 6 parameters, the description covers the critical aspects: the target entity, the categories structure, the guard flag, and a known API pitfall. It falls short of a 5 by not noting what the return value looks like or whether settings are additive/replacement, but it is sufficiently complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate. It adds meaning to 'categories' with valid examples (EXACT, ALTERNATIVE, etc.) and the YES/NO value format, clarifies bid_rub goes via keywordbids, and emphasizes allow_write=true. It does not explicitly cover keyword_ids, project, or dry_run, but those are largely self-explanatory from their schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'WRITE: keywords.update AutotargetingCategories for AT rows,' which clearly identifies the verb (update), resource (AutotargetingCategories), and scope (AT rows). This distinguishes it from sibling tools like set_keyword_states or set_keyword_bids, and the examples of categories further clarify what is being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is a write operation for autotargeting categories, with an example and the requirement of allow_write=true. However, it does not explicitly state when to prefer this tool over alternatives or any exclusions, so it falls short of a 5 but provides enough context for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses critical behaviors: it is a write operation, requires allow_write=true, converts ₽ to micros, and does not modify DailyBudget. However, it does not mention overwrite semantics, error conditions, or whether existing bid ceilings are replaced, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two dense sentences that front-load the action and include only high-value information. Every clause contributes to usage, conversion, or scope, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the core behavior, scope, and safety flag effectively. It lacks details on return values and potential side effects on existing settings, but overall it is sufficient for a straightforward setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds essential meaning beyond the schema by explaining the ₽ to micros conversion for monetary parameters and clarifying the optional BidCeiling. It does not elaborate on dry_run or campaign_id, but the conversion detail is a significant value-add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool writes a network weekly budget maximum clicks spend limit for RSYA-style campaigns. It distinguishes itself from siblings by explicitly noting it does not touch DailyBudget and focuses on network budgets only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides contextual guidance by mentioning 'RSYA-style campaigns' and that search is left as-is, implying when to use. It does not explicitly name alternatives, but the scoping hints at separation from daily budget and search weekly budget tools. Lacks explicit when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the write nature, defines the BidModifier value scale (0=off, 100=default, etc.), and warns about a specific conflict (Desktop may 6000-conflict if Mobile=0). This is valuable behavioral context, though it does not cover error handling or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a few terse sentences to convey the core behavior, value mapping, and an important edge case. Every sentence adds value, and the 'WRITE' prefix immediately signals the operation type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational details for a 7-parameter tool with no output schema. It explains the key parameter semantics, the write flag, and a conflict scenario. However, it does not explain dry_run behavior or the project parameter, leaving some gaps for a complete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%), and the description compensates well by explaining the meaning of mobile/tablet/desktop values and the 'ONE field per API call' rule. It also clarifies allow_write semantics, which is only partially covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'WRITE: campaign device bid mods' which clearly states the action (write) and the resource (device bid modifiers for a campaign). It distinguishes itself from sibling tools by specifying 'ONE field per API call (Mobile/Tablet/Desktop)'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use the tool, including the constraint of one field per call and the necessity of allow_write=true. It does not explicitly name alternatives or exclusions, but the sibling context (e.g., direct_set_bidmodifiers) makes the specific use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly labels the tool as WRITE, discloses the write-enable requirement (allow_write=true), and gives a domain-specific safety rule about dsp.yandex.ru. It also explains merge/replace semantics, which clarifies the effect on existing exclusions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. Every clause is relevant: write indicator, target, mode, safety flag, and the dsp.yandex.ru warning. There is zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema, no annotations), the description covers the essential safety and behavioral aspects. It omits dry_run and campaign_ids details, but those are documented in the schema. The critical selection/invocation criteria are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful parameter context beyond the schema: it states the default mode ('mode=merge (default)') and the requirement for allow_write. Since schema coverage is 67%, the description compensates for some gaps, though sites and campaign_ids are left to schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'WRITE: set campaign ExcludedSites', clearly identifying the action, target, and write nature. It adds domain context ('RSYA junk packages/DSP') and distinguishes itself from the read-only sibling direct_get_excluded_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage constraints: 'allow_write=true required' and the critical warning 'Never auto-exclude dsp.yandex.ru unless sites list includes it.' It also specifies mode options (merge/replace). However, it does not explicitly mention alternative tools for when not to use this one, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses read-only behavior ('READ'), the raw/passthrough nature, and that it requires a fully specified report. However, it omits details like authentication requirements, response format, or error behavior, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with 'READ', and instantly communicates risk and usage. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and the description covers purpose, usage, parameter structure, and alternatives, it is fairly complete. Minor gap: no mention of return value characteristics, but 'raw' implies direct API response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'spec' as 'Reports params object', but the description lists concrete examples (SelectionCriteria, FieldNames, ReportType) and emphasizes the need for a 'full report spec', adding significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'READ: raw Reports API', clearly identifying the action (read) and resource (raw Reports API). It further specifies it requires a full report spec, distinguishing it from higher-level report tools like direct_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Advanced; prefer direct_report / direct_report_breakdown', giving clear guidance on when to use this tool versus alternatives. The word 'Advanced' sets the context of when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![yandex-direct-mcp MCP server](https://glama.ai/mcp/servers/gmen1057/yandex-direct-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gmen1057/yandex-direct-mcp)

Score Badge

Copy to your README.md:

[![yandex-direct-mcp MCP server](https://glama.ai/mcp/servers/gmen1057/yandex-direct-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gmen1057/yandex-direct-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gmen1057/yandex-direct-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server