Metadata MCP Connector

Create Microsoft Ads Price Extension

create_microsoft_price_extension

Add a price-list shown beneath a Microsoft Ads (Bing) 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, microsoft ads, bing, extension

            WHEN TO USE:
            - "Show our pricing tiers under our Microsoft Ads"
            - "Add a Bing price extension with Basic / Pro / Scale plans"
            - "Register monthly subscription prices for the Microsoft Ads campaign"

            WHEN NOT TO USE:
            - Single time-bound discount (Black Friday 20% off, promo code) → use create_microsoft_promotion_extension
            - Non-priced offerings list (just names, no amounts) → use create_microsoft_structured_snippet_extension
            - Same price list for Google Ads → use create_google_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_microsoft_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.7/5.0

Behavior4/5

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

Annotations already indicate this is a mutating operation (readOnlyHint=false), and the description's 'Add' is consistent with that. It adds useful behavioral context about where the extension appears, the 3-8 tile constraint, and required fields per tile. It does not contradict the annotations, though it could go further on post-create behavior such as confirmation or replacement 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 long but well-structured with clear headings and front-loaded core purpose. The ALSO KNOWN AS and KEYWORDS sections somewhat overlap, but the WHEN TO USE, WHEN NOT TO USE, INPUTS, and EXAMPLE sections each carry real selection and invocation value.

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?

The tool has two parameters, one nested array with five subfields, and no output schema, and the description covers all required invocation knowledge: constraints, enums, field semantics, and an end-to-end example. There is no missing information an agent would need to construct a correct call.

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?

Although schema coverage is 100%, the description greatly enriches both parameters: it explains price_qualifier display variants with examples ('From $X', 'Up to $X'), details every price_offerings subfield including length, amount limits, and billing units, and provides a full example call. This meaningfully exceeds the schema's terse descriptions.

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 Microsoft Ads (Bing) ad', and immediately specifies the count and fields of the tiles. It distinguishes itself from sibling tools such as create_microsoft_promotion_extension, create_microsoft_structured_snippet_extension, and create_google_price_extension, so an agent can tell them apart without inspecting schemas.

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 WHEN TO USE section gives concrete natural-language triggers ('Show our pricing tiers under our Microsoft Ads'), and the WHEN NOT TO USE section names explicit alternatives for promotions, non-priced snippets, and Google Ads. This gives both positive and negative selection guidance, leaving little to inference.

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?