Apple Search Ads MCP by Nova (CIVAI)

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

With no annotations, the description carries the full burden for a write operation and discloses almost nothing behavioral. It does not say what happens on duplicate keywords, whether ad_group_id or campaign_id is required in practice, whether the call is idempotent, what errors look like, or what 'array POST' implies for batching.

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

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

The description is a single front-loaded sentence with no filler. It is arguably too terse for a seven-parameter mutation tool, but that is a completeness issue rather than a conciseness problem.

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 seven parameters, no annotations, and no output schema, the description leaves significant gaps: required context (ad_group_id vs campaign_id), duplicate handling, batch semantics implied by 'array POST', and the effect on existing keywords are all unaddressed. It is not sufficient for an agent to invoke the tool confidently.

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

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

Schema description coverage is 100%, so every parameter already has a description with defaults and constraints, making 3 the baseline. The description itself adds no parameter-level 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 ('Add'), resource ('targeting keyword'), and destination ('to an ad group'), which clearly separates it from update_targeting_keyword, delete_targeting_keyword, and list_targeting_keywords. It does not explicitly name those siblings, and the plural tool name versus singular 'a targeting keyword' creates minor ambiguity about whether one or many keywords are added.

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

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

There is no guidance on when to use this versus update_targeting_keyword or list_targeting_keywords, no prerequisites, and no exclusions. The '(CM API array POST)' note hints at the underlying API shape but does not tell an agent when this tool is the right choice.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a write operation through 'Create' and says nothing about default paused status, permissions, side effects, or what happens on failure.

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 with no wasted words and is front-loaded. However, it is so terse that it omits necessary context, making it under-specified rather than optimally concise.

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

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

For a mutation tool with six parameters and no annotations or output schema, the description is incomplete. It does not explain defaults (e.g., PAUSED status), required campaign existence, or the effect of the 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 100%, so the schema already documents all six parameters in detail. The description mentions campaign_id but adds no syntax, constraints, or meaning beyond what the schema provides, 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: 'Create ad group.' It also names the parent campaign, making the operation clear. However, it does not differentiate this creation tool from siblings such as create_campaign, update_ad_group, or list_ad_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?

The description gives no guidance on when to use this tool versus alternatives. It does not state prerequisites such as the campaign existing or how this differs from duplicate_campaign or update_ad_group.

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

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

With no annotations, the description carries the full burden; it does usefully disclose that campaigns are created in PAUSED state and that campaign_name must be unique, which are real behavioral traits. It omits what happens on a name collision, required permissions, and what is returned, leaving significant gaps 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?

Two short sentences, zero filler, with the critical scoping fact (default PAUSED) front-loaded right after the action. Nothing could be removed 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 7-parameter creation mutation with no annotations and no output schema, the description covers the action and the two most important behavioral facts but says nothing about the result (e.g., returned campaign ID) or error/permission conditions. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including defaults for app_adam_id, budget, currency, and status. The description adds nothing beyond re-stating the campaign_name requirement, 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?

States a specific verb (Create) and resource (Search Results campaign), plus the default state and the uniqueness constraint on the name. It does not explicitly contrast with siblings like duplicate_campaign or update_ad_group, so an agent must infer the boundaries, but the core purpose is unmistakable.

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

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

There is no statement of when to use this versus duplicate_campaign or create_ad_group, and no prerequisites (e.g., whether a campaign must not already exist). Only the 'default PAUSED' note hints at usage context, which is implied rather than guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that deletion is permanent and requires user confirmation, but it omits permission requirements, cascading effects, and what the response will contain.

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 short, front-loaded clauses. The action and its permanence come first, followed by the critical confirmation requirement. Nothing extraneous is included.

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

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

For a destructive mutation with no annotations and no output schema, the description covers permanence and confirmation but leaves out side effects, authorization needs, and result behavior. It is adequate but has clear gaps.

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

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

Schema coverage is 100%, so the input schema already documents all three parameters. The description adds no parameter-specific meaning beyond identifying the mutation, which is appropriate for 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 states a specific verb and resource: delete a campaign permanently. It also names the underlying GraphQL operation, making the action unambiguous. It does not explicitly differentiate from siblings, but the resource is clear enough to distinguish it from delete_targeting_keyword and other campaign tools.

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

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

It provides a clear safety prerequisite: confirm with the user first. Usage is implied by the action itself, but the description does not state when to prefer permanent deletion over alternatives or 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?

No annotations are provided, so the description carries the full burden for a destructive operation, yet it says nothing about irreversibility, required permissions, whether historical stats are retained, or what notification_message is used for. For a delete tool with zero annotation coverage this is a significant gap.

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

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

A single front-loaded sentence with no filler, which is efficient. The brevity works against it slightly since nothing else is communicated, but there is no wasted 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?

A destructive tool with no annotations, no output schema, and four parameters (including an unusual notification_message fallback field) needs more than one sentence. Missing coverage of irreversibility, side effects, and the notification_message behavior leaves the agent under-informed.

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 all four parameters already have documented meaning and the baseline is 3. The description adds no syntax, format, or cross-parameter semantics 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?

States a specific verb and resource ('Delete a targeting keyword from an ad group'), which clearly separates it from add_targeting_keywords, update_targeting_keyword, and list_targeting_keywords in the sibling set. It stops short of naming those alternatives explicitly, but the operation is unambiguous.

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

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

There is no guidance on when to use this instead of update_targeting_keyword or how to find a keyword_id first (e.g., via list_targeting_keywords). No prerequisites or preconditions are stated.

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

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

No annotations are supplied, so the description carries the full behavioral burden and does not meet it: it never states whether the duplicate is created paused (that fact lives only in the schema), whether source ads/keywords/budgets carry over, whether the call is idempotent, whether it requires write permission, or whether it returns the new campaign ID. Only one behavioural detail is offered, that ad placements default from the source supply sources.

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

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

Two short sentences with the action front-loaded and no filler. The second sentence is somewhat cryptic ('supplySources' is never defined) and the '(CM REST)' parenthetical is opaque, but there is no padding.

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

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

An eight-parameter mutating tool with no annotations and no output schema needs more: what gets copied, whether the result is returned, and what happens on name collisions are all unstated. The description is far too thin for 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 coverage is 100%, so the schema already documents all eight parameters including defaults like PAUSED and false. The description adds only 'adPlacements default from source supplySources', which largely restates the schema's '(default from source)' note and does not clarify the many string-typed booleans or the notification_message semantics. 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?

Clear specific verb+resource: 'Duplicate an existing campaign', with a platform hint '(CM REST)'. It is distinguishable from create_campaign, but the near-neighbour sibling reload_campaign_from_campaign is never acknowledged, leaving the agent to infer which of the two to use.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as create_campaign or reload_campaign_from_campaign. The agent must already know the campaign ID before it can pick this tool, and nothing in the text says so.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing. It does not say whether the change is idempotent, what permissions are required, what happens when the ad group is already in the target state, or how notification_message behaves when the follow-up reply fails.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity tips into under-specification for a mutation tool rather than excess.

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?

A four-parameter mutation tool with no annotations and no output schema needs more than one sentence. The description says nothing about side effects, permission requirements, or the notification_message fallback parameter, leaving the agent to guess at behavior.

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 required IDs and the status field are already documented, including the default of ENABLED. The description restates the status values the schema already lists and adds no syntax or format detail, 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 and resource: set ad group status to ENABLED or PAUSED. It is clear what the tool does, but it does not differentiate itself from sibling update_ad_group, and the name enable_ad_group suggests a narrower action than the PAUSED option the description offers.

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

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

No when-to-use guidance and no mention of the obvious alternative update_ad_group, which could also change status. The agent must infer that this is the dedicated status-toggle path rather than the general update path.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet beyond the '(PUT CM API)' hint it says nothing about permissions, reversibility, or whether omitted fields are preserved on a PUT. The pause-via-status behavior is only discoverable from the schema's ENABLED/PAUSED note, not the description.

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

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

A single front-loaded sentence with zero filler. It is arguably too terse for a mutation tool with five parameters, but nothing in it 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?

This is a mutation tool with no annotations, no output schema, and ambiguous PUT semantics, yet the description omits what changes are applied, whether unmentioned fields are cleared, and what a successful call returns. For a write operation with zero structured safety signals, it does too little.

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 all five parameters are already documented, including currency defaults and the status enum. The description adds no syntax, format, or interaction detail beyond what the schema states, 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 concrete verb and resource ('Update campaign status and/or daily budget') and usefully corrects the misleadingly narrow tool name enable_campaign, which alone would suggest only enabling. It does not differentiate from siblings like create_campaign, delete_campaign, or update_ad_group, leaving an agent to infer scope from the name.

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

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

No when-to-use, when-not-to-use, or alternative-tool guidance is given beyond the implicit fact that this mutates an existing campaign. An agent must guess whether to reach for this versus create_campaign/duplicate_campaign or update_ad_group for related edits.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the payload (name, status, budget, app metadata), which is valuable given there is no output schema, but it never states that this is a read-only operation, what the response envelope looks like, or what the 'reload' semantics in the underlying GQL imply. The internal endpoint reference hints at behavior without explaining 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?

A single compact sentence with the resource and return fields front-loaded; nothing is repeated or padded. The trailing GQL implementation name is the one element that does not earn its place for an agent selecting a 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 simple single-entity read with a fully documented schema and no output schema, listing the returned fields largely covers what the agent needs. Missing is confirmation that it is a non-mutating read and any note on error behavior for an invalid campaign_id, but nothing essential to invocation is absent.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including the adam_id default and the Referer-path rationale for ad_group_id. The description adds no parameter-level meaning beyond what the schema states, 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?

States a specific verb (get detail) and resource (campaign) and enumerates the returned fields (name, status, budget, app metadata), so the agent knows exactly what it retrieves. It does not distinguish itself from siblings like list_campaigns, but the singular 'detail' framing makes the single-campaign scope clear. The internal 'reloadCampaignFromAdGroupGQL' name adds noise rather than clarity.

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

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

There is no explicit guidance on when to use this versus list_campaigns (bulk listing) or reload_campaign_from_campaign (a near-identical sibling). Usage is only inferable from the required campaign_id and the word 'detail'. No prerequisites, no exclusions, no alternatives named.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses nothing: no indication of read-only vs mutating behavior, no permissions or auth requirements, no return shape or pagination. A four-word fragment is inadequate for a tool with zero annotation coverage.

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

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

Brevity here reflects under-specification rather than conciseness — a single fragment with no verb and no front-loaded explanation of action or purpose. It is not padded, but it fails to carry even minimal 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 annotations, no output schema, and two parameters whose purpose is unexplained relative to the stated topic, the description should do substantial work. Instead it offers a four-word fragment, leaving the agent unable to know what the tool returns or when to invoke it.

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

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

Schema description coverage is 100%, and both parameters (adam_id, notification_message) are documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, and notably does not reconcile why a 'column layout' tool takes an App Store ID and a user-facing notification message.

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 is a four-word noun fragment, 'Dashboard campaign column layout,' that essentially restates the tool name (get_campaign_grid_columns) without a verb. It never states that the tool retrieves or returns a column layout, so an agent cannot tell what action it performs or how it differs from siblings like get_general_setting or get_filter_sets.

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

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

There is no guidance on when to call this tool, when not to, or which sibling to prefer for related dashboard/settings data. The agent is left to infer usage entirely from the 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?

No annotations are provided, so the description carries the full burden and delivers nothing: no read-only confirmation, no auth/permission requirements, no note on what the defaults (adam_id 9025370, CAMPAIGNS) imply, and no indication of the return shape. A single noun phrase cannot cover a behavior profile for an unannotated 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?

It is short, but shortness here is under-specification rather than conciseness — a four-word fragment with no verb and no substantive content. Nothing is front-loaded because there is essentially nothing there.

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 annotations and no output schema, the description is the only place an agent could learn what this returns (a list? IDs? names?) and how filter_set_type affects results. None of that is present, leaving the definition inadequate for a tool that is likely the entry point to a filter-set workflow.

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

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

All three parameters are documented at 100% schema coverage, including defaults for adam_id and filter_set_type, so the baseline of 3 applies. The description itself adds no parameter meaning — it never mentions the app ID scoping, filter set type, or the odd notification_message parameter.

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

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

