shopify-multi-mcp

Overview Schema Source Related Servers Discussions Admin

Run an Admin GraphQL mutation

graphql_mutation

Destructive

Run Shopify Admin GraphQL mutations against a specified store to change data. Validate the document first, confirm the target store and change, then check userErrors in the response.

Instructions

Run a Shopify Admin GraphQL mutation that changes data in one store. Confirm the target store and the change with the user before calling. Validate the document with validate (api "admin") first, look ids up in the same store (ids from another store will not resolve), and check the userErrors field of the result. Refused for read-only stores.

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": {
      "store": "<store>",
      "query": "<query>"
    },
    "name": "graphql_mutation"
  }
}

Input Schema

Name	Required	Description
`query`	Yes	GraphQL mutation document. Select userErrors { field message }.
`store`	Yes	No stores are connected yet. Call connect_store first.
`variables`	No	GraphQL variables.
`api_version`	No	Admin API version such as "2026-10". Omit for the latest stable version.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The annotations already flag this as destructive and not read-only, and the description adds important behavioral context beyond that: it requires user confirmation, operates on exactly one store, rejects cross-store IDs, refuses read-only stores, and requires post-call userErrors inspection. These details materially reduce the risk of an unsafe or failed 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 description is four compact sentences and is front-loaded with the core action and store scope. Each subsequent sentence adds a necessary operational constraint or safety step, with no wasted prose.

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?

For a destructive mutation with no output schema, the description covers the essential considerations: confirmation, validation, store scoping, ID resolution, and userErrors checking. It could mention throttling or partial-failure behavior, but nothing critical for correct invocation is missing.

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 parameters are already well documented. The description adds some query-related guidance, specifically validating the document and selecting userErrors, but it does not add meaning for variables or api_version beyond what the schema provides. This is an appropriate baseline given the schema coverage.

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 states a specific verb and resource: run a Shopify Admin GraphQL mutation that changes data in one store. This distinguishes it clearly from read tools like graphql_query, though it does not explicitly name that sibling. The single-store scope also differentiates it from graphql_query_all_stores.

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 strong when-to-use guidance: confirm the target store and change with the user, validate the document first, look up IDs in the same store, and check userErrors. It also states a clear exclusion, namely that this tool is refused for read-only stores. It stops short of explicitly directing read-only GraphQL calls to graphql_query.

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

Deploy Server