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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds useful behavioral context beyond that, notably that the created ad includes audit status and that the asset URL must already be CDN-hosted. This gives the agent a clearer picture of the creation workflow and expected result.

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 front-loaded with the core purpose and then uses a structured Args/Returns format. It is somewhat repetitive of the input schema, but it is organized, scannable, and avoids irrelevant prose.

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

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

The tool has a nested creative object, required subfields, and no output schema, but the description provides a full field list and a concise Returns note mentioning audit status. It does not explicitly mark which creative subfields are required, though the input schema already provides that. Overall, the important preconditions and outcome are covered well enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents every parameter. The description mostly restates the same information, though its nested listing of creative fields does help readability. It adds little semantic value beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Create a new ad within an ad set.' It clearly distinguishes this from sibling campaign and ad set creation tools by anchoring it to a parent adSetId, and it mentions the returned audit status, making the tool's purpose unambiguous.

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

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

The description gives clear contextual guidance: the ad must belong to an ad set and the asset must be uploaded to the NewsBreak CDN first. It does not explicitly name alternatives like update_ad or get_ads, but the context makes when to use this tool reasonably obvious.

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

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

The annotations already declare readOnlyHint=false and idempotentHint=false, so the mutation behavior is not a surprise. The description adds only 'Returns: Created ad set details' and restates some parameter-level requirements, but does not disclose additional behavioral context such as side effects, failure modes, or what happens when required bid fields are missing.

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 purpose statement is front-loaded and clear, but the subsequent 17-line Args block largely duplicates the input schema line-by-line. This is structured and readable, yet not concise for an agent that already has access to the full schema; the duplication adds length without adding value.

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

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

For a complex 17-parameter creation tool with no output schema, the description leaves the response only as 'Created ad set details,' which is vague and does not tell the agent what fields to expect. Input semantics are well-covered by the schema, but the lack of output detail and explicit prerequisites beyond campaignId makes it only minimally complete.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter thoroughly. The description's Args section mostly restates the schema's existing information (e.g., 'Budget in cents', 'required for CPM, CPC, TARGET_CPA') without adding meaningful new semantics 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 opens with 'Create a new ad set within a campaign,' naming a specific action, object, and parent scope. This makes it immediately distinguishable from sibling tools like newsbreak_create_campaign and newsbreak_create_ad, and from the update_ad_set variant.

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

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

The phrase 'within a campaign' and the required campaignId parameter clearly establish that this tool is for creating ad sets under an existing campaign, not for retrieving or updating them. It does not explicitly name alternatives or say when not to use it, but the context is sufficient for correct selection among 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 show readOnlyHint=false and idempotentHint=false, so the write behavior is expected. The description aligns with those annotations and adds the return behavior (created campaign details) but does not disclose additional behavioral context such as idempotency implications, permission requirements, or effects of duplicate names. This is acceptable but not rich.

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

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

The description is well-structured, starting with the core purpose and then listing parameters and return value in a compact, scannable format. There is no filler, and every section earns its place.

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

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

For a straightforward create-campaign operation, the description is complete: it covers all required parameters, optional parameters with defaults, and the return value. Since there is no output schema, the Returns section fills that gap. No critical information for invoking the 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?

Schema description coverage is 100%, and the schema already fully documents all four parameters with descriptions, types, and enums. The description repeats this information in an Args block but does not add meaningful semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description opens with a clear, specific verb and resource: 'Create a new advertising campaign.' It distinguishes itself from sibling tools like newsbreak_create_ad_set and newsbreak_create_ad by identifying the exact entity being created, so an agent can select it confidently.

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 clearly implies this tool is for creating a campaign rather than updating one or creating ad sets/ads, but it does not explicitly state when to use it versus alternatives or mention any prerequisites such as 'the ad account must already exist.' The intent is understandable but relies on inference from the tool name and operation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by stating that results are grouped by organization and include account IDs, names, and creation times. There is no contradiction with the annotations.

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

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

The description is compact, with an opening sentence that states the core purpose and short sections for Args and Returns. There is minor redundancy: the return shape is described in prose and again in the Returns block, and the Args block repeats schema information. Still, the structure is scannable and every sentence is relevant.

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 required parameter, comprehensive annotations, and no output schema, the description adequately covers the input, return grouping, and included fields. It does not mention pagination, errors, or authentication, but these are not critical given the tool's simplicity and annotation coverage.

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

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

