Metadata MCP Connector

Create Google Ads Price Extension

create_google_price_extension

Add a price-list shown beneath a Google Ads ad — 3-8 tiles, each with a plan/product name, a short description, a USD amount, and a billing unit. Standard play for SaaS pricing tiers, subscription plans, course catalogs, service menus, or hotel night rates.

            ALSO KNOWN AS: price extension, pricing, price list, pricing tiers, plan pricing, subscription pricing, price tiles, rate card, fare list

            KEYWORDS: price, pricing, price list, plan, plans, tier, tiers, subscription, monthly, yearly, hourly, daily, fare, rate, cost, dollar, $, USD, google ads, extension

            WHEN TO USE:
            - "Show our pricing tiers under our Google Ads"
            - "Add a price extension with Basic / Pro / Scale plans"
            - "Register monthly subscription prices for the campaign"
            - "Create a rate card extension starting from $9.99"

            WHEN NOT TO USE:
            - Single time-bound discount (Black Friday 20% off, promo code) → use create_google_promotion_extension
            - Non-priced offerings list (just names, no amounts) → use create_google_structured_snippet_extension
            - Same price list for Microsoft Ads / Bing → use create_microsoft_price_extension

            INPUTS:
            - price_qualifier: prefix shown before each price. UNSPECIFIED (no prefix) | FROM ("From $X") | UP_TO ("Up to $X") | AVERAGE ("Avg $X").
            - price_offerings: 3-8 tiles. Each tile:
                - url:         landing page for that tier (non-blank, ≤2000 chars).
                - header:      tier name (1-25 chars). E.g. "Basic", "Pro", "Scale".
                - description: short tagline (1-25 chars). E.g. "Starter plan".
                - amount:      USD number (max 999999999.99, two decimals).
                - unit:        billing cadence. UNSPECIFIED | PER_HOUR | PER_DAY | PER_WEEK | PER_MONTH | PER_YEAR | PER_NIGHT.

            EXAMPLE:
            create_google_price_extension(
                price_qualifier="FROM",
                price_offerings=[
                    {"url": "https://example.com/basic", "header": "Basic",
                     "description": "Starter plan",  "amount": 9.99,  "unit": "PER_MONTH"},
                    {"url": "https://example.com/pro",   "header": "Pro",
                     "description": "Growing teams", "amount": 29.00, "unit": "PER_MONTH"},
                    {"url": "https://example.com/scale", "header": "Scale",
                     "description": "Enterprise",    "amount": 99.00, "unit": "PER_MONTH"},
                ],
            )

Input Schema

TableJSON Schema

Name	Required	Description	Default
`price_offerings`	Yes	3-8 price offerings.
`price_qualifier`	Yes	Price qualifier shown before the price.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already flag this as a mutation (readOnlyHint=false, destructiveHint=false). The description adds the placement context ('beneath a Google Ads ad') and the 3-8 tile constraint, but does not disclose any side effects, activation steps, or response behavior. It satisfies the mutation implication but adds little beyond annotations and the obvious create semantics.

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?

The description is well-structured with headers (WHEN TO USE, INPUTS, EXAMPLE) and front-loads the core action. The ALSO KNOWN AS and KEYWORDS sections add length but serve retrieval for natural-language user intents, so they earn their place. Minor redundancy between the intro and INPUTS keeps it from 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?

Given two parameters (one nested with five fields), no output schema, and a requirement to differentiate from six sibling extension tools, the description covers all input semantics, explicit examples, and decision routing. An agent has everything needed to call the tool 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%, but the description goes further by explaining the meaning of price_qualifier (e.g., FROM -> 'From $X'), the field-level constraints for each tile (lengths, amount range, billing unit examples), and providing a full usage example. This meaningfully adds to the bare schema definitions.

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: 'Add a price-list shown beneath a Google Ads ad.' It details the tile structure and explicitly names sibling alternatives in the WHEN NOT TO USE section, making it unambiguous against other extension-creation tools.

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?

WHEN TO USE gives concrete example intents, and WHEN NOT TO USE routes to three specific sibling tools (promotion, structured snippet, Microsoft price extension) with the exact disambiguating conditions. No inference is required.

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

All Metadata MCP Connector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?