update_keyword_bid

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the cap enforcement, the pre-rejection logic, the silent-ignore behavior of the underlying API, and the fact that the write path has never been live-verified. However, it does not mention what a successful call returns or whether the draft is actually applied, which would round out the behavioral picture.

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 lengthy but each sentence carries essential caveats that are critical for correct use. It front-loads the primary purpose and then layers restrictions and known limitations. While not terse, the density is justified given the complexity and failure modes; it could be tightened but is well ordered.

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 three-parameter tool with no output schema and no annotations, the description covers many important constraints and known limitations, including pre-rejection rules and live-verification status. However, it leaves gaps: it does not explain what the tool returns on success, and it fails to describe the parameters themselves (which is especially important given 0% schema coverage). These omissions make it incomplete for an agent that needs to call it correctly.

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

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

Schema description coverage is 0%, so the description was expected to compensate by explaining parameters, but it does not. It omits any per-parameter guidance: what units 'bid' uses, how 'keyword_id' and 'ad_group_id' relate, or any constraints. The parameter names are self-evident, but the description adds no extra 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?

The description states a specific verb ('Draft a keyword CPC bid change') and resource ('keyword bid') with an additional constraint (MS_ADS_MAX_CPC cap). It clearly distinguishes the tool from siblings like 'draft_keywords' (which creates keywords) and 'remove_keywords' (deletes them), so an agent can identify its unique function.

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

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

The description explicitly states when the tool is allowed ('ONLY when the ad group's effective bid strategy is in the MANUAL_BIDDING allowlist') and when it is not ('Pre-rejected for Smart Bidding'), including the reason (silent ignoring). It also describes the fail-closed behavior for unrecognized strategies, giving unambiguous guidance on when to call or avoid the tool.

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