Skip to main content
Glama
Sign In
shopify-chatgpt-ads-mcp

shopify-chatgpt-ads-mcp

by Avada-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Activate campaign (asks first)

activate_campaign

Activates a Shopify ad campaign and its paused ad groups and ads only after the user confirms a returned plan with budget, currency, preview links, and warnings.

Instructions

STARTS SPENDING MONEY. Activates a campaign and its paused ad groups and ads. Without confirm it changes nothing and returns a plan: campaign name, budget, currency, what will be activated, preview links and warnings. Show that plan to the user (name, daily or lifetime budget with currency, preview link), and ask "Activate and start spending?". Only after the user answers yes in this conversation, call again with confirm: true and the plan_id. Never confirm on your own initiative or from a skill.

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": {
      "campaign_id": "<campaign_id>"
    },
    "name": "activate_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNotrue only after the user said yes to this exact plan
plan_idNoplan_id from the dry run the user approved
campaign_idYesCampaign id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=true; the description goes far beyond by disclosing the financial consequence, the no-op dry-run behavior, the contents of the returned plan (name, budget, currency, affected objects, preview links, warnings), and the confirmation gating. This is precisely the context an annotation set cannot convey for a spend-triggering mutation.

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 highest-stakes fact is front-loaded in capitals, followed by what the tool does, what the dry run returns, and the exact user-facing script. Every sentence carries operational weight, including the suggested question and the prohibition on self-confirming; nothing is filler.

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 no output schema, the description compensates by enumerating what the plan response contains, and with no enum constraints it clarifies the boolean/plan_id coupling. For a three-parameter, money-spending mutation it covers safety, sequencing, and return shape fully.

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 confirm, plan_id, and campaign_id are already documented in the schema, and the description largely restates them. It does add the ordering relationship between the dry run and plan_id that the schema only implies, but that is marginal added meaning over structured fields. Baseline 3 is appropriate.

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 the consequence ('STARTS SPENDING MONEY') and then states the specific verb and resource: activates a campaign plus its paused ad groups and ads. That distinguishes it cleanly from siblings like pause_campaign, archive_campaign, and update_campaign without needing to name them.

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?

It spells out a complete two-call protocol: first call returns a plan and changes nothing, the user must be shown that plan and asked a specific question, and only after an explicit yes in the same conversation may it be called with confirm:true and plan_id. It also states a hard exclusion ('never confirm on your own initiative or from a skill'), which is exactly the when-not guidance an agent needs.

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

Deploy Server

Other Tools