The input schema already documents orgIds with a clear description and 100% schema description coverage. The description's Args section only restates the schema ('Array of organization IDs') without adding formatting, constraints, defaults, or relationships, so it provides no added meaning beyond the schema.

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

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

The description uses a specific verb 'Get' with resource 'ad accounts' and a scope 'for specified organizations,' and also mentions the return format (grouped by organization with account IDs, names, and creation times). This clearly differentiates it from sibling tools that operate on campaigns, ad sets, and ads, none of which list ad accounts.

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 an agent needs ad accounts for a set of organization IDs, but it never explicitly states when to prefer this tool over alternatives or when not to use it. Because no sibling tool targets ad accounts, the context is reasonably clear but implied rather than stated.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the description only needed to add extra behavioral context. It adds pagination defaults and return contents (creative details and status), which go beyond the structured data and help the agent understand what to expect.

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 opening line is efficient and front-loaded, and the Returns section is useful. However, the Args block duplicates the input schema almost verbatim, so a meaningful portion of the description does not earn its place.

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

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

For a read-only list operation with full schema coverage and safety annotations, the description covers the key aspects: what it returns, pagination behavior, and optional filters. It could mention error conditions or rate limits, but these are less critical given the annotations and flat schema.

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

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

Schema description coverage is 100%, and the Args section largely restates the schema's own descriptions and defaults. The description adds no new parameter meaning beyond the opening summary and the return note, so it meets the baseline but does not elevate it.

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

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

The description states a specific verb ('Get') and resource ('all ads for an ad account') with optional filters, making the tool's purpose immediately clear. It distinguishes itself from sibling tools like get_ad_accounts and get_campaigns by naming the exact entity returned.

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

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

The description clearly implies this is the tool to use when retrieving ads for an account, and the sibling set of create/update/status tools makes the read-only role obvious. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.

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

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

Annotations already establish readOnly, idempotent, non-destructive behavior. The description adds value by stating that the result is a paginated list and that returned ad sets include full details such as targeting and schedule. No side effects are claimed, so there is no 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?

The one-sentence summary is front-loaded and the Args/Returns structure is easy to scan without excessive verbosity. It loses a point because the Args block largely duplicates the schema and contains the misleading 'search' entry.

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

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

For a read-only list operation with annotations and a full schema, the description is mostly sufficient: it identifies required account ID, optional filters, pagination defaults, and the shape of the return value. However, the unsupported 'search' parameter is a substantive error, and with no output schema the return description is only a high-level sketch.

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

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

The schema already documents all accepted parameters with 100% coverage, so the description's parameter list is largely redundant. More importantly, the description lists a 'search' argument that is not present in the schema, while additionalProperties is false, which could cause an agent to send an invalid request.

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 line 'Get all ad sets for an ad account with optional filters' states the exact verb, resource, and scope. This is distinct from siblings such as newsbreak_get_campaigns, newsbreak_get_ads, and create/update tools because the resource and read-only intent are explicit.

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 intended context clear: retrieve all ad sets belonging to a specific ad account, with optional filtering. It does not explicitly name alternatives or say when not to use it, but the resource-specific phrasing is enough to route an agent correctly.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by stating that results are paginated and includes defaults for pageNo and pageSize. No contradictions 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 well-organized with a front-loaded one-line summary, an Args section, and a Returns section. It is appropriately sized for a five-parameter tool, though it duplicates some information already present in the input schema.

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

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

Together with the schema and strong read-only annotations, the description covers the required adAccountId, optional filters, pagination behavior, defaults, and return shape at a useful level. It doesn't describe exact campaign fields returned, but this is not critical given no output schema and the simple list nature of the tool.

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

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

Schema description coverage is 100%, so the structured schema already documents all five parameters. The description largely repeats the schema's parameter summaries and defaults without adding deeper meaning, such as value semantics or relationships between parameters.

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 ('Get'), the resource ('all campaigns'), and the scope ('for an ad account'), with optional filters. This immediately distinguishes it from sibling tools like create_campaign, update_campaign, get_ad_sets, and get_ads.

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

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