The description is a bare noun phrase, 'Saved dashboard filter sets.', which restates the tool name rather than stating a verb+resource action. An agent can infer it retrieves saved filter sets, but the scope (which dashboard, which app) and the operation are left implicit.

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 at all on when to call this versus siblings such as get_general_setting or get_campaign_grid_columns, nor any stated prerequisite or exclusion. The agent must guess the trigger condition entirely.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it says nothing about whether the call is read-only, whether it requires authentication or an active session, or what form the response takes. Only the implicit 'get' prefix in the name hints at a safe read 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?

It is very short and front-loaded with the resource, but it is an under-specified fragment rather than a sentence, and the brevity comes at the cost of a verb and scope detail rather than from tight editing. Nothing extraneous is present, but little is earned either.

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 tool with three optional parameters, no annotations, and no output schema, the agent needs to know what is returned when no setting name is supplied and what the defaults imply. The description supplies none of that, leaving the caller to reconstruct behavior from the schema descriptions alone.

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

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

Schema description coverage is 100%, with each of the three parameters (adam_id, general_setting_name, notification_message) documented in the schema itself, so the baseline is 3. The description adds nothing about parameter behavior, notably the non-obvious notification_message fallback text, but the schema already carries that 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 is a noun phrase that essentially restates the tool name, adding only the scope word 'Account' and one example value ('timezone'). There is no verb, so an agent must infer that this retrieves a setting rather than describing or updating one, and nothing distinguishes it from the many other get_* siblings.

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

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

No when-to-use guidance, no preconditions, and no mention of any alternative tool among the many siblings (get_campaign, get_filter_sets, session_status, etc.). The agent is left to infer that this is the tool for reading account-level configuration.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals the return shape (status, data[], pagination) and implies a read-only GET, but says nothing about authorization/Referer requirements, rate limits, or what the pagination behavior actually is — notably the schema has no page/limit parameters to control 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?

A single compact line with the resource front-loaded and no filler. It is efficient, though bordering on cryptic given how much is left unstated.

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 four-parameter, all-optional read tool with no output schema, the mention of return shape (status, data[], pagination) is genuinely useful. But the purpose of notification_message and the absence of any pagination controls in the schema leave the agent with an incomplete picture.

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 all four parameters are already documented in the schema and the baseline is 3. The description adds no meaning beyond that, and it does not explain the puzzling notification_message parameter on an inbox-read operation.

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

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

The description gives a verb+resource ("Search Ads notification inbox") plus the underlying endpoint, so the agent knows roughly what it touches. However "Search" is loose for what is a fetch of an inbox, and it never distinguishes itself from the sibling list_notifications, which an agent could easily confuse it with.

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

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

There is no statement of when to use this tool, no prerequisites, and no named alternative such as list_notifications. The agent must infer the choice from the name alone.

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

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

No annotations are provided, so the description carries the full burden, yet it says nothing about read-only behavior, permissions, pagination, or what happens when the optional date range is omitted. '(GraphQL)' hints at the transport but conveys no operational behavior.

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

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

It is a single fragment with no wasted words, but it is under-specified rather than efficiently concise. There is no front-loaded verb or scope sentence an agent can act on.

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

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

For a 5-parameter reporting tool with no annotations and no output schema, the description should explain date-range defaults and what metrics are returned. It does neither, so an agent must open the schema and guess at behavior.

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 campaign_id, adam_id, report_start_time, report_end_time, and notification_message are all documented in the schema. The description adds nothing beyond that, which is the baseline case when the schema does the heavy lifting.

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

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

The description identifies the resource ('Ad group metrics') and the scope ('for a campaign'), which is more than a tautology. But it uses no verb ('list'/'retrieve'), and it never distinguishes itself from the very similar sibling list_campaign_reports or from list_ad_groups, leaving the agent to infer the difference.

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

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

There is no statement of when to use this tool rather than list_campaign_reports, list_ad_groups, or get_campaign. The '(GraphQL)' tag is an implementation note, not usage guidance, so the agent gets no routing help.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a safe read operation, but the description does not address pagination, result limits, permissions, or what data is returned, leaving most behavioral traits unspecified.

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

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

The single sentence is front-loaded and free of waste. It is appropriately sized, though it is arguably too terse to serve as a complete tool definition.

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?

