Skip to main content
Glama
ibrahimhajjaj

seo-console-mcp

ads_keyword_create

Add a keyword to an ad group while preventing duplicate or conflicting entries; dry run shows guard trips before any change is made.

Instructions

Add one keyword to an ad group. This is the only tool here that creates rather than changes, and it is guarded differently for that reason: there is no current value to compare against, so it is a duplicate check instead. It refuses a keyword that already exists in the target ad group, including a removed one, since a removed criterion still holds the text and Google rejects the create with an error naming a resource the interface does not show. A copy elsewhere in the account trips a guard rather than refusing, because two copies compete for the same budget. EXACT by default; PHRASE and BROAD buy more than the text written and each trips a guard. Dry run unless dryRun is false, and the keyword is read back afterwards

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidYesThe max CPC bid in dollars. There is no current bid to compare against on a create, so the only size check is the ceiling
dryRunNoReport what would be added and which guards it trips, without adding anything
adGroupYesThe ad group to add it to. It must match exactly one or nothing is added
confirmNoAdd it even though a guard tripped. The dry run lists every reason, so this confirms something already read
keywordYesThe keyword text to add. It is created as written; this tool does not guess at variants
matchTypeNoHow the keyword matches. EXACT by default because it is the one that buys what it says; PHRASE and BROAD buy more than the text written here and each trips a guardEXACT

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bidYes
notesYes
guardsYesA create is guarded by a duplicate check rather than a before-and-after comparison, because there is no before
adGroupYes
appliedYes
keywordYes
matchesYes
campaignYes
readBackYesThe keyword as the account holds it after the write. Null when it could not be read back, which is not the same as not created
matchTypeYes
customerIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.18.0

TDQS

A4.9/5.0
Behavior5/5

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 discloses several behavioral traits: duplicate checking (including removed keywords), account-copy guard, match-type consequences (EXACT vs PHRASE/BROAD buying more), default dry-run behavior, and read-back after creation. These are significant operational details beyond what the schema reveals (e.g., dryRun default). No contradictions with annotations since none are present.

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

Conciseness5/5

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

The description is compact yet dense, with every sentence contributing new operational insight. It front-loads the core action, then layers guard logic and defaults. No fluff or repetition; a model agent can quickly grasp the essential behavior and the reasons behind it. The multi-sentence structure is justified by the complexity of the tool's safeguards.

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

Completeness5/5

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

Given the tool's complexity (6 parameters, guard mechanisms, dry-run semantics), the description covers all necessary details: what happens on create, how duplicates and copies are handled, match-type trade-offs, dry-run default, confirmation requirement, and post-readback. The output schema is present, so return format is documented elsewhere. No major gaps remain for an agent to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100% meaning all six parameters have descriptions. However, the description adds context beyond the schema: it explains the guard logic for duplicate keywords (relates to 'keyword' and 'adGroup'), the reason EXACT is default, and the implications of matchType. It also clarifies the bid ceiling check rationale. While the schema already documents parameters, the description enriches the semantics, especially for behaviorally relevant fields like dryRun and confirm. Slight deduct for not adding explanation to the existing param descriptions, but the integration is strong.

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

Purpose5/5

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

The description leads with a clear, specific verb and resource: 'Add one keyword to an ad group.' It immediately differentiates this tool from siblings by stating it is 'the only tool here that creates rather than changes,' which disambiguates it from ads_update and ads_negatives_update. The phrase 'guarded differently' further signals unique behavior.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool ('Add one keyword') and contrasts it with other tools ('only tool here that creates rather than changes'). It also explains when not to use it indirectly: the duplicate and copy guards define constraints on when the tool will succeed. The dry-run behavior and confirm parameter provide a clear usage workflow, effectively guiding when to invoke with dryRun=false.

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