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

shopify-chatgpt-ads-mcp

by Avada-AI

List campaigns

list_campaigns
Read-only

Retrieve ad campaigns with status, objective, budget, targeting, and optional serving issues, with pagination for reviewing active campaigns and diagnosing delivery problems.

Instructions

Campaigns in the ad account with status, objective, budget (micros and readable amount) and targeting. Archived campaigns are not listed by OpenAI; read one with get_campaign.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_campaigns"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNolast_id of the previous page
limitNo
include_serving_issuesNoAlso return serving_issues (why something is not delivering)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: archived campaigns are filtered out of results, and budget is surfaced both as micros and as a readable amount. It says nothing about pagination limits or ordering, which matters for a list endpoint.

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?

Two tightly written sentences, front-loaded with the returned fields and followed by the exclusion/alternative note — nothing redundant. The 'by OpenAI' artifact and the abrupt 'with status, objective, budget...' list make it slightly less clean than it could be.

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?

Since there is no output schema, the description correctly carries the return-value burden by listing the fields returned, and it discloses the archived-campaign filter. For a zero-required-parameter list tool with read-only annotations this is nearly sufficient; only pagination and the serving-issues flag are left unaddressed.

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

Parameters2/5

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

None of the three parameters are explained in the description: neither the 'after' cursor, the 'limit' cap (which has no schema description at all), nor when to set include_serving_issues. With schema coverage at only 67% the description needed to compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely (campaigns in the ad account) and enumerates the fields returned — status, objective, budget in micros and readable amount, targeting — so the agent knows what comes back before opening the schema. It also distinguishes itself from get_campaign. The odd phrase 'not listed by OpenAI' muddies an otherwise crisp statement, but the intent (archived campaigns excluded) is still recoverable.

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 gives an explicit exclusion rule (archived campaigns are not returned) and routes the agent to the correct alternative ('read one with get_campaign'), which is exactly the when-to-use guidance that matters for a list tool. It does not address why an agent would choose this over measurement_list_campaigns, leaving one sibling relationship unresolved.

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