This is a simple read operation with a fully documented three-parameter schema, so the description covers the core action. However, without annotations or an output schema, it should do more to explain return behavior or filtering semantics.

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

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

Schema description coverage is 100%, so the schema already documents campaign_id and the optional ad_group_list_query filter. The description adds no parameter-level meaning beyond what the schema provides, making the baseline of 3 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 states a clear verb (List) and resource (ad groups) scoped to a campaign, which distinguishes it from mutation siblings like create_ad_group and update_ad_group. It does not explicitly contrast with list_campaigns or list_ad_group_reports, but the resource is specific enough to infer.

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 scoping phrase 'in a campaign,' so an agent can infer it is used when ad groups for a known campaign are needed. However, the description gives no explicit when-to-use guidance, prerequisites, or alternatives such as list_campaigns or search_apps.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: no return shape, no pagination, no date-range defaults, no note that it is read-only. The only behavioral signal is the embedded method name getReportsByCampaign, implying a retrieval 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?

A single short fragment with no wasted words, but the brevity is under-specification rather than concision. Nothing is front-loaded because there is nothing substantive to front-load.

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 five-parameter reporting tool with no annotations and no output schema, the description should explain what the report contains, how date ranges are interpreted, and what the caller gets back. None of that is present, leaving the agent guessing about return contents and default behavior.

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 all five parameters (adam_id, report_start_time, report_end_time, report_timezone, notification_message) are documented in the schema itself, making 3 the baseline. The description adds no additional meaning about date ranges or defaults, but the schema already does the heavy lifting.

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 is a noun phrase, "Campaign performance report (getReportsByCampaign)", that essentially restates the tool name rather than stating a verb and scope. The parenthetical API method name adds a small hint that this is a read/query operation, but an agent gets no statement of what is listed, in what granularity, or how it differs from the sibling list_ad_group_reports.

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

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

There is no guidance on when to use this tool versus alternatives such as list_campaign_reports-adjacent siblings like list_ad_group_reports or list_campaigns, nor any prerequisites or exclusions. Usage must be inferred entirely from the 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?

No annotations are provided, so the description carries the full burden and it discloses almost nothing: no pagination/limit behavior, no result ordering, no statement of what happens when app_adam_id is omitted (the schema hints at a default app). The interesting param, notification_message, implies a fallback-reply mechanism but its behavior is never explained in the description.

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

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

A single short sentence with the resource front-loaded, so nothing is buried. It is arguably too terse rather than padded, and the trailing "(CM API find)" is low-value jargon that 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?

With no annotations, no output schema, and all three parameters optional, the description should explain default scope (all campaigns for the default app?) and return shape, but it does neither. An agent cannot tell whether an empty call lists everything or errors.

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 already carries its own description, establishing a baseline of 3. The description mentions "for an app", loosely mapping to app_adam_id, but adds no semantics for campaign_list_query or the unusual notification_message parameter beyond what the schema says.

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?

"List campaigns for an app" states a clear verb and resource, so the core operation is unambiguous. However, with siblings like get_campaign, list_campaign_reports and get_filter_sets in the set, it does not say how this list differs from a single get or from the report listing. The parenthetical "CM API find" is backend jargon that adds little for an agent.

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

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

There is no statement of when to use this versus get_campaign, list_campaign_reports, or get_filter_sets. No prerequisites (auth, session) or exclusions are mentioned, so the agent must infer routing from sibling names alone.

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

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

No annotations are provided, so the description carries the full disclosure burden and does almost none of it: no indication of read vs write, permissions, pagination, or failure behavior. It also conflicts with the schema, which exposes campaign/ad-group and notification_message parameters that do not fit a plain inbox 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?

It is a single short clause with no filler, so nothing is wasted. However, brevity here reflects under-specification rather than disciplined editing; there is no front-loaded statement of what the tool actually does.

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 annotations, no output schema, and four non-obvious parameters, the definition needs far more than one sentence. The agent has no way to know the return shape, whether calling it mutates anything, or how its parameters relate to an inbox read.

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 all four parameters are documented in the schema itself, and the baseline of 3 applies. The description adds no parameter context, and notably does not explain why inbox-alias parameters include adam_id, campaign_id, ad_group_id, and notification_message.

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

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

