Skip to main content
Glama

Google Ads: create conversion action

create_conversion_action

Creates a Google Ads conversion action (what the account counts as a result) and returns its website tag: the code snippet, and the conversion ID and label a Tag Manager tag needs.

Only type WEBPAGE can be created: a result counted by a Google Ads
conversion tag on the website. Stage that tag in Tag Manager with the
returned conversion_id and conversion_label (the "Google Ads Conversion
Tracking" tag, fired on the sign-up / thank-you trigger); nothing is
counted until the user publishes the Tag Manager container. A site
without Tag Manager installs the returned tag_snippet instead:
global_site_tag in the <head> of every page and event_snippet on the
conversion page (click_event_snippet, when present, counts a click).

Analytics-imported types (GOOGLE_ANALYTICS_4_CUSTOM, _PURCHASE) cannot be
created through the Google Ads API and are refused with an explanation.

This tool creates one ENABLED action and changes nothing else: it never
edits, demotes or removes an existing conversion action or goal.
primary_for_goal has no default on purpose — a primary action is one the
account's bidding aims for, so ask the user and pass their answer.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    name: The conversion action's name, unique in the account
        (e.g. "Sign-up (website)").
    category: What the result is. One of: SIGNUP, SUBMIT_LEAD_FORM,
        PURCHASE, CONTACT, BOOK_APPOINTMENT, REQUEST_QUOTE, SUBSCRIBE_PAID,
        BEGIN_CHECKOUT, ADD_TO_CART, DOWNLOAD, GET_DIRECTIONS,
        OUTBOUND_CLICK, PAGE_VIEW, DEFAULT.
    primary_for_goal: True makes this a primary action — campaigns that
        bid for conversions aim for it. False records it as secondary
        (reported, not bid on). Required: pass what the user chose.
    type: The conversion action type. Only WEBPAGE is supported.
    counting_type: ONE_PER_CLICK (one result per ad click — right for
        sign-ups and leads) or MANY_PER_CLICK (every result — right for
        purchases). Defaults to MANY_PER_CLICK for PURCHASE and
        ONE_PER_CLICK for every other category.
    default_value: The value of one result, in the account's currency
        (a plain amount, not micros). Optional; no value is set if omitted.
    default_currency_code: ISO 4217 currency code for default_value,
        e.g. the account's own currency. Optional.
    always_use_default_value: True always records default_value, ignoring
        any value the tag sends. Optional.
    click_through_lookback_window_days: How many days after an ad click a
        result still counts (1-90). Optional; Google's default if omitted.

Returns:
    Dictionary with the new action's resource name and id, its
    conversion_id / conversion_label / send_to for the website tag, its
    tag_snippet (global_site_tag, event_snippet, and click_event_snippet
    when Google returns one), the other enabled primary actions already
    in this category (read only), and whether the account's goal for this
    category is biddable.

Tools revision: d80f65c0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "customer_id": "<customer_id>",
      "name": "<name>",
      "category": "<category>",
      "primary_for_goal": "<primary_for_goal>"
    },
    "name": "create_conversion_action"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
typeNoWEBPAGE
categoryYes
customer_idYes
counting_typeNo
default_valueNo
primary_for_goalYes
default_currency_codeNo
always_use_default_valueNo
click_through_lookback_window_daysNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation and safety profile is known. The description adds real value beyond them: it says exactly one enabled action is created, nothing else is modified, imported types are refused, and publishing in Tag Manager is required before results are counted. It also flags the deliberate lack of a default for primary_for_goal. A 3 reflects that this is solid supplemental context on top of annotations that already carry the core safety signal.

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

Conciseness4/5

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

It is front-loaded (purpose, then constraints, then returns, then per-argument detail) and every section is scannable. It runs long, and the phrase 'creates one ENABLED action and changes nothing else' is partly restated by the clause that follows it, which keeps it just short of a 5.

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 10-parameter creation tool with no schema descriptions, the description covers the full workflow, the constraint on supported type, parameter semantics and defaults, and expected return fields. An output schema exists, yet the returns paragraph still adds the interpretive detail an agent needs to act on the response.

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

Parameters5/5

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

With 0% schema description coverage, the description carries the full burden and does so: it documents every one of the 10 parameters, enumerates the valid category values, explains counting_type semantics and its category-dependent default, clarifies that default_value is a plain amount in account currency rather than micros, and bounds the lookback window at 1-90 days.

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

Purpose4/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 Google Ads conversion action ... and returns its website tag') and clarifies its scope ('creates one ENABLED action and changes nothing else'). It distinguishes itself from mutating siblings by stating it never edits, demotes or removes existing actions, though it never names an alternative sibling such as conversion_setup_audit or ga4_create_conversion_event.

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

Usage Guidelines4/5

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

It gives clear operational context: only WEBPAGE can be created, the returned tag must be staged in Tag Manager and published before anything counts, and non-Tag-Manager sites should install tag_snippet instead. It also explains that analytics-imported types are refused with an explanation. What is missing is an explicit routing statement naming which sibling to use instead for auditing or editing existing conversion actions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources