Skip to main content
Glama
alex-brecher

shopify-multi-store

by alex-brecher
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Change a Shopify Store

shopify_graphql_mutation
Destructive

Run a GraphQL Admin API mutation on a chosen store; confirm with the mutation name for destructive changes, and see per-field status (applied/rejected/unknown).

Instructions

Run one GraphQL Admin API mutation against one named store. Set confirm to true only after the user authorizes the exact store and change. Destructive mutations (see shopify_describe_action; some are destructive only with certain arguments, such as a product status of ARCHIVED or notifyCustomer true) need confirm set to the mutation name instead, and denylisted mutations are refused, exactly as in shopify_run_action. The result reports each top-level mutation field as applied, rejected, or unknown, and the store as applied, rejected, partial, or unknown; after partial or unknown, retry only the rejected fields in a new document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
storeYesConfigured store alias, such as main-store or wholesale-store
confirmYesTrue after the user authorizes the exact change and store. Destructive mutations need the mutation name instead (several: comma-separated, in document order).
mutationYesA GraphQL mutation document.
variablesNoGraphQL variables as a JSON object

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.0.1
    • addedInput schema / properties / confirm / anyOf
      Added value: +[
+  {
+    "const": true,
+    "type": "boolean"
+  },
+  {
+    "maxLength": 2000,
+    "minLength": 1,
+    "type": "string"
+  }
+]
    • removedInput schema / properties / confirm / const
      Removed value: -true
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true after the user authorizes the exact change and store."New value: +"True after the user authorizes the exact change and store. Destructive mutations need the mutation name instead (several: comma-separated, in document order)."
    • removedInput schema / properties / confirm / type
      Removed value: -"boolean"
  2. First observedv1.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining the confirm-gating workflow, the special confirm-as-mutation-name requirement for destructive mutations (including arg-dependent cases like ARCHIVED status or notifyCustomer), denylist refusal, and per-field result statuses. This is exactly the behavioral detail an agent needs for a destructive tool.

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?

A single dense paragraph that is front-loaded with the core action, then the confirm workflow, then result semantics. It is long but nearly every sentence carries operational information; 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?

For a destructive, no-output-schema tool with nested variables, the description covers authorization prerequisites, the destructive-confirm protocol, denylist behavior, return-status vocabulary, and retry guidance after partial/unknown outcomes. Little an agent needs to invoke correctly is missing.

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: it clarifies that confirm may be the mutation name for destructive mutations and ties result fields to top-level mutation fields. It doesn't expand much on the variables object, which the schema already documents.

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?

States a specific verb and resource ('Run one GraphQL Admin API mutation against one named store') and implicitly distinguishes itself from the query siblings. An agent can immediately tell this executes writes rather than reads.

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?

Gives clear when-to-use guidance: set confirm to true only after the user authorizes the exact store and change, and defers destructive-mutation specifics to shopify_describe_action. It also notes denylisted mutations are refused, matching shopify_run_action. It doesn't explicitly contrast mutation vs. shopify_graphql_query, but routing is otherwise clear.

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