The description gives clear context for when to use the tool: to retrieve campaigns for a given ad account, with optional search, status, and pagination filters. It does not explicitly name alternatives or exclusions, but the usage intent 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 already convey the safety profile (not read-only, not destructive, idempotent), and the description does not add meaningful behavioral details beyond restating the update action and a vague 'Returns: Updated ad details'. It does not disclose partial vs full replacement semantics, side effects, or what happens to omitted fields, so transparency is limted.

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 structurally organized and front-loaded with a clear purpose sentence. However, the extensive Args block largely duplicates what the input schema already provides, which reduces the value of the description and makes it less concise than it could be.

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

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

With a rich schema and helpful annotations, the definition is mostly functional for basic use. However, there is no output schema and the return description is vague ('Updated ad details'), and the description leaves update semantics (partial vs full replacement) unclear. This is a noticeable gap for a complex update operation.

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 fully documents all parameters. The description's Args section mostly repeats schema content without adding new meaning, such as format constraints, default behavior, or relationships between parameters. Therefore a baseline of 3 is appropriate.

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

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

The description clearly states a specific operation ('Update an existing ad's content and settings') with a clear resource. It is distinguishable from create/get tools, but it does not explicitly distinguish itself from the sibling newsbreak_update_ad_status, which is a closely related update operation.

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

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

The phrase 'existing ad' implies the tool is for updating already-created ads, which gives some usage context. However, it does not provide explicit guidance on when to prefer this tool over newsbreak_update_ad_status, nor does it mention any prerequisites or exclusions.

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

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

Annotations already cover readOnly=false, idempotent=true, and destructive=false, so the description does not need to restate them. It adds a useful return note ('Returns: Updated ad set details') because no output schema exists, but it does not disclose partial-update behavior, permissions, or side effects beyond that.

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 front-loaded with a clear purpose sentence and ends with a useful return note. The long Args block is structured but largely duplicative of the schema, making the description longer than necessary while still remaining scannable.

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

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

The schema and annotations cover most parameter and safety details for this complex 15-parameter tool. The description adds a return note but does not clarify whether unspecified optional fields are left unchanged or reset, which is an important behavior for an update operation.

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 Args list mostly duplicates information already present in the input schema. It also omits iosAppId and googlePlayId, though the schema documents those. No additional semantic meaning is added 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 states a specific action ('Update') on a clear resource ('an existing ad set's configuration'), which distinguishes it from create_ad_set and update_ad_set_status. It does not explicitly name sibling tools, so it stops short of a full 5.

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

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

The phrase 'existing ad set's configuration' implies when to use the tool: to modify configuration on an already-created ad set rather than to create or status-update. However, it does not explicitly state when not to use it or which alternatives to prefer.

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

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

Annotations already declare readOnlyHint=false and idempotenceHint=true, so the description doesn't need to repeat that this tool mutates. It does add a useful return-value hint ('Updated ad set details') and clarifies the action is a toggle between ON/OFF. It does not describe potential downstream effects on ads within the ad set, but that is a minor gap given the simple operation.

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 minimal and efficient: one clear core-action sentence followed by a compact Args/Returns structure. Every part earns its place, with the purpose front-loaded and 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 simple two-parameter status toggle, the description covers the inputs and gives a basic return expectation. Annotations supply the idempotence and mutation profile. The only missing context is explicit guidance about side effects on child ads or when to use a sibling tool, but the tool is straightforward enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, and the schema already documents both adSetId and status, including the ON/OFF enum. The description repeats essentially the same parameter information without adding extra detail such as format, prerequisites, or edge-case behavior, so it stays at the baseline for full schema coverage.

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

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

The description opens with a specific verb and resource: 'Enable or disable an ad set.' This clearly distinguishes the tool from sibling tools like newsbreak_update_ad_set, which handles other ad set fields, and newsbreak_update_ad_status, which targets a different entity.

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 intended usage is implied by 'Enable or disable an ad set,' which tells an agent this is the tool for toggling ON/OFF status. However, it does not explicitly mention alternatives or when not to use it, such as deferring to newsbreak_update_ad_set for non-status changes.

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 communicate that the operation is not read-only, is idempotent, and is not destructive. The description adds the concrete behavioral effect of enabling or disabling an ad and notes that updated ad details are returned, which is useful but not extensive. There is no contradiction with the annotations.

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

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

The description is short, front-loaded with the primary purpose, and the parameter list is clearly structured. It is efficient, though the Args section is somewhat redundant with the rich schema and could have been trimmed without losing information.

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

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

For a simple two-parameter update tool, the description covers the operation, the parameters, and the return value ('Updated ad details'), even though no output schema exists. Missing exclusions or alternative routing is a minor gap but does not prevent correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents adId and status with meaningful descriptions. The description's Args section largely restates the same information, adding no new semantic detail beyond what the schema provides. A 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 opens with 'Enable or disable an ad,' a clear verb and resource that tells the agent exactly what the tool does. It is distinct from siblings like 'update_ad' or 'update_campaign_status,' though it does not explicitly name a sibling to differentiate itself.

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

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

The description implies the tool is for toggling ad status between ON and OFF, but it provides no explicit guidance on when to use it versus update_ad, update_campaign_status, or update_ad_set_status. The sibling list shows alternatives exist, but the description does not help an agent choose among them.

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

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

Annotations already convey readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds only the return value ('Updated campaign details') and does not elaborate on side effects, validation, or failure behavior. 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 compact and well-structured: a one-line action statement, an Args block, and a Returns line. It avoids fluff, though the Args section is largely duplicative of the schema.

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

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

The tool is simple: two required string parameters, no nested objects, and no output schema. The description explains what it updates, what the parameters are, and what is returned. This is complete enough for an agent to call it correctly, though it lacks explicit usage-contrast guidance.

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 description simply restates the same parameter names, types, and required flags already present in the input schema. It adds no additional meaning 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 states a specific verb ('Update'), a specific resource ('existing campaign'), and a specific field ('name'). This clearly distinguishes it from sibling tools like newsbreak_update_campaign_status and newsbreak_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 makes it clear this is for renaming a campaign, so usage is implied rather than explicit. It does not name alternatives or state when not to use it, leaving the agent to infer from sibling tool names.

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 establish that the tool is non-readonly, idempotent, and non-destructive. The description adds the concrete behavioral effect (toggling status between ON and OFF) and states that updated campaign details are returned, which is useful since no output schema is provided. No contraciction with annotations.

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

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

The description is short and front-loaded with the main behavior, and the return-value note is helpful. The Args section is slightly redundant with the schema, but the overall structure remains efficient and easy to scan.

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 status toggle, the description, schema, and annotations together give enough information to call the tool correctly: required params, accepted values, effect, and return shape. It does not explain campaign ownership prerequisites or edge cases, but these are not central for this tool.

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

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

Schema coverage is 100%, with descriptions for both campaignId and status; the description's Args block essentially restates the schema rather than adding new semantic meaning. The enum on status is captured in both places, so the description provides no additional parameter insight beyond the schema.

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

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

The description opens with 'Enable or disable a campaign,' which states a clear action and resource, and the title adds the resource (campaign). It is distinguishable from the sibling update_campaign because it specifically toggles campaign status, though it does not explicitly name that sibling or other status 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 action 'Enable or disable a campaign' implies when this tool should be used, but the description gives no explicit guidance on when to prefer it over update_campaign for other campaign edits or over analogous status tools for ad sets and ads. No alternatives or exclusions 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 already indicate this is a write, non-idempotent, non-destructive operation. The description adds useful behavioral context: the asset is uploaded to NewsBreak CDN, may be saved to the Media Library, and returns assetUrl/mediaId. However, it does not disclose potential side effects such as duplicate uploads, file size or format limits, or auth/permission requirements.

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 front-loaded with the core purpose and uses a compact Args/Returns structure. It remains readable and avoids fluff, though the Args list repeats information already in the schema.

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

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

There is no output schema, so the Returns section usefully supplies the expected result (assetUrl and mediaId). All parameters and the conditional requirement are covered in one place. It is complete enough for a straightforward upload tool, though minor operational details such as size limits or supported file types are absent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description mostly restates the parameter meanings and the conditional relationship between saveToMediaLibrary and mediaName, which is also present in the schema. It adds little beyond the structured definition.

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 a specific action ('Upload an image, video, or GIF asset to NewsBreak CDN') and the downstream purpose ('The returned assetUrl can then be used when creating ads'). It distinguishes this tool from the campaign/ad-management siblings because none of them handle asset uploads.

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 clear workflow context by explaining that the returned assetUrl is intended for ad creation. It does not name explicit alternatives or exclusions, but among the listed siblings this is the only asset-upload tool, so the usage context is sufficiently clear.

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