Skip to main content
Glama
logly

mureo

by logly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

google_ads_campaigns_create

Create a Google Ads Search or Display campaign using a budget ID; returns the new campaign's resource name and ID.

Instructions

Creates a new Search or Display campaign in the specified Google Ads account. Returns the new campaign's resource_name and id. Mutating — counts against daily write quota. Not automatically reversible — record before-state with mureo_state_action_log_append if you may need to roll back. Requires a pre-existing budget_id; to create a budget first, call google_ads_budget_create. For later edits use google_ads_campaigns_update or google_ads_campaigns_update_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesCampaign name (max 255 chars). Must be unique within the account.
reasonNoWhy this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.
budget_idNoExisting campaign-budget ID to attach. Create one first with google_ads_budget_create if you do not have one.
customer_idNoGoogle Ads customer ID as a 10-digit string without dashes (e.g. '1234567890'). Optional — falls back to GOOGLE_ADS_CUSTOMER_ID / GOOGLE_ADS_LOGIN_CUSTOMER_ID from the configured credentials when omitted.
channel_typeNoAdvertising channel. SEARCH (default) for text ads on Google Search; DISPLAY for image/banner ads on the GDN.
bidding_strategyNoGoogle Ads bidding strategy. Defaults to MAXIMIZE_CLICKS when omitted. TARGET_CPA / TARGET_ROAS require additional target fields that this tool does not expose — use the Google Ads UI or a follow-up campaigns.update for those.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.0
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "Why this change is being made: one or two sentences naming the evidence and the expected effect. Stored in the journal and on the action_log entry this call produces, for the operator and the next session.",
+  "maxLength": 500,
+  "type": "string"
+}
  2. Changed1 schema field changedv0.10.37
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.10.11
  4. Removedv0.10.9
  5. Addedv0.9.12
  6. Removedv0.9.6
  7. Addedv0.9.2
  8. Removedv0.9.1
  9. Addedv1.0.5

TDQS

A4.5/5.0
Behavior4/5

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 clearly states the tool is mutating, counts against the daily write quota, is not automatically reversible, and advises recording before-state via mureo_state_action_log_append. This is strong coverage, though it could also mention permission requirements or default campaign status.

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 front-loaded with the core purpose and return value, then packs critical behavioral and routing information into compact sentences. Every sentence earns its place and there is no filler or repetition.

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?

For a mutating tool with no annotations and no output schema, the description covers purpose, return values, side effects, quota impact, rollback guidance, prerequisites, and alternative tools. An agent has enough context to call it correctly and anticipate consequences.

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

Parameters3/5

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 main description repeats the budget_id prerequisite and the TARGET_CPA/TARGET_ROAS limitation, but those details already exist in the parameter descriptions. It adds little semantic value beyond what the schema already provides.

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 opens with a specific verb and resource: 'Creates a new Search or Display campaign in the specified Google Ads account.' It also states the return values and differentiates from the update/update_status siblings by explicitly scoping this tool to creation.

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?

Gives explicit guidance on when to use this tool versus alternatives: requires a pre-existing budget_id and points to google_ads_budget_create for that prerequisite, and directs later edits to google_ads_campaigns_update or google_ads_campaigns_update_status. This is clear routing with no ambiguity.

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

Deploy Server

Other Tools