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

Goes beyond the idempotentHint annotation by spelling out the consequence ('repeating the call changes nothing') and disclosing an all-or-nothing failure mode ('a campaign that does not belong to the account refuses the whole request'). It does not state permission requirements or whether any response is returned, but the atomicity and idempotency disclosure is meaningful 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.

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

Three sentences, front-loaded with the action, then scoping rule, then edge-case behavior. No filler; each sentence carries distinct operational information.

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

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

For a 3-parameter mutation tool with only an idempotency annotation and no output schema, the description covers scope, parameter sourcing, idempotency, and failure atomicity. Remaining gaps (permissions, return behavior) are minor.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds value beyond the schema: it names the source of zone IDs (sites report, macrosId) and clarifies that campaignIds must enumerate every campaign affected. The blocked flag semantics are already in the schema, so no credit there.

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

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

States a specific verb pair (stop/resume buying traffic) and resource (sites/zones in given campaigns), and the per-campaign scoping distinguishes it from siblings like kadam_adv_update_site_bids or kadam_adv_toggle_autorule_slice_block. An agent can identify the operation and its granularity without opening the schema.

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

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

Explains the key usage condition – blocking is per campaign, so every campaign must be listed, and zone IDs come from the sites report (macrosId). It gives clear context but does not explicitly name an alternative tool or state when not to use this one.

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

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

Annotations provide idempotentHint=true. The description adds critical behavioral details: mixing pricing models errors out and countries are required. It does not mention if updates overwrite existing bids (implied) or what the response looks like, but given minimal annotations, the description provides meaningful context beyond annotations.

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

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

Two sentences, no filler, front-loaded with the core action. Every sentence provides necessary information without redundancy. Highly efficient.

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

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

The description covers the main action and critical constraints (pricing model, countries). It doesn't explain return values (no output schema) or other edge cases, but for a 4-parameter bulk update tool with high schema coverage, it is sufficiently complete for agent decision-making.

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

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

Schema coverage is 100%, so each parameter is already documented. The description adds cross-parameter business logic: all campaigns must share one pricing model. This adds value beyond individual parameter descriptions, justifying a score above baseline 3.

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

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

The description clearly states 'Set the same bid on multiple campaigns at once', with a specific verb and resource. It adds constraints (pricing model, countries) that distinguish it from sibling tools like kadam_adv_update_campaign_bid (single campaign) and kadam_adv_update_site_bids (site level).

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

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

The description explicitly states that all campaigns must share one pricing model and that countries are required. This provides clear context for when to use the tool. However, it does not explicitly exclude alternative tools or provide when-not-to-use guidance, but the constraints serve as implicit guidance.

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

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

Annotations only declare readOnlyHint=false, so the description carries real weight and delivers: what is cloned (targeting, limits, bids) vs not (stats, spend), that the copy starts paused, re-enters moderation, does not spend until activated, and that creatives are copied and re-moderated as new. This is exactly the behavioral context an agent needs for a mutation.

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

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

Three tight sentences, front-loaded with the core action, and each one adds a distinct behavioral fact without redundancy. Zero filler.

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

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

For a mutation tool with no output schema this is strong: the description explains post-copy state, moderation, and spend behavior comprehensively. It is slightly short of perfect because return/result expectations are unaddressed, though the schema covers all inputs.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters with detailed semantics. The description adds no extra parameter syntax or format detail beyond what the schema provides (its 'all by default' note merely restates the creatives schema default), so the baseline 3 applies.

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

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

The opening verb+resource ("Copy a campaign") is specific and clearly distinct from create_campaign/update_campaign, and the following sentences sharpen the meaning by stating exactly what is cloned. It stops short of an explicit sibling comparison, so it misses the top tier.

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

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

Usage is implied: this duplicates an existing campaign rather than creating one from scratch, and the paused/moderation behavior is stated. However there is no explicit when-to-use, when-not, or alternative (e.g. create_campaign) guidance, so it stays at implied usage.

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

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

Annotations only declare readOnlyHint=false, so the description carries real weight and delivers: the cartesian-product behavior (2 creatives x 2 targets = 4 copies), that originals are preserved, that copies start paused, and that they go through moderation. These are exactly the mutation-behavior facts an agent needs before calling a write tool.

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

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

Three tight sentences that front-load the purpose, then explain the copy semantics and constraints. No filler; the concrete 2x2=4 example earns its place by clarifying a non-obvious expansion rule.

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

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

For a mutating tool with no output schema, the description covers behavior, constraints, and post-copy state well. It stops short of noting the 50-target cap or what the call returns (e.g., new creative IDs), but nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not convey: the multiplicative relationship between creativeIds and targets, and the pause-after-copy outcome tied to pauseAfterModeration. It reinforces the url domain constraint already documented in the schema.

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

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

The description opens with a specific verb+resource: 'Copy creatives into other campaigns.' This clearly distinguishes it from siblings like kadam_adv_move_creatives (originals retained vs moved) and kadam_adv_create_creative, so an agent can route without opening the schema.

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

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

It gives clear operational context and constraints (same ad format required, landing URL must stay on target domain), and 'originals are untouched' implicitly distinguishes copy from move. However, it never explicitly names an alternative tool or states when-not-to-use, so it stops short of full routing guidance.

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

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

Annotations only declare readOnlyHint=false, so the description must carry behavioral weight. It usefully discloses that type=fingerprint is never created directly and must be produced as a side effect via createFingerprint=true, and re-explains dryRun's no-op semantics. However it says nothing about permissions, error behavior on partial payloads, or whether a created fingerprint is atomically linked.

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

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

Front-loads the core action, then uses a tight type-by-type bullet list rather than prose, with no redundant sentences. The closing dryRun sentence earns its place by giving the practical trigger for using it.

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

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

For an 11-parameter mutation tool with no output schema, the description covers payload composition thoroughly. The remaining gap is the result side: it never indicates what is returned on success (e.g., the new audience ID) or how to verify creation, which an agent orchestrating a campaign create would want.

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

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

Schema description coverage is 73%, so the schema already documents most individual flags, but the description adds genuine cross-field semantics absent from the schema: the '>=1 of hasClicks/hasConversions/hasHolds/hasRejects' constraint for type=audience, the required sets per type, and that linkedAudienceIds takes pixel/fingerprint IDs. This meaningfully exceeds the baseline.

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

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

States a specific verb and resource ('Create an audience') and then enumerates the exact required field sets for each of the three creatable types, which no other sibling does. An agent can distinguish this from kadam_adv_update_audience, kadam_adv_delete_audience, and kadam_adv_list_audiences from the description alone.

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

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

Gives clear per-type selection logic (which fields apply when) and recommends dryRun=true while assembling a campaign and its audience together. It stops short of naming the sibling tools to use for modification or deletion, so it lacks explicit alternatives/exclusions, but the conditional guidance is strong.

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

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

Adds substantial behavior beyond the lone readOnlyHint=false annotation: the 5-rules-per-campaign and 300-per-account caps, that exceeding either is refused, the delete-before-add workaround, and the staff-token exemption. This is exactly the operational context an agent needs before a write call.

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

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

Four dense sentences, each carrying distinct information (scope, one-per-rule, bidChange requirements, quota rules). Front-loads the core purpose and uses no filler despite a 12-parameter tool.

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

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

For a complex mutation tool with no output schema and no destructive/rate annotations, the description covers scope, dependencies, and quotas well. It omits only return-value expectations and whether creation is reversible, which are minor gaps here.

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

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

Schema coverage is already high (83%), but the description adds cross-parameter dependencies the schema cannot express: bidChange requires slices + bidRate + bidMax together with a spend/clicks condition. It does not restate every field, but that dependency mapping is genuine added value.

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

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

States a specific verb+resource ('Create an autorule on a CPC campaign') and immediately scopes it with the CPC-only constraint. It is clearly distinguishable from siblings like update_autorule, delete_autorule, list_autorules, and set_autorule_status.

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

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

Gives concrete usage guidance: 'Campaigns usually carry several rules (a strategy); call once per rule' and 'delete a rule before adding one' when limits are exceeded. It does not explicitly route to update_autorule for modifying an existing rule, so it stops short of full when-vs-alternatives coverage.

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

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

Annotations only declare readOnlyHint=false, so the description carries the real behavioral burden and does it well: asynchronous queueing, a job handle rather than immediate creatives, and idempotency on identical payloads. It also discloses the multiplicative batch semantics (items × campaigns), which materially affects how the agent sizes requests.

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

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

Five sentences, each carrying distinct information (pipeline position, cross-product sizing, prerequisite, async/job model, idempotency), with the most important framing front-loaded. No filler or restatement of the tool name.

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

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

With no output schema, the description still explains what the call returns (a job) and where per-row results are read, plus the async and replay semantics. Combined with 100% schema parameter coverage, an agent has everything needed to invoke and follow up correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot express: every item is fanned out across every listed campaign, and each item requires a stagedId sourced from a specific sibling tool. The remaining params (name, path, text, title, pauseAfterModeration) are left to the schema, which is acceptable.

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

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

States a specific verb and resource ('turn staged images into creatives') and positions itself as 'second step of a bulk creative batch', which separates it from the single-creative sibling kadam_adv_create_creative. An agent can identify the operation without opening the schema.

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

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

Explicitly names the prerequisite step (stagedId from kadam_adv_upload_bulk_images) and the follow-up path for results (kadam_adv_get_bulk_job), giving a full pipeline context rather than isolated usage. The same-payload-replay behavior further tells the agent when re-calling is safe.

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

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

Annotations only declare readOnlyHint=false, so the description carries most of the burden and does so well: dryRun creates nothing and reports the same field errors. It does not cover permissions, campaign status after creation (active vs paused), moderation effects, or rate limits.

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

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

Two dense sentences with the action first and the dryRun rationale second; both earn their place. The only cost is the incomplete required-field enumeration, which is a correctness issue rather than verbosity.

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

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

For a 46-parameter creation tool with no output schema and near-zero annotation coverage, the description supplies the creation intent, the required set, and the validation escape hatch. Remaining gaps (resulting campaign state, interactions among trafficSources/conversionTemplateId) are largely covered by the rich schema.

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

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

Schema coverage is 100%, so the schema already documents all 46 parameters and the baseline would be 3. However, the description's 'Required:' list omits countries, which the schema marks required — an agent trusting the prose would submit an invalid payload.

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

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

Specific verb+resource: 'Create a new advertiser campaign' immediately distinguishes it from update_campaign, copy_campaign, and create_campaign_folder siblings. It does not name an alternative, but the creation verb plus the required-field list makes the scope unambiguous.

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

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

Gives concrete when-to-use guidance for dryRun: validate the payload before committing, useful for checking bids/targeting/limits. It does not address when to choose this tool over siblings like copy_campaign or create_campaign_folder, so it falls short of the top band.

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

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

Annotations already indicate write operation (readOnlyHint=false). Description adds terminology clarification but does not disclose behavioral traits such as uniqueness constraints, potential errors, or what happens on success (e.g., returns folder ID). The agent gains little beyond the annotation.

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

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

The description is a single concise sentence (20 words) that directly states the purpose. No unnecessary words. Front-loaded with the key action and resource.

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

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

Given a simple tool with one parameter and no output schema, the description covers the basic purpose. However, it lacks information about the expected response or side effects, which would help an agent use it correctly. The absence of output schema makes the description incomplete in terms of return value.

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

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

Schema covers the single parameter (name) with a description including length and examples. The tool description adds the aliases but does not add new semantic meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

Description clearly states the action ('Create') and resource ('campaign group' / 'folder'). It provides both UI and API terminology, and distinguishes from sibling tools like kadam_adv_create_campaign (different resource) and kadam_adv_update_campaign_folder (update vs create).

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

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

The description implies usage (when you need a new campaign group), but does not explicitly state when to use this tool vs alternatives or provide any exclusions. No prerequisites or context about when not to use it.

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

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

Goes well beyond the single readOnlyHint=false annotation: it discloses that HTML5 and video uploads require internal grants, that advertisers normally deliver video as a VAST tag with nothing uploaded, that the VAST tag is fetched and parsed on save and rejected if no usable document is returned, and that pauseAfterModeration defaults to true for safety.

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

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

Front-loads the verb and resource in one line, then uses a tight scannable bullet list keyed by creative type, ending with a pointer to the reference resource for sizes. No filler sentences; every line carries actionable information.

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

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

For a 15-parameter, no-output-schema creation tool, the description covers format requirements, grants, and the moderation/pause default, which is what an agent needs to invoke it correctly. Minor gaps remain: no statement of what the created creative's initial status is beyond the pause flag, and no mention of how it relates to bulk creation.

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

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds real value by consolidating requirements into a per-format matrix (e.g., Banner = url + imageUrl + sizeId; Video = title + url + videoUrl) that is not derivable from reading individual property descriptions in isolation.

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

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

States a specific verb and resource ('Create a creative') and immediately enumerates the format-specific required fields, so the agent knows exactly what this operation produces. It does not, however, reference the adjacent 'create_bulk_creatives' sibling, so the single-vs-bulk distinction must be inferred.

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

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

The per-type requirement list effectively tells the agent when each field combination applies (Push, Native, Banner, HTML5, Video, VAST, Popunder) and flags grant prerequisites for HTML5 archive and VAST/video upload. It gives no explicit exclusions or named alternatives (e.g., when to prefer bulk creation or update_creative).

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

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

Annotations already set destructiveHint=true, and the description adds the detail that deletion is permanent and requires confirm=true. This adds non-obvious behavioral context beyond annotations.

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

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

The description is a single sentence conveying critical information with no wasted words. It is appropriately short and front-loaded.

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

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

For a simple delete tool with two parameters and no output schema, the description covers the key safety requirement and permanence. It does not describe return values, but that is acceptable given the action's nature.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the purpose of confirm (safety) but does not describe the id parameter. This provides partial but not complete parameter guidance.

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

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

The description clearly states 'Permanently delete an audience', which is a specific verb (delete) and resource (audience). It distinguishes from sibling tools like create_audience or update_audience.

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

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

The description provides the explicit guideline 'Requires confirm=true for safety', indicating the required parameter setting. It does not elaborate on when not to use, but for a delete operation, this is adequate.

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

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

Adds 'permanently' and 'requires confirm=true' beyond the destructiveHint annotation. Agent understands irreversibility and confirmation necessity, which are critical behavioral traits.

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

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

Two succinct sentences front-load purpose. Every word adds value; no filler.

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

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

