Metadata MCP Connector

Unarchive Campaigns

unarchive_campaigns

Put archived campaigns back, with a result per campaign.

            An unarchived campaign is visible again under its name and no
            experiment restarts. The exception is a campaign that was waiting
            for its audiences to launch when it was archived: unarchiving
            resumes that launch and it starts spending, so such a campaign
            is only unarchived once its id is in confirm_pending_launch_ids.

            KEYWORDS: unarchive, restore, undo archive, recover, put back, campaign

            WHEN TO USE:
            - The user asks to restore or unarchive campaigns, or to undo an
              archive
            - To find archived campaigns, call list_wizard_campaigns with
              visibility ARCHIVED

            Each campaign is processed on its own, so one that cannot be put
            back does not stop the others. `results` holds one entry per
            campaign with its `outcome`:
            - unarchived
            - not_archived: it is not archived; nothing changed
            - not_in_account: no campaign with that id in this account
            - native_imported: imported from an ad channel account, which is
              never unarchived here
            - pending_launch: unarchiving would resume its pending launch;
              ask the user, then call again with only the campaigns the user
              agreed to in confirm_pending_launch_ids
            - name_taken: another visible campaign now holds its name, and
              `holder` names it. Offer to rename the holder; once the user
              agrees and it is renamed, unarchive again. Without a `holder`,
              the archived campaign may hold the name itself. Never rename an
              archived campaign: its name is what unarchive restores, so
              renaming it blocks its own unarchive.
            - not_attempted: the call stopped early (a rejected session or
              rate limiting) before reaching it
            - unknown: the platform's answer was lost; check the campaign
              before trying again
            - error: the platform refused it; `message` says why

            PARAMETERS:
            - campaign_ids (required): 1 to 50 campaign ids
            - confirm_pending_launch_ids (optional): the campaigns, among
              campaign_ids, whose pending launch the user agreed to resume

Input Schema

TableJSON Schema

Name	Required	Description	Default
`campaign_ids`	Yes	The ids of the campaigns to unarchive (1 to 50)
`confirm_pending_launch_ids`	No	Campaigns, among campaign_ids, whose pending launch (and spend) the user agreed to resume

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses non-atomic processing, the pending-launch spending risk, and enumerates every possible outcome with explanations (e.g., name_taken, not_attempted, error). It even warns about renaming archived campaigns, adding crucial behavioral context.

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 long but structured with clear sections (core statement, WHEN TO USE, outcomes, parameters). Every sentence serves a purpose—the exhaustive outcome list is essential for correct invocation, and the layout front-loads the primary action while keeping details organized.

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?

Given no output schema and the tool's complexity (per-campaign outcomes, pending launch, name collisions), the description covers all necessary scenarios, including edge cases like rate limiting and lost responses. An agent has everything needed to call it correctly and interpret results.

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 coverage is 100% and both parameters have descriptive schema entries. The description's PARAMETERS section essentially restates the schema (1-50 ids, confirm_pending_launch_ids for agreed resumptions) without adding new meaning. It satisfies the baseline but doesn't elevate beyond it.

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 'Put archived campaigns back', a specific verb and resource, and distinguishes itself from siblings like unarchive_ad and unarchive_audience by focusing on campaigns. It also clarifies the per-campaign result model, 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?

A dedicated 'WHEN TO USE' section explicitly states the triggering user requests and directs users to list_wizard_campaigns to find archived campaigns. It also implies when not to use (e.g., for native_imported campaigns) and covers the pending-launch confirmation flow.

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?