Camberstack: Google Ads

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the result granularity (per campaign) and that the window ends yesterday via the schema, which is modest but real context. It says nothing about result volume, whether zero-activity campaigns are included, or how metrics like cost per conversion are derived or nulled.

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 sentence with no filler, front-loading the metric list and the window scope. Every clause carries information and nothing is repeated from the title.

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

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

With no output schema in play, the description partially compensates by naming the metrics returned, which is the most important thing an agent needs to judge relevance. It still omits aggregation level beyond 'per campaign', result ordering, and whether the response is a single row or a list, leaving an agent to discover these by calling.

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%: both days (look-back window ending yesterday) and customer_id (format and provenance from list_accounts) are fully documented in the schema. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The description names a concrete resource (campaign performance) and enumerates the specific metrics returned: spend, clicks, conversions, cost per conversion, over a window. That is far better than a tautology of the title. However, it does not differentiate itself from siblings like run_gaql or find_wasted_spend, which an agent might reasonably consider for similar reporting questions.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as run_gaql for arbitrary queries or find_wasted_spend for the narrower diagnostic case. The only implied usage is that the tool is read-oriented, which the agent could infer 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds meaningful context beyond that: each change is logged and can be reversed with undo_changes, which tells the agent the operation is recoverable and auditable.

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

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

Three short sentences, front-loaded with the core action, then the precondition, then the reversibility note. 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 single-parameter mutation with rich annotations and no output schema, the description covers action, precondition, and recovery path adequately. Minor gap: no statement about what happens on failure or whether the proposal is consumed/expired after applying.

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?

Only one parameter with 100% schema description coverage ('The id returned by propose_changes'). The description reinforces the origin of the id but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Applies) and resource (a proposal from propose_changes) against the Google Ads account, which cleanly separates it from sibling tools like propose_changes and discard_proposal.

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

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

Gives an explicit precondition: 'Only call this after the user has explicitly approved that proposal,' and points to propose_changes as the source of the input. It doesn't spell out when-not to use or contrast with discard_proposal, but the gating condition is clear and actionable.

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

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

Annotations already establish this as a safe, non-open-world read (readOnlyHint=true, openWorldHint=false), so the description only needs to add context. It does so usefully: it discloses that the response centers on a personal upgrade/change-card link and distinguishes free vs. Pro tiers, which is non-obvious behavioral context.

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

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

Three short sentences with the core purpose front-loaded and the tier/link details following. Every sentence carries information, though the trailing free-features clause sits slightly apart from the primary function.

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

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

With no parameters, no output schema, and safety covered by annotations, the description correctly compensates by describing what the tool returns (plan state plus an upgrade/cancel link). It is essentially complete for a simple zero-arg status tool, lacking only explicit routing guidance to siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. Nothing in the description misrepresents the empty argument list.

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

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

The description states a specific verb and resource: it shows the user's Camberstack plan (free applied-changes remaining vs. Pro). That resource is clearly distinct from siblings like account_overview or run_gaql, though it does not explicitly name an alternative to compare against.

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 (check plan status to decide on upgrading), and the line that diagnosis, proposals, history and undo are always free implicitly tells the agent it does not need billing to gate those features. There is no explicit when-to-use or when-not guidance naming alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds value by listing the status categories returned (applied, failed, undone), but it omits pagination behavior, rate limits, and the fact that the result set is limited by the 'limit' parameter, which is referenced only in the schema.

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

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

A single sentence with no filler, front-loading the resource and the key return categories. Every word contributes to the purpose.

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

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

There is no output schema, so the description carries some burden for return values, and it does mention applied/failed/undone statuses. However, it omits pagination and result-limit behavior, and does not clarify that customer_id filters the history despite the description saying 'Every proposal,' leaving gaps for a filtered list 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 50%: customer_id has a schema description, but limit has none. The description does not mention either parameter, so it fails to compensate for the undocumented limit parameter and adds no meaning beyond the existing customer_id schema text.

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

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