Covers purpose and key requirement. Missing id explanation is minor given sibling tools; no output schema is typical for deletion. Adequate for a simple tool.

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

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

With 0% schema coverage, description must explain parameters. It explains confirm (must be true) but not id. Agent knows confirm's purpose but id remains ambiguous.

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

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

The description clearly states 'Permanently delete an autorule', specifying the verb (delete), resource (autorule), and permanence. This distinguishes it from sibling tools like update or set status.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., deactivating via set_autorule_status). The requirement 'confirm=true' is a prerequisite, not a usage comparison.

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

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

Annotations only declare destructiveHint=true and a title; the description goes well beyond by specifying cascade deletion of creatives, the archived-state precondition, call-level rejection semantics, and non-idempotent retry behavior. That is exactly the behavioral context an agent needs before a permanent mutation.

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

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

Four short sentences, each carrying a distinct fact (action, cascade, confirmation gate, precondition, retry behavior), with the destructive verb front-loaded. No filler.

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

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

For a permanent-mutation tool with no output schema, the description covers the irreversible consequences, the gating precondition with the sibling tool to call first, and failure modes. Nothing material is left for the agent to infer.

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

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

Schema coverage is only 50% (ids documented, confirm has a const with no prose). The description compensates by explaining that confirm must be true as a deliberate safety gate, though it never restates that ids is a comma-separated list, so the format meaning still lives only in the schema.

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

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

States a specific verb (permanently delete) and resource (campaigns), and discloses the cascade to their creatives. This cleanly separates it from sibling tools like set_campaign_status, delete_creatives, and move_campaigns.

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

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

Explicitly names the prerequisite path ('a campaign must be archived first (use set_campaign_status with status=archived)'), names the required confirm flag, and warns against retrying. It gives both when-to-use and when-the-call-will-fail.

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

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

Annotations only declare destructiveHint=true; the description goes well beyond that by stating the operation is permanent, that confirm=true is mandatory, that the entire call is rejected (atomic, not partial) if archiving wasn't done, and that deleted creatives become unaddressable. These are exactly the failure modes an agent needs before committing to a destructive call.

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

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

Four short sentences, front-loaded with the action and hard requirement, then prerequisites, then the retry edge case. No filler; each sentence carries a distinct operational fact.

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

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

For a two-parameter destructive tool with no output schema, the description covers the mutation semantics, the mandatory flag, the ordering prerequisite, and the rejection conditions. Nothing an agent needs before invoking it is missing.

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

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

Schema coverage is 50%: 'ids' is documented in-schema as comma-separated IDs, but 'confirm' has only a const constraint and no schema description. The description compensates by explaining that confirm=true is required and that omitting it fails the call. It adds real meaning for the undocumented parameter, though it says nothing about format limits or ID count for 'ids'.

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

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

States a specific verb and resource ('Permanently delete creatives') and immediately pins down scope via the confirm and archive prerequisites. An agent can distinguish it from siblings like set_creative_status, update_creative, or delete_campaigns without opening any schema.

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

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

Gives explicit when-not conditions and the alternative workflow: the creative must be archived first, and it names the sibling (set_creative_status with status=archived) that accomplishes that. It also states that retries against already-deleted creatives are rejected, closing a failure path an agent would otherwise hit.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral value beyond that by disclosing the exact returned field set and, notably, a negative boundary ('Does not return email or name'), which prevents the agent from assuming the profile is complete.

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

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

Two tight sentences: the positive return set is front-loaded, followed by the exclusion. Every clause carries information and nothing is padded.

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

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

There is no output schema, so the description must carry the return-value burden, and it does so by listing the fields returned and the fields deliberately omitted. For a parameterless read tool this is complete.

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

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

The tool takes no parameters, so there is nothing to document and the baseline of 4 applies. The description correctly spends no words on parameter semantics.

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

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

States a specific verb and resource ('Gets the current advertiser account profile') and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from the sibling kadam_adv_get_balance, which overlaps on the 'balance' field it lists, so sibling differentiation is left to inference.

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

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

Usage is implied by the name and the field list — fetch the account profile — but there is no explicit when-to-use statement or pointer to alternatives such as kadam_adv_get_balance. For a zero-parameter read tool the implied usage is largely sufficient, hence a minimum-viable 3.

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

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

Annotations already set readOnlyHint=true. The description adds valuable detail about return values depending on type (pixel/s2s/stat), going beyond a simple 'read'.

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

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

Single sentence, front-loaded with action, no wasted words.

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

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

For a simple 1-param get tool without output schema, the description covers purpose and return differentiation. Could add more on error conditions or exact return structure.

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

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

With 0% schema coverage, the description should compensate but only implies 'id' is the audience identifier by context. No explicit parameter description is provided.

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

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

The description clearly states it retrieves a single audience by ID. It distinguishes from siblings like list_audiences (returns multiple) and the many create/update/delete tools.

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

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

The description implies usage for fetching a specific audience's details. Sibling tool names provide context, but no explicit when-to-use or alternatives are given.

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

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

Beyond readOnlyHint=true, the description discloses permission scoping (only the owner can read), the failure mode for shared audiences (not found), and null semantics for unset slots including the downstream effect on the {placeholder}. This is exactly the kind of auth/data-shape context annotations cannot carry.

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

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

Three tight sentences, front-loaded with what the resource is, then eligibility, then return semantics. No filler and nothing repeated from the schema or annotations.

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

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

For a one-parameter read tool with no output schema, the description covers identity, eligibility, access failure, and null-slot behavior, which is nearly everything an agent needs. It stops short of describing the shape of the returned parameter slots, but that is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100% for the single id parameter, so the baseline is 3, but the description adds real constraint meaning by tying the accepted ID domain to pixel-or-S2S audiences and explaining that IDs outside that domain surface as not found rather than as an error.

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

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

The description names the exact resource returned — hardcoded parameter values that a pixel or S2S audience substitutes into its tracking code — which is specific enough that an agent can distinguish it from the generic kadam_adv_get_audience sibling. It is phrased as a noun description rather than a verb-led statement of retrieval, but the scope and data type are unambiguous.

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

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

It states a clear precondition (only pixel and S2S audiences have these values) and an exclusion (an audience shared with the account answers as not found), which tells the agent when this call is pointless. It does not name kadam_adv_get_audience or kadam_adv_set_audience_params as alternatives, so routing 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.

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

readOnlyHint=true already establishes the safe-read profile, but the description adds value beyond annotations by disclosing the returned content (balance and currency) and the 'lightweight' nature of the call. It stops short of stating freshness, currency/account scoping, or error behavior, so it falls just below a full 5.

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

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

Two tight sentences, zero filler. The resource and return contents come first, the routing guidance second — appropriately front-loaded.

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

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

With no parameters, no output schema, and only readOnlyHint in annotations, the description carries the remaining burden and does so: it states what is returned (balance and currency) and when to call it. Nothing an agent needs to invoke this correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema; baseline 4 applies. The description correctly implies the call is self-scoped to the current advertiser, which is useful since no scoping parameter exists.

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

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

The description names a concrete resource (current advertiser balance and currency) with an implied retrieval verb, and explicitly distinguishes itself from kadam_adv_get_account and finance operations. An agent can separate it from the 50+ siblings without opening the schema.

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

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