The description identifies the tool only relationally: it is an alias of get_inbox with the "same inbox API." That tells an agent which sibling it duplicates, but never states in its own words what the tool returns or does (list notifications, read inbox messages), and the name list_notifications is not reconciled with the inbox framing.

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?

Saying "Alias for get_inbox" implies interchangeability but gives no rule for when an agent should pick this name over get_inbox, and no exclusions or preconditions. The agent must guess whether this is a deprecated shim, a preferred entry point, or identical in behavior.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no pagination, no return volume, no note on whether report_start_time/report_end_time narrow the results, and no clarification of what the 'GraphQL adgroup_targetedkeywords' reference implies for output shape. 'List' at least signals a non-mutating read, but that is the only behavioral cue.

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

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

A single front-loaded sentence with the target resource stated first and no filler. The parenthetical GraphQL name is of marginal value to an agent but is short enough not to be wasteful.

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

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

With six parameters, no annotations, and no output schema, the description does very little: it never states that campaign_id is required alongside ad_group_id, what the returned keyword records contain, or why a reporting date range would be passed to a keyword listing. For a tool of this shape the one-line description leaves significant gaps.

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

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

Schema description coverage is 100%, so all six parameters (including campaign_id, ad_group_id, date range, adam_id, notification_message) are already documented in the schema; the baseline of 3 applies. The description adds no meaning beyond the schema, and notably does not explain how the optional date range interacts with a keyword listing.

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

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

States a specific verb and resource ('List targeting keywords') plus the scope ('for an ad group'), which is enough to distinguish it from add_targeting_keywords and delete_targeting_keyword by the verb alone. It stops short of naming those siblings or clarifying what kind of keywords are returned (positive vs negative), so it is clear but not fully differentiated.

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

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

There is no explicit guidance on when to use this versus the sibling list/add/update/delete keyword tools, nor any prerequisites such as needing an existing ad group. Usage is only implied by the verb 'List' and the scope 'for an ad group'.

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

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

No annotations exist, so the description carries the full burden and largely fails: it says nothing about whether 'reload' mutates state, what the notification_message follow-up mechanism does (only implied in the schema), or what happens if the reload fails. The GraphQL/reporting-view note is the only added context.

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

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

A single short fragment with no wasted words, but it is under-specified rather than concise — it front-loads the data source instead of the action the tool performs.

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 name implying an action, no annotations, no output schema, and an unclear relationship to get_campaign, the description does not give an agent enough to call this correctly or interpret results. The notification_message error-path semantics are left entirely unexplained in prose.

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 all three parameters (adam_id, campaign_id, notification_message) are already documented in the schema. The description adds no further meaning such as ID formats or defaults, 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 identifies the resource (campaign detail) and its source (campaign reporting view / GraphQL), but the verb conflicts with the tool name 'reload_campaign_from_campaign', leaving it unclear whether this refreshes, re-fetches, or simply reads campaign data. It does not differentiate from the sibling get_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?

No indication of when to use this rather than get_campaign or list_campaign_reports, and no preconditions or exclusions are stated. The agent must guess from the name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about read-only behavior, result volume, pagination, or whether an empty result is an error. Most notably it never explains the odd notification_message parameter, which implies a follow-up reply mechanism the description does not describe.

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

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

A single short sentence with no waste and the resource front-loaded. It is terse to the point of under-specification, but it is not padded or buried.

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

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

For a search tool with no annotations and no output schema, the description should say what a hit looks like, whether the query is optional (required is empty), and what the notification_message is for. None of that is present, leaving the agent unable to predict call behavior.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no meaning beyond the schema and does not clarify the non-obvious notification_message parameter or how app_search_query matching works (substring, exact, empty = list all?).

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

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

The verb+resource ('Search ... apps') is identifiable, but 'promotable apps' and '(CM API)' are unexplained jargon, so an agent cannot tell what domain this searches or whether results are the promoted-app catalog. Nothing distinguishes it from sibling list/search tools such as get_filter_sets or 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?

No guidance on when to use this vs. the 25 sibling tools, no prerequisites, no indication of whether the search is mandatory before a promotion flow. The parenthetical '(CM API)' is the only context and it does not route the agent anywhere.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not clarify whether this is a read-only check, whether it triggers authentication, what happens when the session is invalid, or what the verification actually inspects. '(config + GetView)' hints at implementation details without explaining observable behavior.

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

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

