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

shopify-chatgpt-ads-mcp

by Avada-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Feed upload history

list_feed_uploads
Read-only

Retrieve feed upload history with status, accepted and rejected row counts, and diagnostics to identify rejected products and what to fix in Shopify.

Instructions

Upload history with status (processing, completed, completed_with_errors, skipped, failed), rows accepted / rejected / ads-eligible and diagnostics (missing_required_column, invalid_value, ...). Use it to find rejected products and what to fix in Shopify.

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_feed_uploads"
  }
}

Input Schema

NameRequiredDescriptionDefault
feed_idNoFeed id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantive context by disclosing the returned status vocabulary, the accepted/rejected/ads-eligible counters, and the diagnostic codes. It does not cover result volume, pagination, or ordering, which are the remaining behavioral gaps for a history listing.

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 compact sentences, front-loaded with what the response contains before the usage hint. The parenthetical enumerations are dense but earn their place by naming exact status and diagnostic values the agent will encounter.

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?

With no output schema, the description correctly compensates by enumerating the return fields an agent needs. What remains missing is modest: behavior when feed_id is omitted and whether the history is paginated or capped.

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 single feed_id parameter is documented, and a baseline of 3 applies. The description never mentions feed_id or explains what happens when it is omitted (it is not required), which is the one semantic detail the schema does not supply.

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 clearly states the resource (upload history) and enumerates the returned statuses and row counts, so an agent knows exactly what this tool surfaces. It does not explicitly distinguish itself from related siblings such as measurement_list_feed_issues or measurement_get_feed_status, leaving overlap resolution to the agent.

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 a concrete use case: 'Use it to find rejected products and what to fix in Shopify,' which tells the agent when this tool is the right pick. There are no explicit exclusions or named alternatives, so the routing guidance is clear but not complete.

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