It gives an explicit use case (alerts and balance checks) and names the alternatives it should displace (kadam_adv_get_account, finance operations) with the selecting condition ('when you only need the balance'). Routing is fully determined.

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

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

Adds genuinely non-obvious behavioral context beyond the readOnlyHint annotation: 'done' means the worker finished, not that rows succeeded, and callers must inspect counters. This is exactly the kind of outcome-semantics disclosure the annotation cannot provide, and it is critical given there is no output schema.

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

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

Two dense sentences with no filler; the critical caveat about 'done' is front-loaded in the second sentence. The opening clause is slightly compressed to the point of being terse, but nothing wastes space.

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

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

With no output schema, the description carries the burden of explaining what comes back (counters, staging refusals, per-row outcomes) and does so well. Remaining gaps are minor: no indication of polling behavior or how long results persist.

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

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

Schema coverage is 100% and the sole jobId parameter is already documented as 'Job ID returned by the upload or create call.' The description reinforces that origin story implicitly but adds no format, validation, or lifecycle detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('State of a bulk creative batch') and goes further by distinguishing the two job flavors it covers — staged/refused images for an upload job vs. per-row outcomes for a creation job. It is clearly separable from siblings, though it never names the producer tools (upload_bulk_images / create_bulk_creatives) that generate the jobId.

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

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

The description makes the use context clear: this is the status-check step for a bulk upload or creation batch, and it warns to read counters before declaring success. It lacks explicit when-not-to-use guidance or polling/cadence advice, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds details about the returned data but does not disclose any hidden behavioral traits beyond what the annotation already conveys.

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

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

The description is two sentences, front-loaded with the main purpose, and lists many included items without unnecessary fluff.

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

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

For a simple read-only tool with one parameter and no output schema, the description adequately covers what is returned and the usage context, making it complete.

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

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

The schema covers the only parameter 'id' with description 'Campaign ID' (100% coverage). The description adds no additional meaning beyond stating it's retrieved by ID, so baseline of 3 is appropriate.

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

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

The description explicitly states that the tool gets the full campaign configuration by ID, listing specific details. It differentiates from siblings by noting it should be used after kadam_adv_list_campaigns for detailed inspection.

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

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

It gives explicit guidance to 'Use after kadam_adv_list_campaigns to inspect one campaign in detail,' clearly indicating the workflow context and when this tool is appropriate.

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

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

readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds cardinality context ('one entry per rule'), which hints at result shape, but says nothing about scoping, pagination, permissions, or failure behavior beyond what annotations provide.

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

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

Two tight sentences: the first delivers the what, the second the why. No filler, no repetition of the title, and the capability statement is front-loaded.

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

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

With no output schema, the description should sketch the return shape; 'one entry per rule' is the only hint, and what a slice entry actually contains (bid value, rule identity, hand-set vs. rule-managed flag) is left unstated. For a simple read-only, one-parameter tool this is adequate but not fully complete.

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

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