The description is a single, front-loaded sentence with no wasted words. Its brevity is appropriate structurally, though the cryptic parenthetical reduces clarity rather than adding useful detail.

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 annotations and no output schema, the description should explain what 'verify session' returns or how it behaves. Instead, it leaves the agent guessing about the result, failure modes, and relationship to 'start_browser_auth', which is insufficient for a tool an agent may need to call before other campaign operations.

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 there is only one optional parameter ('notification_message'), so the schema already documents it adequately. The description adds no parameter-specific meaning, which is acceptable given the high coverage baseline.

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

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

The description states a specific verb ('Verify') and resource ('Apple Search Ads session'), which is better than a tautology. However, the parenthetical '(config + GetView)' is jargon and does not clearly distinguish this tool from the sibling 'start_browser_auth', so an agent cannot confidently tell the two apart 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?

There is no explicit guidance on when to use this tool versus 'start_browser_auth' or other session-related operations. The implied use case is checking session validity, but the description does not state prerequisites, exclusions, or what to do if verification fails.

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

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

With no annotations, the description carries the full burden and does well: it discloses the no-op/idempotent short-circuit when a saved session is valid, that the viewer is not opened in that case, and that force_reconnect destroys the saved cookie. It does not say whether the call blocks while the user signs in or what a failure result looks like.

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 default safe behavior, then the prerequisite, then the opt-in destructive path. Nothing extraneous; the repeated 'destructive' emphasis is proportionate to the risk.

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 the branching behavior, prerequisite, and risk for a one-parameter tool with no output schema. The only gap is what the tool returns or how long it blocks during interactive sign-in.

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 single parameter is already well documented, so baseline is 3; the description adds a usage-level condition (only on explicit user request to sign out/reconnect/clear session) that reinforces the destructive semantics beyond the schema wording.

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 ('Open App Store Connect sign-in') plus the scope constraint ('only when needed'), and names the sibling that should gate it (session_status). An agent can distinguish it from login and session_status without further reading.

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

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

Explicit ordering ('Call session_status first') and an explicit exclusion for the destructive path ('Use force_reconnect only when the user explicitly wants to wipe the saved cookie'). Both when-to-use and when-not-to-use are stated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states which fields can be updated but omits mutation side effects, permission requirements, whether omitted fields remain unchanged, and what happens on failure.

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

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

The description is a single, front-loaded sentence with no wasted wording. It immediately states the operation and the affected fields.

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 rich schema covers all parameters, so the description is minimally sufficient for invocation. However, for a mutation tool with no annotations and no output schema, it should better address side effects and expected response behavior.

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 seven parameters in detail. The description merely restates the three main optional updatable fields and does not add syntax or format details 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 names a specific verb (Update) and resource (ad group), then lists the exact updatable fields: status, name, and default max CPT bid. It is clear what the tool does, though it does not explicitly distinguish itself from sibling enable_ad_group, which also changes 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 description provides no when-to-use guidance and does not mention alternatives such as enable_ad_group or create_ad_group. An agent must infer usage from the tool name and schema alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says 'update' but does not disclose whether omitted fields are preserved, whether the update is partial or full-replace, permission requirements, or reversibility — significant gaps 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?

A single tight sentence with the resource and mutable fields front-loaded. No wasted words, though it is arguably too terse given the tool's complexity.

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

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

With 8 parameters, no annotations, and no output schema, the description is under-specified: it lists three updatable fields while the schema exposes match type and ids, and it never clarifies partial-update semantics or what the tool returns.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only highlights bid/status/text and says nothing about match_type, the id scoping params, or the notification_message fallback behavior, adding little 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?

States a specific verb (Update) and resource (targeting keyword) and names the updatable facets (bid, status, text). It is clearly distinct from delete_targeting_keyword and add_targeting_keywords, though it does not explicitly name those siblings as alternatives.

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

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

The phrase 'on an existing targeting keyword' implies this is the mutation path for already-created keywords, but there is no explicit when-to-use vs add_targeting_keywords/delete_targeting_keyword guidance or any stated preconditions.

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