Metadata MCP Connector

Remove Extensions from Native-Structure Campaign

remove_extensions_from_native_campaign

Destructive

Detach extensions from a native-structure Google Ads / Microsoft Ads campaign. The extension stays in the account library — only the campaign binding is removed.

            ALSO KNOWN AS: remove extension from campaign, detach sitelink, unlink extension, take sitelink off campaign

            KEYWORDS: remove, detach, unlink, unbind, extension, sitelink, callout, campaign, native, native structure, google ads, microsoft ads, bing

            WHEN TO USE:
            - "Remove that sitelink from campaign X"
            - "Take the old promotion extension off the native search campaign"
            - Undoing a wrong add_extensions_to_native_campaign call

            WHEN NOT TO USE:
            - Deleting the extension from the library entirely — this only unbinds it from one campaign
            - The campaign uses the Precision / METADATA structure — native-structure campaigns only

            INPUTS (all required):
            - campaign_id:    wizard campaign id
            - channel:        GOOGLE_ADS or MICROSOFT_ADS
            - extension_ids:  internal ids from list_extensions

            BEHAVIOUR: only the named ids are detached; other attachments are preserved. Safe to re-run.

            EXAMPLE:
            remove_extensions_from_native_campaign(campaign_id=8421, channel="GOOGLE_ADS", extension_ids=[551])

Input Schema

TableJSON Schema

Name	Required	Description
`channel`	Yes	Search channel. Ad extensions are a search-channel-only concept.
`campaign_id`	Yes	The wizard campaign id.
`extension_ids`	Yes	Internal library extension ids from list_extensions. These are the `id` field, NOT `externalId` (the ad platform's own id).

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description goes further by explaining that the extension remains in the library, only the campaign binding is removed, only the named IDs are detached, other attachments are preserved, and the operation is safe to re-run. This provides important context beyond the raw annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: summary, aliases, keywords, usage guidance, inputs, behavior, and example. The key facts are front-loaded, and the example illustrates a realistic call. While lengthy, every section earns its place and improves agent matching and invocation.

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?

With three fully documented parameters, clear behavior notes, explicit exclusions, and an example call, the description gives an agent everything needed to select and invoke the tool correctly. No output schema exists, but for a detachment operation the behavioral guarantees provided are sufficient for confident use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents campaign_id, channel, and extension_ids thoroughly, including the crucial warning that extension_ids are internal ids and not externalId. The description mostly repeats these facts rather than adding substantially new semantics. This is an acceptable baseline given full schema coverage.

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 states a specific action and resource ('Detach extensions from a native-structure campaign') and clearly distinguishes this from deleting the extension entirely and from precision/METADATA-structure campaigns. The 'ALSO KNOWN AS' list and examples further anchor the tool's purpose, and sibling tools like add_extensions_to_native_campaign make the differentiation obvious.

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 contains explicit WHEN TO USE and WHEN NOT TO USE sections, with concrete natural-language examples and the inverse operation (add_extensions_to_native_campaign) mentioned. It also explicitly excludes the precision/METADATA structure, leaving no ambiguity about when this tool applies versus a sibling.

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?