There is a single required parameter (campaignId) with 0% schema description coverage, so the description must carry the load. It implicitly establishes campaign scoping ('the campaign's bid'), which makes the parameter's meaning inferable, but never mentions the argument by name, type, or accepted form.

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

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

The description states a specific resource ('the campaign's bid [that] autorules act on') and the output granularity ('one entry per rule'), which goes beyond the tautological title 'Campaign autorule slices'. The phrasing is slightly awkward and it does not explicitly distinguish itself from lookalike siblings such as get_campaign_bid_restrictions or list_extended_bids, so it stops short of a 5.

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

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

'Use it to tell apart a bid you set by hand from one an autorule keeps rewriting' gives a concrete decision context for reaching for this tool. It does not name an alternative tool or state when not to use it (e.g., when you just want rule definitions from list_autorules), so no exclusion guidance is present.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description still adds real behavioral context by disclosing the null semantics ('null when the geo bids differ'), which prevents misinterpreting a missing value as an error. It does not cover auth, rate limits, or numeric formats, keeping it short of a 5.

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

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

A single dense sentence front-loads the resource, then the returned fields, then the usage rule. No filler; every clause carries information the agent needs.

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

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

There is no output schema, so the description correctly compensates by describing the three returned values and the null case. The only gap is that the required campaignId argument is undocumented, which is minor for a single obvious identifier on a read-only tool.

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

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

Schema description coverage is 0% and the description never mentions campaignId or its expected form. The parameter name is self-evident and there is only one, which limits the practical damage, but the description does not compensate for the coverage gap. Minimum-viable 3.

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

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

The description states a specific resource and enumerates what is inside it: the fixed-bid cap, the largest allowed multiplier, and the campaign bid the multiplier applies to. That is far more concrete than a tautology. It stops short of naming the sibling write tools it is meant to precede, so sibling differentiation is only implied via 'before writing bids.'

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

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

'Read it before writing bids to know what will pass' gives a clear triggering context and implicitly routes the agent toward the bid-writing siblings (update_campaign_bid, bulk_update_bids, update_extended_bids). There is no explicit when-not-to-use or named alternative, but the sequencing guidance is actionable.

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

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

readOnlyHint=true already tells the agent this is a safe non-mutating call. Beyond that, the description discloses the returned payload shape (name, archived state, budgets, distribution), which genuinely matters because there is no output schema. It does not cover error behavior (e.g. what an unknown ID returns), so it is good but not complete.

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

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

One tightly written sentence: the action and keying field come first, the returned fields follow as the payoff, and the parenthetical naming gloss is placed at the end where it does not interrupt the main clause. No wasted words.

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

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

For a single-resource read with one required parameter, no output schema and a readOnly annotation, the description supplies the missing piece: what fields come back. That makes it sufficient for correct invocation. A note on missing/not-found behavior would be the only remaining gap.

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

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

Schema coverage is 100% and the sole parameter is documented as 'Campaign group ID'. The description's only added value is reinforcing that the ID is a campaign-group/folder ID, which is a minor clarification over the schema. Baseline 3 is appropriate when the schema carries the semantics.

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

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

Specific verb (get) plus resource (a single campaign group), the keyed lookup field (by ID), and an enumerated field list. It also resolves the naming ambiguity between the API term 'campaign group' and the UI term 'folder', which is the main source of confusion here. It stops short of explicitly distinguishing itself from the sibling list_campaign_folders.

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

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

The word 'single' combined with 'by ID' implies this is the point-fetch counterpart to kadam_adv_list_campaign_folders, so the usage context is inferable. But there is no explicit when-to-use statement, no exclusion, and no mention of sibling tools by name.

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

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

Far exceeds the readOnlyHint annotation by explaining exactly what the returned go link does when opened (writes a click id, resolves macros, redirects like a served ad), clarifying nothing is registered until someone opens it, and noting format-specific behavior: HTML-tag creatives have no go link and framed formats add a preview link.

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

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

Purpose is front-loaded in the first sentence and each subsequent sentence carries distinct behavioral value (side-effect timing, format caveats). Slightly verbose, but nothing is wasted.

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

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

With no output schema, the description compensates by describing what comes back: a go link for standard creatives, no go link for HTML-tag creatives, and an extra preview link for framed formats. An agent has everything needed to call it and interpret the result.

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

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

There is a single parameter with 100% schema coverage, so the schema already documents creativeId. The description adds no param-level syntax or constraint details, so the baseline 3 applies.

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

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

The description states a specific verb and resource: it hands over links for verifying a creative's conversion tracking. No sibling tool does this, and the agent can tell immediately this returns diagnostic test links rather than creative metadata (list_creatives) or creative mutations.

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

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

The purpose implies when to use it (to verify a creative's postback end to end) but there is no explicit when/when-not framing or named alternative. With no sibling offering a comparable test-link capability, the guidance is adequate but left to inference.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful semantics beyond that: '0 means no cap' and 'null minimum means the currency does not support changing the limit', which explain the returned values' meaning rather than restating the read-only nature.

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

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

Three short sentences with zero filler. The scope constraint and sibling redirect are front-loaded ahead of the edge-case return semantics.

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

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

With no output schema, the description usefully documents the two key return values (limit=0 meaning no cap, null minimum meaning currency unsupported). It leaves minor gaps (no mention of other returned fields or error behavior), but covers what an agent needs to interpret the result.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument call and adds no spurious parameter guidance, keeping semantics clean.

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

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

States a specific verb ('Gets') and resource ('daily spending limit') with an explicit scope qualifier ('WHOLE ACCOUNT, not of a single campaign'). It names the sibling kadam_adv_get_campaign and the condition that separates them, so an agent can route correctly without opening schemas.

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

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

Explicitly redirects campaign-budget calls to kadam_adv_get_campaign, giving clear usage context. It stops short of a full when/when-not framing (e.g., preconditions for calling), but the alternative-selection guidance is present.

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

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

Beyond readOnlyHint=true, the description discloses behavioral traits an agent needs: isps/regions/cities are paginated and searchable because one country can hold tens of thousands of entries, platforms/devices/categories return nested trees, campaign-types is scoped to what the account may actually create, and conversion-templates expose status strings. These are real invocation-relevant behaviors not derivable from annotations.

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

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

Front-loaded with the core action and its full domain, then conditions per type. The single dense paragraph is long but nearly every sentence carries distinct information; only mild redundancy with the schema enum list keeps it from a 5.

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

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

For a lookup tool with no output schema, the description is complete: it names every valid type, the prerequisites for each, pagination/search scope, and how returned ids are consumed downstream. An agent can invoke it correctly without opening the schema.

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

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

Schema coverage is already 100%, so baseline is 3, but the description adds genuine meaning on top: the geo id chain (countries ids feed countryId and the campaign's countries field; regions/cities give the campaign's cities ids) and the conditional coupling of campaignType/countryId to specific type values. It stops short of documenting perPage/search edge behavior beyond what the schema states.

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

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

States a specific verb (Gets) and resource (one reference dictionary used to build campaign targeting) and enumerates all eleven dictionary types by name. An agent can immediately tell this apart from data-fetching siblings like get_campaign or list_campaigns because it is a metadata/lookup tool.

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

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

Explicitly says 'Call this instead of guessing IDs — every targeting field expects the numeric ids returned here,' which is a direct when-to-use instruction. It further routes by type: categories requires campaignType, isps/regions/cities require countryId, cities can be narrowed by regionId, and countries is named as the entry point of the geo chain.

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

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

Annotations declare readOnlyHint=true, and the description confirms it's a stats grid, consistent with read-only. It adds behavioral details beyond annotations: the need for Bid Optimization access and the pattern of re-using pathIds for bid updates. No contradictions.

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

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

Three sentences with no wasted words. The first sentence states purpose and requirement, the second explains the drill/reuse pattern, and the third gives a cardinality tip. Information is front-loaded.

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

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

Given 11 parameters, low schema coverage, and no output schema, the description covers the core functionality and essential parameters well. It lacks detail on date range, search, and pagination but provides enough context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is low (36%), but the description adds significant meaning to key parameters: it explains how pathIds work (drill path, slice IDs), enumerates valid metric and sortField keys, and clarifies that campaignIds should be a single campaign for per-row bids. This compensates for the coverage gap.

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

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

The description clearly states 'Bid Optimization: per-slice stats grid for drilling down and setting bids,' which is a specific verb+resource combination. It distinguishes from sibling tools like kadam_adv_get_stats (general stats) and kadam_adv_list_extended_bids (list bids) by focusing on drill-down and bid-setting context.

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

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

Explicitly states requirement ('requires Bid Optimization access'), provides when-to-use guidance ('Drill by appending a sliceId to pathIds'), and instructs how to re-use results ('reuse each row's pathIds to set bids via kadam_adv_update_extended_bids'). It also advises cardinality ('Use ONE campaign to see per-row bids').

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

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

Annotations already declare readOnlyHint=true, and the description aligns with a read operation. The description adds value by explaining report types and parameter details, but lacks disclosure on pagination, 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.

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

The description is concise with two short sentences and a fragment, front-loading the purpose. It efficiently introduces key options without extra verbiage.

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

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

Given 19 parameters and no output schema, the description is insufficient. It omits return value format, pagination behavior, and how to interpret responses, leaving significant gaps for an AI agent.

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

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

The description adds meaning by explaining reportType options and providing examples for metrics and groupBy, partially compensating for the low schema description coverage (32%). However, many parameters remain undocumented.

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

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

The description clearly states 'Advertiser statistics' and explains the three report types with examples for metrics and groupBy. It distinguishes itself from sibling CRUD and list tools by focusing on statistical data.

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

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

No guidance on when to use this tool versus siblings like list_campaigns or other read tools. It does not mention alternatives or conditions for use.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds meaningful behavioral context beyond that: the forecast is derived from yesterday's auction, and an empty curve signals 'could not be built' rather than zero traffic — a non-obvious output semantics detail.

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

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

Three tight sentences, front-loaded with purpose, then usage timing, then the interpretation caveat. No filler and every sentence carries distinct information.

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

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

With no output schema, the description carries the burden of return semantics and does so for the key edge case (empty curve). It could say more about the shape of a successful forecast response, but is adequate for an agent to call and interpret the tool.

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

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

Schema description coverage is 100% for all 7 parameters, including enum semantics (cpa_target forecast as cpc) and the campaignId exclusion behavior, so the schema does the heavy lifting. The description adds no parameter-level detail, which matches the baseline 3 when the schema is complete.

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

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

States a specific verb (forecast) and resource (traffic a bid can buy for a targeting set) with the data basis (yesterday's auction). No sibling tool forecasts traffic, and the description makes the tool's distinct role obvious.

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

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

Explicitly says when to use it: 'before creating a campaign or raising a bid,' which frames it as a pre-flight check. It does not name alternative tools or when-not to use it, but no sibling overlaps enough to require that.

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

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

Annotations already mark the tool as read-only. The description adds behavioral details: it supports pagination, filtering by search query, and sorting by field and order, providing useful context beyond the annotation.

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

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

The description is a single concise sentence that front-loads the main action and key features, with no unnecessary words.

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

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

For a list tool with 5 parameters and no output schema, the description covers the essential aspects (pagination, filter, sort). It could mention defaults or constraints, but it's largely complete for agent usage.

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

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

Schema coverage is low (20%), so the description should compensate. It mentions 'Filter by search query, sort by field and order' but doesn't explain each parameter in depth, such as the minLength constraint on searchQuery or default values for page and perPage.

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

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

The description clearly states the verb 'List' and resource 'advertiser audiences', distinguishing it from sibling tools like create, delete, or update. It also mentions pagination, filtering, and sorting, which are specific to this tool.

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

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

The description implies when to use this tool: for viewing audiences with optional filtering and sorting. It doesn't explicitly state when not to use it, but the sibling tools cover modifications, making the intended use clear.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that it returns 'full rule definitions' and specifies behavior for campaignId, adding value beyond annotations without contradiction.

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

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

Two sentences with no filler. The information is front-loaded and every word is necessary. Highly concise and structured effectively.

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

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

Given the tool's simplicity (one optional param, read-only), the description is mostly complete. It states the return type ('full rule definitions'). Could mention pagination or limits, but not essential for a minimal viable description.

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

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

Schema has 0% description coverage for the only parameter (campaignId). The description fully compensates by explaining that omitting it returns all rules for active campaigns and passing it filters for one campaign, giving crucial semantic meaning.

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

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

The description clearly states the verb 'List' and the resource 'autorules (campaign automation)'. It distinguishes from sibling create/delete/update tools by specifying the listing behavior and the optional campaignId filter.

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

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

Provides clear guidance on parameter usage: omit campaignId for all rules of active campaigns, pass it for one campaign. Does not explicitly mention when not to use it or alternatives, but the context is sufficient for this read-only list tool.

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

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

Annotations already indicate readOnlyHint=true. The description adds behavioral context by mentioning pagination (page/perPage) and optional search by name, which are not in annotations. No contradictions.

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

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

Two sentences: first summarizes core action and features, second clarifies terminology. No redundant information. Front-loaded and efficient.

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

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

For a simple list tool with 3 parameters and no output schema, the description covers the main functionality. It lacks mention of response structure but is largely complete given the context.

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

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

Schema coverage is 0%, so description must compensate. It explains that 'page' and 'perPage' enable pagination and 'searchQuery' allows search by name. However, it does not specify defaults or types, leaving some ambiguity.

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

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

The description clearly states the tool lists campaign groups (folders) with pagination and optional search. It clarifies terminology by noting the entity is called 'campaign group' or folder, distinguishing it from sibling tools like list_campaigns.

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

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

The description does not provide any guidance on when to use this tool versus alternatives (e.g., when to use list_campaign_folders vs list_campaigns). No exclusion criteria or context for selection.

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

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

Annotations already declare readOnlyHint=true, consistent with listing. The description adds pagination and filtering behavior, but does not complicate or contradict. No destructive behavior disclosed, which matches annotations.

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

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

Single sentence, front-loaded with primary action and filter options. No redundancy or unnecessary text.

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

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

No output schema is provided. The description does not explain the return format (e.g., what fields are in each campaign object, pagination metadata). While it's a list tool, an agent might need to know the response structure. Completeness is adequate but not fully comprehensive.

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

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

Schema description coverage is 40% (4/10 parameters described in schema). The description names filter categories but does not detail parameter formats or constraints beyond what schema provides. For example, enum values for status/type are not mentioned. It adds marginal context but does not fully compensate for low coverage.

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

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

The description clearly states 'List advertiser campaigns with pagination' and enumerates filtering options (folderId, status, type, date range, search query), distinguishing it from sibling tools like get_campaign (single) or create_campaign.

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

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

The description implies when to use (when you need a paginated, filtered list) but does not explicitly contrast with sibling tools like get_campaign for a single campaign or list_campaign_folders for folders. Still, the filtering context is clear.

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

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

The description adds pagination and filter capabilities beyond the readOnlyHint annotation. However, it does not disclose additional behavioral traits like authentication requirements, rate limits, or response structure.

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

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

Extremely concise single sentence, front-loaded with the primary action and resource. Every clause serves a purpose without redundancy.

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

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

Given 5 parameters and no output schema, the description covers the core listing and filtering but omits default values (page, perPage), optional status enum details, and response format. It is adequate but has gaps.

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

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

With only 20% schema description coverage, the description should compensate but merely lists filter types (campaign, status, search query) without adding meaning or format details beyond parameter names. The searchQuery parameter description in schema is not reiterated.

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

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

The description clearly states the tool lists advertiser creatives with pagination, using specific verb 'List' and resource. It distinguishes from sibling tools like list_campaigns or list_audiences by specifying 'creatives'.

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

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

No explicit guidance on when to use this tool versus alternatives. While the name implies listing creatives, there is no mention of when not to use it or how it differs from other list tools among many siblings.

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

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

Annotations already declare readOnlyHint=true. The description adds that the tool is paginated and lists 'per-slice bid overrides' under 'Bid Optimization', which provides slight behavioral context but no additional safety or auth details. No contradiction with annotations.

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

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

The description is a single, efficient sentence that front-loads the action and resource. No wasted words.

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

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

The description mentions listing and pagination but does not describe the output format or structure. Given no output schema, this omission reduces completeness for an agent to understand what to expect.

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

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

Schema description coverage is 33% (only 'campaignIds' has a description). The description does not explain any parameters beyond implying campaignIds are needed. It adds no meaning to 'page' or 'perPage' beyond what the schema provides.

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

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

The description clearly states the verb 'List', the resource 'per-slice bid overrides', and the context 'Bid Optimization'. This uniquely identifies the tool's function and distinguishes it from siblings like 'kadam_adv_bulk_update_bids' and 'kadam_adv_update_extended_bids'.

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

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

The description implies usage for reading bid overrides but provides no explicit guidance on when to use this tool versus other listing tools (e.g., 'kadam_adv_list_campaigns'). No when-not or alternative tools are mentioned.

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

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

Annotations include readOnlyHint=true, confirming safety. Description adds purpose and typical use cases. No contradictions, but lacks additional behavioral details like pagination behavior or rate limits. Still, annotations cover the main safety aspect.

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

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

Extremely concise: two sentences that front-load the purpose and provide immediate user intent. No wasted words.

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

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

No output schema exists, yet description does not mention return format, pagination, or any error conditions. Adequate for basic use but leaves gaps for an AI agent needing full context.

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

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

Schema has 5 parameters with 60% description coverage (page and perPage lack descriptions). The description does not add any parameter-specific meaning beyond what is in the schema, failing to compensate for the gaps.

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

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

Clearly specifies the verb 'Lists' and resource 'financial operations', with examples (deposits, charges, refunds) and intended use (check account balance, transactions). This distinguishes it from sibling tools like list_campaigns or list_audiences.

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

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

Provides context for usage ('check account balance, recent transactions, and spending history') but does not explicitly state when not to use or mention alternatives among siblings. The guidance is implicit rather than explicit.

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

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

readOnlyHint=true already establishes the safe-read profile, and the description adds real behavioral context beyond it: the per-currency shape of the returned conditions and the filtering rule that administrator-reserved systems are excluded. It does not mention auth scope or pagination, but for a no-param read tool the added disclosure is meaningful.

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

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

Three compact sentences: what is returned, when to call it, and what is filtered out. Every clause carries information, and the primary purpose is front-loaded.

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

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

With no output schema, the description compensates by naming the fields a caller will receive and the exclusion rule, so an agent knows both the trigger and the payload shape. Nothing needed to invoke this zero-arg read tool correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the schema to describe and the baseline of 4 applies. The description correctly adds no parameter guidance because none is needed.

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

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

The description uses a specific verb ('Lists') and a precise resource ('the payment systems the account may deposit through'), then enumerates the returned fields (commission, min/max amount, exchange rate). No sibling tool covers payment systems, so the resource itself is self-distinguishing within the sibling set.

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

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

'Use before advising on a deposit' gives an explicit triggering condition, which is more than most list tools provide. It stops short of naming any alternative or stating when-not-to-call, but the intended call site is unambiguous.

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

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

The description goes beyond the idempotentHint annotation by disclosing atomicity semantics: validation errors reject the whole request and success means every campaign was moved. This is exactly the kind of all-or-nothing behavior an agent needs before issuing a batch mutation, and it is consistent with idempotentHint=true.

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

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

Three short sentences with the core action front-loaded and no filler. The middle sentence largely duplicates the schema's parameter descriptions, which is mild redundancy given 100% schema coverage, but overall the structure is tight.

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

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

For a simple two-parameter batch mutation with no output schema, the description covers the action, the inputs, and the atomicity guarantee. Missing only minor context such as required permissions or behavior when a target group is invalid, which is not fatal at this complexity.

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

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

Schema description coverage is 100%, so both parameters (ids, folderId) are already documented in the schema. The description restates 'comma-separated campaign IDs' and 'target campaign group ID', adding no format, limit, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource pair ('Move ... campaigns to a campaign group'), which cleanly separates it from the sibling kadam_adv_move_creatives, whose resource differs. It is clear and specific, but does not explicitly disambiguate from other campaign-related siblings such as update_campaign or set_campaign_status.

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

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

The instruction to pass comma-separated IDs implies the batch use case, so an agent can infer when this tool is the right choice over single-campaign operations. However, no explicit when-to-use/when-not guidance or named alternatives (e.g., a hypothetical single-campaign move) are given.

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

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

Annotations only declare readOnlyHint=false, so the description carries the behavioral burden and does it well: it discloses that moved creatives lose creative-level geo bids, are paused, and return to moderation, and that the operation is atomic ('nothing moves' on failure). It stops short of saying whether the operation is revertible or what the caller gets back afterward, but the destructive effects are unusually well surfaced.

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

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

Four short sentences, front-loaded with the operation and its constraints, then the side effects, then the failure semantics, then the alternative. Every sentence carries distinct information with no filler.

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

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

With no output schema, the description could say what a caller receives after a successful move (e.g. job id or moderation state), which is the one gap. Otherwise it covers prerequisites, destructive effects, and atomicity, which is sufficient for a three-parameter mutation tool.

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

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

Schema description coverage is 100%, and the schema already states the domain constraint on 'url' and the format/pricing constraint on 'campaignId'. The description restates those constraints but adds no syntax, format, or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Move creatives to another campaign') and constrains scope to the same ad format and pricing model. It also explicitly names the sibling operation that covers the alternative intent ('To keep the originals in place, copy instead'), so an agent can distinguish it from kadam_adv_copy_creatives without opening either schema.

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

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

It gives explicit selection criteria — same ad format, same pricing model — and names the alternative tool (copy) with the condition that selects it. The when-not condition is stated rather than implied.

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

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

Annotations already declare destructiveHint=true, but the description adds value beyond them: it discloses the non-obvious side effect that blacklisted (action=off) slices are also dropped and begin being bought again, requires confirm=true, and states the bids are not recoverable. This is exactly the irreversibility and side-effect context an agent needs.

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

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

Three tightly packed sentences, front-loaded with the core action, side effect, safety requirement, and alternative. No filler; every sentence carries actionable information.

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

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

No output schema exists and this is a destructive mutation, so the description carries the burden well: it covers what is destroyed, the blacklist side effect, the confirmation requirement, and irreversibility. An agent has everything needed to call it safely and correctly.

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

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

Schema coverage is 50% (confirm documented only as const true, campaignIds as comma-separated string). The description explains why confirm=true exists ('the dropped bids are not recoverable'), adding meaning beyond the schema's const constraint, and clarifies campaignIds as 'the listed campaigns'. It stops short of detailing ID formats or the confirm failure mode.

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

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

States a specific verb+resource ('Drop every per-slice bid ... returning them to the campaign-level bid') and defines the exact scope (listed campaigns, all slices). It is clearly distinguishable from the sibling kadam_adv_update_extended_bids, which is named for the single-slice case.

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

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

Names a concrete alternative ('To remove a single slice use kadam_adv_update_extended_bids with action=remove') and gives the condition selecting it. It lacks broader routing guidance among the many other bid-related siblings (bulk_update_bids, update_site_bids), so it is strong but not exhaustive.

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

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

With annotations only supplying readOnlyHint=false, the description carries the disclosure burden and does so well: it states this is a full-replace operation where unset slots are cleared, and that {placeholder}-like values are rejected. Both are non-obvious behaviors an agent would otherwise get wrong.

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

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

Three tight sentences with no filler; the destructive replace semantics are front-loaded and the read-first pointer and validation rule follow in priority order. Every sentence carries actionable information.

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

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

For a 6-parameter mutation with no output schema, the description covers the destructive-replace risk, the prerequisite read step, and a validation constraint, which is what an agent needs to call it safely. Return-value detail is unnecessary given there is no output schema.

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

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

Schema coverage is 67%, with the id and two paramInt descriptions supplied by the schema, so the baseline is 3. The description adds important semantics about the set as a whole (omitted slots are cleared, placeholder values refused) but does not explain what event, paramStr, or paramStr2 individually mean beyond their schema entries.

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

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

States a specific verb ('Set') and resource ('hardcoded parameters of a pixel or S2S audience'), which cleanly separates it from the read sibling kadam_adv_get_audience_params and from kadam_adv_update_audience. An agent can identify the operation without opening either schema.

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

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

Explicitly directs the agent to read current values with kadam_adv_get_audience_params first and clarifies the 'send every value you want to keep' precondition, which is real usage guidance. It stops short of stating when not to use this tool (e.g. versus update_audience or create_audience), so it is clear context rather than full when/when-not routing.

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

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

Adds important context by clarifying the tool does not delete the autorule. The annotation 'idempotentHint' already covers idempotency, so the description does not need to repeat it.

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

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

Extremely concise (one sentence), but at the cost of omitting parameter guidance and usage context; prioritizes brevity over completeness.

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

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

For a simple two-parameter tool without output schema, the description is too minimal; it fails to explain return values, what happens on error, or any behavioral nuances.

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

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

With 0% schema description coverage, the description must compensate by explaining parameters, but it does not mention 'id' or 'isActive' at all, leaving their meanings unclear.

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

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

Clearly states the verb (enable/disable) and resource (autorule), and distinguishes from sibling 'delete_autorule' by explicitly saying 'without deleting it'.

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

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

Implies usage for toggling active state, but provides no explicit guidance on when to use versus alternatives like 'update_autorule' or conditions that must be met.

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

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

Beyond the idempotentHint annotation, it discloses cascading effects (activating/pausing/archiving a group also affects all contained campaigns) and an all-or-nothing failure mode for restore, which is valuable operational context. It does not describe permissions, rate limits, or return shape, but it adds real behavior beyond the annotation.

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

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

Front-loaded with the scope ('Bulk action on campaign groups') and compressed into roughly two sentences. The parenthetical clarifications (folder terminology, inverse relationship) earn their place, though the sentence is dense.

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

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

For a 2-parameter, no-output-schema tool, the description covers the bulk semantics, ID format, every action's effect, and the restore precondition, plus the idempotency annotation. Only minor gaps remain (no note on what happens to already-active groups, no permission requirements).

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

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

With 50% schema coverage, only 'ids' is documented in the schema; the description compensates by defining what each enum value of 'action' actually performs (activate, pause, archive, restore) and restating the comma-separated 'ids' format. This meaningfully extends what the bare enum and schema provide.

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

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

The description opens with a specific verb and resource ('Bulk action on campaign groups') and enumerates exactly what activate/pause/archive/restore do at the group level. It also disambiguates terminology ('campaign group = the UI term for a folder'). It stops short of contrasting itself with the sibling kadam_adv_set_campaign_status, which operates on individual campaigns rather than groups.

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

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

It gives per-action semantics and a concrete precondition for restore ('accepts ONLY archived group IDs and rejects the whole call if a live ID is passed'), which tells the agent when restore is valid. It does not name an alternative tool or state when to prefer this over single-campaign status tools, so no explicit exclusions.

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

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

Annotations only supply idempotentHint, so the description carries real behavioral weight and delivers it: the import is scheduled rather than immediate, success means the feed was saved and not that creatives exist yet, and stopping the import leaves already-imported creatives in place. That success-semantics caveat is exactly the kind of context annotations cannot express.

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

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

Three tight sentences, front-loaded with the primary action and effect, then the eligibility constraint, then the asynchronous caveat. Every sentence carries information the agent needs.

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

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

For a 4-parameter mutation with no output schema and thin annotations, the description covers the main risks: format restriction, async scheduling, and non-destructive stop behavior. Minor gaps remain (it never touches the moderation/removal flags), though the schema does document those.

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

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

Schema description coverage is 100% and the schema already documents the empty-string stop convention, native-campaign requirement, and both boolean flags. The description repeats the empty-link behavior rather than adding new parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource ('point a native campaign at an RSS feed') and covers both directions of the operation (set vs. stop via empty link). The 'native campaigns only — other formats are rejected' clause scopes it precisely, and no sibling tool touches RSS feeds, so the agent can pick it without ambiguity.

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

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

Gives clear when-to-use conditions for both modes: set a feed to import creatives, or send an empty link to stop. It does not name an alternative tool for related work (e.g., manual creative creation), but the usage context itself is unambiguous.

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

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

Annotations only supply idempotentHint=true, so the description carries most of the load and does so well: it discloses partial-failure semantics ('some IDs can be refused while others succeed') and clarifies the non-obvious 'restored' semantics as un-archiving. It stops short of stating permission requirements, behavior for campaigns already in the target status, or reversibility of archiving.

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

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

Three short sentences, front-loaded with the action, then invocation format, then the partial-success caveat. No filler or redundancy; every sentence carries distinct information.

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

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

For a two-parameter mutation tool with no output schema, the definition covers what an agent needs to call it correctly, including per-campaign result variability. Only secondary details (authorization needs, effect on campaigns already in the target state) are absent, which is acceptable at this complexity.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: 'ids' is documented as a comma-separated list and 'status' values are enumerated with the meaning of the ambiguous 'restored' spelled out. It adds no formatting/validation detail beyond that (e.g. ID formats, max batch size).

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

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

States a specific verb ('Set status') and resource ('campaigns') with explicit batch scope ('multiple campaigns'). It is clearly distinguishable from same-family siblings like kadam_adv_set_creative_status, kadam_adv_set_autorule_status and kadam_adv_set_campaign_folder_status without opening any schema.

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

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

The description gives invocation guidance (comma-separated IDs, allowed status values) but never states when to prefer this bulk tool over per-campaign paths such as kadam_adv_update_campaign, nor any exclusion or precondition. Usage is implied by the operation itself, not compared against alternatives.

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

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

Annotations only declare readOnlyHint=false; the description carries the real behavioral load: replace-not-merge semantics, fallback to campaign bid for omitted countries, same-campaign and targeting preconditions, duplicate-country restriction, and CPA rejection. This is exactly the destructive/irreversible context an agent needs before calling.

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

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

Three sentences, purpose front-loaded, then the crucial replace/fallback behavior, then validation constraints. Every sentence earns its place with no filler.

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

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

For a two-parameter write tool with no output schema, the description covers semantics, preconditions, and rejected cases completely. An agent has everything needed to invoke it correctly without opening the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the bids list fully replaces existing bids and unmapped countries fall back to the campaign bid. That semantics-of-the-list insight is not inferable from the schema alone.

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

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

States a specific verb and resource ('Set per-country bids on creatives') with scope clarified as per-country/creative. This clearly distinguishes it from siblings like kadam_adv_bulk_update_bids and kadam_adv_update_extended_bids.

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

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

Gives strong operational guidance: 'send every country you want priced, not just the one you are changing' and an explicit exclusion ('CPA campaigns are rejected'). It does not, however, name an alternative tool for e.g. campaign-level bids, so it stops short of full when-vs-alternative routing.

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

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

Annotations only assert idempotentHint, so the description carries the behavioral load and does it well: partial success semantics ('some IDs can be refused while others succeed') and a real precondition ('restored is rejected for the whole call if the creative's campaign is itself archived — restore the campaign first'). It omits auth/permission requirements and any rate-limit context.

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

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

Three sentences, front-loaded with the core action, then the parameter format, then the two edge cases. No filler; every clause adds operative information.

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

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

For a 2-parameter mutation tool with no output schema and minimal annotations, this covers the essentials an agent needs: bulk invocation format, allowed values, partial-failure behavior, and the archived-campaign blocker for 'restored'.

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

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

Schema description coverage is 0%, so the description must compensate: it explains that 'ids' is a comma-separated string and that 'status' accepts active/paused/archived/restored, including the non-obvious meaning of 'restored' as take-out-of-archive. That adds genuine meaning beyond the enum list.

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

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

States a specific verb and resource ('Set status for multiple creatives'), explicitly bulk, which cleanly separates it from siblings like kadam_adv_set_campaign_status and kadam_adv_update_creative (single-creative edit). An agent can pick it without opening the schema.

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

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

Gives clear operative context: comma-separated IDs, the four allowed statuses, and the meaning of 'restored'. It does not explicitly name when to prefer an alternative (e.g., update_creative or set_creative_bids), so it stops short of full when/when-not routing.

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

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

Annotations only cover idempotency, so the description carries the rest and delivers real behavioral disclosure: raising or removing the limit resumes campaigns it had stopped, a minimum-value constraint sourced from another tool, and a currency-eligibility gate. These are consequential side effects an agent must know before calling.

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

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

Four dense sentences, each carrying distinct routing, validation, eligibility, or side-effect information with no filler. The most important distinction (account vs campaign) is front-loaded.

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

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

For a one-parameter mutation with no output schema, the description covers scope, alternative routing, validation bounds, eligibility, and side effects. An agent has everything needed to call it correctly.

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

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

The single parameter is fully described in the schema, but the description goes beyond it by stating the amount must be at least the minimum reported by kadam_adv_get_day_money_limit and reasserting the 0-removes semantics. That adds a validation rule the schema's minimum: 0 alone does not convey.

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

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

States a specific verb and resource ('sets the daily spending limit of the WHOLE ACCOUNT') and explicitly scopes it against the sibling use case by naming kadam_adv_update_campaign for campaign budgets. An agent can distinguish it from all siblings without opening a schema.

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