Metadata MCP Connector

Create Google Ads Image Extension (BETA)

create_google_image_extension

Attach visual imagery (1-20 product / lifestyle shots) to a Google Ads text ad to lift click-through. BETA. Re-uses assets already uploaded to the Metadata image library — pass their IDs, not raw files.

            ALSO KNOWN AS: image extension, image asset, ad image, visual extension, picture extension, photo extension, hero image

            KEYWORDS: image, image extension, photo, picture, visual, hero, asset, library, BETA, google ads, extension, CTR

            WHEN TO USE:
            - "Attach images to our Google Ads text ad"
            - "Add image library IDs 123 and 456 as an image extension"
            - "Create an image extension showing product photos under our search ads"

            WHEN NOT TO USE:
            - The image is a logo / brand mark → use create_google_business_logo_extension
            - You haven't uploaded the assets yet — image extensions reference library IDs, so upload to the image library first.
            - Want to drive clicks via text snippets → use create_google_sitelink_extension / callout
            - Same images for Microsoft Ads / Bing → use create_microsoft_image_extension

            INPUTS:
            - image_library_ids (required): 1-20 IDs from the Metadata image library.
            - alternative_text:  accessibility alt text (≤90 chars).
            - display_text:      short caption overlaid on the image (≤35 chars). E.g. "Shop Now".
            - destination_url:   landing page when the image is clicked.

            EXAMPLE:
            create_google_image_extension(
                image_library_ids=[123, 456],
                alternative_text="Product hero shot",
                display_text="Shop Now",
                destination_url="https://example.com/landing",
            )

Input Schema

TableJSON Schema

Name	Required	Description
`display_text`	No
`destination_url`	No
`alternative_text`	No
`image_library_ids`	Yes	1-20 image-library IDs.

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 indicate readOnlyHint=false and destructiveHint=false, and the description does not contradict this. The description adds critical behavioral context beyond annotations: it is BETA, requires pre-uploaded library IDs rather than raw files, and implies mutation by 'attach'. It does not detail success/failure outcomes or permissions, but given annotations cover the safety profile, the added context is valuable.

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 distinct sections (ALSO KNOWN AS, KEYWORDS, WHEN TO USE, WHEN NOT TO USE, INPUTS, EXAMPLE). It front-loads the core purpose and then provides necessary routing and parameter detail. Some redundancy exists (ALSO KNOWN AS and KEYWORDS overlap), but each section serves a purpose for an AI agent searching and parsing.

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 mutation tool with no output schema, the description is comprehensive: it covers purpose, usage conditions, parameter semantics, an example, and sibling differentiators. Nothing critical is missing for an agent to correctly invoke the tool, including the prerequisite that assets must already be in the library.

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?

Schema coverage is only 25% (only image_library_ids has a schema description). The description compensates fully by explaining each parameter: image_library_ids (required, 1-20), alternative_text (≤90 chars), display_text (≤35 chars with example 'Shop Now'), and destination_url (landing page). It also provides a complete example call, making parameter usage crystal clear.

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 clearly states the action ('Attach visual imagery') and the target resource ('Google Ads text ad'), plus the benefit ('lift click-through'). It also differentiates from siblings by naming alternatives like logo, sitelink, and Microsoft image extensions, making the tool's scope unambiguous.

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?

Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections provide clear conditions and name specific sibling tools (create_google_business_logo_extension, create_google_sitelink_extension, create_microsoft_image_extension). It also states the prerequisite of uploading assets to the library first, leaving no guesswork.

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?