AdCopilot

Google Ads: link asset to campaign

link_asset_to_campaign

Destructive

Links an existing asset to a campaign.

In a campaign that is already running, the asset can show to the public
as soon as Google approves it, in place of any account-level assets of
the same type.

After creating an asset (sitelink, callout, etc.), use this tool to
attach it to a campaign so it appears with that campaign's ads.

Args:
    customer_id: The Google Ads customer ID (numbers only, no hyphens).
    campaign_id: The ID of the campaign to link the asset to.
    asset_resource_name: The resource name of the asset (from create_*_asset tools).
    field_type: The asset field type. One of: SITELINK, CALLOUT, STRUCTURED_SNIPPET,
        CALL, PROMOTION, PRICE, LEAD_FORM, MOBILE_APP, HOTEL_CALLOUT,
        BUSINESS_NAME, BUSINESS_LOGO, AD_IMAGE. For an image on a Search
        campaign use AD_IMAGE (Google requires an eligible account) or
        BUSINESS_LOGO; Performance Max images go through
        add_assets_to_asset_group instead.

Returns:
    Dictionary with the created campaign asset link resource name.

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>",
      "campaign_id": "<campaign_id>",
      "asset_resource_name": "<asset_resource_name>",
      "field_type": "<field_type>"
    },
    "name": "link_asset_to_campaign"
  }
}

Input Schema

Name	Required	Description	Default
`field_type`	Yes
`campaign_id`	Yes
`customer_id`	Yes
`asset_resource_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, so the bar is lower, yet the description still adds real context: the asset can go live to the public immediately on Google approval and supersede account-level assets of the same type, plus the AD_IMAGE eligibility caveat. It does not address what happens on a duplicate link or how to undo the link, leaving the destructive/idempotency implications only in the annotations.

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?

Front-loaded with the core purpose, then behavioral impact, then parameters — a sensible order with no filler sentences. There is minor redundancy between 'attach it to a campaign so it appears with that campaign's ads' and the earlier statement about showing to the public, and the Returns line duplicates the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter mutation tool with an output schema, the definition covers purpose, prerequisites, field-type selection, and go-live impact. Remaining gaps are the destructive/idempotency implications (duplicate links, how to detach via set_campaign_asset_status) which the annotations flag but the description never explains.

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 it: all four parameters are documented with added meaning beyond their names — customer ID format (digits only, no hyphens), asset_resource_name provenance (from create_*_asset tools), and the complete field_type enumeration with per-type routing notes. Without the Args block an agent could not populate field_type correctly from the schema, which only declares it as a bare string.

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+resource pair ('Links an existing asset to a campaign') and immediately scopes it against the account-level case. It also names the confusable siblings explicitly (add_assets_to_asset_group for Performance Max images, create_*_asset tools as the prerequisite), so an agent can distinguish it from link_asset_to_ad_group and link_assets_to_customer.

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 clearly states the workflow position: create the asset first, then use this tool to attach it to a campaign. It also routes one specific case away to add_assets_to_asset_group, which is genuine when-not guidance. It stops short of stating exclusions versus the ad-group and customer-level linking siblings, which are the other obvious alternatives an agent would weigh.

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?