AdCopilot

Google Ads: create image asset

create_image_asset

Uploads a PNG or JPEG image (max 5120 KB) to the account's asset library.

Uploading it changes no ad: it shows only once added to an asset group
or linked to a campaign or ad group.

Where an image can then be used: Performance Max, through
add_assets_to_asset_group (MARKETING_IMAGE 1.91:1 min 600x314,
SQUARE_MARKETING_IMAGE 1:1 min 300x300, PORTRAIT_MARKETING_IMAGE 4:5
min 480x600, LOGO 1:1 min 128x128, LANDSCAPE_LOGO 4:1 min 512x128).
On Search, only as AD_IMAGE (campaign or ad group; Google requires an
eligible account) or BUSINESS_LOGO (campaign) via link_asset_to_campaign /
link_asset_to_ad_group — the marketing image and logo types above are
refused for Search campaigns.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    image_source: One of: an http(s) URL the server can download; a data
        URI (data:image/png;base64,...) when there is no public URL; or a
        file path, which only works when this server runs on the same
        machine as the file — a hosted connector needs a URL or data URI.
    asset_name: A name for the image asset.

Returns:
    Dictionary with the created asset resource name, and the image's
    mime_type, width and height.

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>",
      "image_source": "<image_source>",
      "asset_name": "<asset_name>"
    },
    "name": "create_image_asset"
  }
}

Input Schema

Name	Required	Description	Default
`asset_name`	Yes
`customer_id`	Yes
`image_source`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only convey the generic mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds behavior the annotations cannot: the 5120 KB size limit, PNG/JPEG format restriction, the fact that nothing is modified in any ad until linking occurs, and per-placement minimum-dimension rules. It also warns about the file-path source failing on a hosted connector, which is exactly the kind of operational caveat an agent needs before calling.

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 side-effect disclaimer and the placement/routing rules are front-loaded ahead of the Args section, and each paragraph earns its place. The long parenthetical listing aspect ratios and minimum dimensions is dense but functional; it costs some scannability without being wasted text.

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 three-parameter upload tool, the description covers the source modes, format and size limits, post-upload wiring requirements, and placement compatibility, and it briefly notes the return value even though an output schema exists. Nothing an agent needs to avoid a failed or misrouted upload is missing.

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 description coverage is 0%, so the description carries the full burden and does so: customer_id is constrained to numbers only with no hyphens, image_source documents three distinct modes (http(s) URL, data URI, local file path) plus the hosted-connector limitation, and asset_name is identified as the image asset's name. This is meaning well beyond the bare string types in the schema.

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 opening sentence names a specific verb and resource ('Uploads a PNG or JPEG image ... to the account's asset library') and implicitly separates it from the many other create_*_asset siblings by media type. An agent can tell immediately that this is the image-upload path, not text, sitelink, or callout assets.

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 description explicitly says uploading changes no ad and that the asset only takes effect after add_assets_to_asset_group or link_asset_to_campaign/link_asset_to_ad_group, naming those siblings directly. It goes further by enumerating which asset types are valid on Performance Max versus Search and states that marketing image and logo types are refused for Search campaigns, giving concrete when-not guidance.

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

All AdCopilot 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?