The description states a specific resource (proposals made through Camberstack) and the information returned about them (applied, failed, undone). It clearly distinguishes this retrieval tool from mutation siblings like apply_changes or propose_changes, though it does not name an alternative explicitly.

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, no conditions for selecting this tool over siblings like account_overview, and no prerequisites. It is a noun phrase that implies viewing history but gives no usage context.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds the important effect that the proposal becomes unappliable, but it does not say whether the discard is reversible (relevant given the undo_changes sibling), what happens if the proposal is not open, or what permissions are required.

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 action and its consequence front-loaded; no filler. It could have used the remaining space for the precondition/reversibility detail, but as written it is efficient and readable.

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

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

For a mutation tool with no output schema, no parameter documentation, and no reversibility annotation, the description is too thin. It omits error/precondition behavior, permission requirements, and whether the state change can be undone, all of which an agent needs before invoking a state-mutating 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 0%, so the schema documents nothing about proposal_id beyond its type. The description never mentions the parameter, its identifier format, or where such an ID comes from (presumably propose_changes), leaving the sole required parameter unelaborated in both places.

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

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

Specific verb ('Marks ... as discarded') plus resource ('an open proposal') and a stated consequence ('so it cannot be applied'). It implies a state precondition ('open') that distinguishes it from siblings like apply_changes, but it never explicitly names or contrasts those 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?

The word 'open' hints at a precondition, but the description gives no explicit when-to-use guidance, no mention of what to do instead (e.g., undo_changes, apply_changes), and no note on when discarding is inappropriate. An agent must infer routing from the sibling list 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds specificity about what is actually destroyed (revoked access plus deleted stored credentials) and the confirmation gate, which is meaningful behavioral context beyond 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?

Two short sentences, front-loaded with the destructive action and followed by the confirmation requirement. No filler or redundancy.

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

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

For a single-parameter destructive tool with no output schema and annotations covering safety, the description is nearly complete. It omits only post-condition details such as irreversibility or whether re-authorization is needed later.

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 'confirm' parameter is fully documented in the schema, so the description carries no additional parameter burden. Baseline 3 is appropriate since the description adds nothing about parameter format or constraints.

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: revokes Google access and deletes stored credentials. This is unambiguous and clearly distinguishable from every sibling tool (none of which touch credentials or auth state).

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 notes the user must confirm, which is a prerequisite, but it does not articulate when to invoke this versus alternatives (e.g., a re-auth flow) or what happens afterwards. Usage is implied rather than guided, and the confirmation requirement largely restates the schema's 'ask the user first'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral detail beyond that: it discloses the internal ordering (conversion tracking checked first, which implicitly flags the accuracy caveat when tracking is broken) and what the tool emits. It does not mention cost, latency, or how the look-back interacts with data freshness.

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

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

Front-loaded with the outcome ('where money is going with nothing to show for it'), then a compact colon-delimited list of checks, then the output/handoff. Dense but every clause earns its place; only the parenthetical examples could be trimmed.

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 diagnostic with no output schema, the description does the necessary work of describing what comes back (suggested negative keywords) and where it flows next. A three-parameter, fully documented schema keeps the remaining needs modest, so this is nearly 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 days, campaign_id, and customer_id are already fully documented in the schema, including the 'ending yesterday' window semantics. The description adds no parameter-level meaning (e.g., how campaign_id scoping changes which checks run), 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?

Opens with a concrete verb+resource ('Diagnoses where money is going with nothing to show for it') and enumerates the exact checks it performs (conversion tracking, high-cost zero-conversion search terms, low-intent patterns, keywords to review). That is much more specific than a tautology, though it never explicitly contrasts itself with the data-retrieval siblings like run_gaql or account_overview.

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 handoff line ('suggested negative keywords ready to pass to propose_changes') gives useful workflow context and implies the tool is a pre-audit step. However there is no explicit when-to-use/when-not statement and no mention of alternatives for users who want raw query access.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope detail about including client accounts under an MCC and positions the tool as a starting point, though it omits pagination or return-shape details.

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 definition is two short sentences with zero waste, front-loading the core action and scope before the 'Start here' guidance. Every phrase earns its place.

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

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

Given a zero-parameter list tool with annotations covering safety and an empty schema, the description provides everything needed to call it correctly: what it lists, the scope including MCC accounts, and its role as a starting point. No output schema exists, but the return type is obvious from the verb.

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

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

The tool has zero parameters and 100% schema coverage, so the baseline of 4 applies. The description appropriately does not need to explain any parameter semantics.

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

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

The description uses a specific verb and resource ('Lists every Google Ads account this login can reach') and clarifies scope by including MCC client accounts. It is clear but does not explicitly differentiate itself from the sibling account_overview tool.

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

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

The phrase 'Start here' gives a clear usage context as an entry point, but the description does not name alternatives or state when not to use this tool, leaving some inference to the agent.

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

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description usefully adds that changes are dry-run against Google and that the live account is untouched. It does not describe failure behavior or what the stored proposal looks like, but the added behavioral context is substantive.

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

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

Front-loaded with the core behavior (dry-run, nothing changed) before the supported-types list, and every sentence carries operational weight. The trailing type list is partly redundant with the schema but is a reasonable quick reference.

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

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

For a 2-parameter but structurally complex tool, the description covers the approval workflow and the no-op guarantee well. However, the 'Supported' list omits remove_negative_keywords, which the schema accepts, risking an agent believing that operation is unsupported, and there is no output schema or mention of validation-failure outcomes.

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 nested change union and required fields are already fully documented; the description's only added value is enumerating change types. That enumeration is also incomplete — it lists six types but the schema supports seven (remove_negative_keywords is omitted), so it slightly under-informs rather than compensating.

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 specific verbs and resources: it validates changes against the live account, dry-runs them with Google, stores them as a proposal, and returns a summary. This is clearly separable from siblings like apply_changes, discard_proposal, and undo_changes without opening any schema.

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

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

Gives explicit workflow guidance: show the summary to the user and apply only after approval, which implies the handoff to apply_changes. It does not name apply_changes or discard_proposal directly or state what to do on validation failure, so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description still adds genuine value beyond them by disclosing the read-only SELECT constraint and the 500-row cap, which an agent needs to anticipate result truncation. It does not describe error behavior or how to page beyond 500 rows.

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

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

Two tight sentences with zero waste; the primary capability is front-loaded and the row cap is appended as a secondary constraint. Every clause 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 two-parameter query tool with no output schema, the description covers purpose, routing, and the row limit, which is enough to call it correctly. A note on pagination or failure modes would complete it, but the coverage is strong for the complexity.

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

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

Schema description coverage is 100%, with both parameters documented (query as a GAQL SELECT, customer_id with format and provenance from list_accounts). The description adds nothing about parameters beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Runs) and resource (read-only GAQL SELECT), and explicitly positions itself as the catch-all for questions the other tools don't cover. An agent can distinguish it from siblings like account_overview or find_wasted_spend without opening any schema.

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

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

Explicitly names the fallback condition ('questions the other tools don't cover'), which tells the agent when to reach for this instead of the specialized tools. It stops short of listing which specific questions require it or any exclusions, but the routing intent is clear.

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

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

With annotations covering safety flags (readOnlyHint=false, destructiveHint=false), the description still adds meaningful non-obvious behavior: this does not undo directly but generates a new proposal that must go through approval and application. It also discloses the reversal semantics. It stops short of noting what happens if the proposal was never applied.

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

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

Two tight sentences with zero waste; the core mechanism (builds a reversing proposal) is front-loaded and the workflow caveat follows.

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

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

For a one-parameter tool with no output schema, the description conveys the mechanism, the scope of reversal, and the approval requirement. The main missing piece is parameter-level detail and error/precondition behavior for a non-applied proposal.

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

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

Schema description coverage is 0% for the single proposal_id parameter, so the description must carry the meaning, yet it only refers to 'an applied one' without naming the parameter or clarifying its expected format or constraints. It does not compensate for the coverage gap.

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

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

The description states a specific verb and resource: it 'builds a new proposal that reverses an applied one,' and even enumerates the reversal scope (removes added negatives, restores statuses and budgets). It's clearly distinct from propose_changes as a special reversal case, though it never names a sibling to route against.

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 implies the workflow ('must be approved and applied') which tells the agent this is not an immediate action, but it gives no explicit when-to-use guidance versus alternatives like discard_proposal or apply_changes, nor any precondition such as the target having actually been applied.

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