Skip to main content
Glama

Metadata MCP Connector

by io.metadata.mcp-server
OverviewDiscussionsAdmin

Manage Experiment

manage_experiment
Destructive

Pause, restart or reactivate a whole experiment (a launched channel campaign inside a wizard campaign).

            KEYWORDS: pause, stop, restart, resume, unpause, reactivate, experiment, control, manage, halt

            WHEN TO USE:
            - User asks to "pause experiment X"
            - User wants to "stop the LinkedIn experiment"
            - User requests to "restart experiment Y"
            - User wants to "resume/unpause a paused experiment"
            - User wants a completed experiment to run again until a new end date

            SCOPE - DO NOT CONFUSE WITH SIMILAR TOOLS:
            - manage_experiment (this tool) acts on ONE WHOLE EXPERIMENT.
            - pause_experiment_keyword / restart_experiment_keyword act on ONE
              KEYWORD inside an experiment - they never pause the experiment itself.
            - manage_campaign acts on the whole wizard campaign, which can span
              several experiments/channels.
            - update_experiment_end_date moves the end date of a RUNNING Google Ads
              or Microsoft Ads experiment; reactivate (below) is for a COMPLETED one.

            ACTIONS:
            - pause: Stop ad serving and budget spend for the experiment
            - restart: Resume a paused experiment so it serves ads and spends again
            - reactivate: Run a Completed experiment again until end_date (required,
              YYYY-MM-DD, today or later; at most one year ahead on Facebook and
              Instagram). It spends again, so reactivate only when the user asked for it.

            WORKFLOW:
            1. Find the experiment: search_experiments(search_name="my experiment")
               and note experimentId and statusLabel from the results
            2. Pause it: manage_experiment(experiment_id=123, action="pause")
            3. Or restart it: manage_experiment(experiment_id=123, action="restart")
            4. Or reactivate a Completed one:
               manage_experiment(experiment_id=123, action="reactivate", end_date="2026-12-31")

            IMPORTANT VALIDATION REQUIREMENTS:
            - **CRITICAL**: You can ONLY pause experiments that are currently active
            - **CRITICAL**: You can ONLY restart experiments that are currently Paused
            - **CRITICAL**: You can ONLY reactivate experiments that are currently Completed
            - Use search_experiments first to verify the current experiment status

            RESTART AND REACTIVATE BUDGET CONFIRMATION FLOW:
            Restarting and reactivating first estimate the impact on budget groups
            (the same check the main UI runs). If any budget group is impacted, the
            tool does NOT act: it returns status="requires_confirmation" with the impacted
            groups in budgetImpact. Present the impact to the user, and only after
            they explicitly confirm, call again with confirm_budget_impact=true.

            WARNING: This changes the live state of the experiment on the ad channel.
            WARNING: ASYNC FLOW: The channel-side status change may take a moment to
            propagate. Verify later with search_experiments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesThe action to perform: 'pause' to stop the experiment, 'restart' to resume a paused one, 'reactivate' to run a completed one again until end_date
end_dateNoReactivate only, and required there: the new end date, YYYY-MM-DD, today or later (at most one year ahead on Facebook and Instagram).
experiment_idYesThe experiment ID to pause, restart or reactivate (experimentId from search_experiments).
confirm_budget_impactNoRestart and reactivate only. Set true ONLY after the user explicitly confirmed the budget-group impact returned by a previous manage_experiment call with status='requires_confirmation'.
auto_pause_ignore_historical_dataNoRestart only. When the experiment was auto-paused for low performance, true tells the optimizer to ignore the historical performance data that caused the pause.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"The action to perform: 'pause' to stop the experiment, 'restart' to resume it"New value: +"The action to perform: 'pause' to stop the experiment, 'restart' to resume a paused one, 'reactivate' to run a completed one again until end_date"
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "pause",
-  "restart"
-]New value: +[
+  "pause",
+  "restart",
+  "reactivate"
+]
    • changedInput schema / properties / confirm_budget_impact / description
      Previous value: -"Restart only. Set true ONLY after the user explicitly confirmed the budget-group impact returned by a previous manage_experiment call with status='requires_confirmation'."New value: +"Restart and reactivate only. Set true ONLY after the user explicitly confirmed the budget-group impact returned by a previous manage_experiment call with status='requires_confirmation'."
    • addedInput schema / properties / end_date
      Added value: +{
+  "description": "Reactivate only, and required there: the new end date, YYYY-MM-DD, today or later (at most one year ahead on Facebook and Instagram).",
+  "type": "string"
+}
    • changedInput schema / properties / experiment_id / description
      Previous value: -"The experiment ID to pause or restart (experimentId from search_experiments)."New value: +"The experiment ID to pause, restart or reactivate (experimentId from search_experiments)."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive/openWorld, and the description goes well beyond them: it documents the budget-impact confirmation flow (returns status='requires_confirmation' with budgetImpact and requires confirm_budget_impact=true), the live-state warning, and the async propagation caveat. This is exactly the extra behavioral context annotations cannot carry.

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-loads the core action and uses clear headers (WHEN TO USE, SCOPE, ACTIONS, WORKFLOW, VALIDATION, WARNING). The KEYWORDS line is largely redundant keyword stuffing, but the remaining length is earned by genuinely distinct content.

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 complex mutation tool with no output schema, the description covers state validation, the two-step confirmation handshake, channel-side async timing, and a verification path via search_experiments. No key calling requirement is left unstated.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: end_date is reactivate-only with a today-or-later and one-year-ahead FB/IG constraint, and the confirm_budget_impact gating condition is spelled out. The workflow examples show concrete call shapes, though some content duplicates the schema field descriptions.

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?

Opens with a specific verb set and resource ('Pause, restart or reactivate a whole experiment') and immediately qualifies the scope ('a launched channel campaign inside a wizard campaign'). The SCOPE section names each sibling that could be confused (pause_experiment_keyword, restart_experiment_keyword, manage_campaign, update_experiment_end_date) and states precisely how this tool differs.

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?

Provides explicit WHEN TO USE examples mapped to natural user phrasings ('pause experiment X', 'stop the LinkedIn experiment', 'resume/unpause'), plus a DO NOT CONFUSE section routing to the correct alternative for each adjacent intent. Also encodes state preconditions (only active can pause, only paused can restart, only completed can reactivate).

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 toolsInspect
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