shop-mcp

A Model Context Protocol server that lets an LLM agent answer questions about a Shopify store's catalogue and stock — over stdio, from a single file, using only the Python standard library.

No MCP SDK. No requests. No GraphQL client. python3 shop_mcp.py is the whole install.

$ python3 shop_mcp.py --self-test
all green: 189 assertions

That command needs no credentials and no network. It is the point of the repo: the protocol layer and the tool layer are both exercised for real, because the Shopify transport is replaced at a seam rather than mocked at the boundary.

Why write the protocol by hand

Because the failure modes of a stdio MCP server are all invisible locally and all fatal in a host. Each one below is a real defect this file is built to not have, and each has an assertion naming it:

• A diagnostic on stdout. One stray print() corrupts the client's next parse. Nothing looks wrong when you run the server yourself. Every diagnostic here goes to stderr, and a test asserts stdout stays byte-empty across a full session.
• Answering a notification. notifications/initialized has no id, so a reply to it is a message with no pending request. Strict clients treat that as a protocol violation and drop the connection.
• id: 0 read as a notification. if msg.get("id") is falsy for zero, so a client that numbers requests from zero has its first call silently dropped. Presence, not truthiness.
• Tool failures sent as JSON-RPC errors. A JSON-RPC error is for a malformed request. A tool that ran and failed must return a normal result with isError: true and the reason as text — otherwise the model never sees the message and cannot correct its own arguments.
• Echoing an unknown protocolVersion. If a client asks for a revision the server does not know, agreeing to it leaves both sides believing a spec is in use that neither implements. This falls back to 2025-03-26, the spec's own default, and says so.
• Pretty-printing the reply. Indented JSON contains newlines, and newline is the frame delimiter. One message becomes several broken ones.

Tools

Four tools, chosen because each answers a question a shop owner actually asks. A wider surface would be easy and would make the model worse at picking.

The correctness that is not protocol

Three of the assertions cover mistakes that produce confidently wrong answers, which are worse than errors:

• An unquoted SKU. sku:SH 1 is a different query from sku:"SH 1". The first silently matches the wrong variants and reports their stock as if it were yours. SKUs are quoted and internal quotes escaped.
• A null quantity read as zero. Shopify returns null for a variant that does not track inventory. Coerced to 0, it appears in every restock report forever. Untracked and out-of-stock are different facts and stay different.
• scan_exhausted. low_stock_report scans a bounded number of variants. If the scan hit its limit, "nothing is low" is indistinguishable from "I did not look far enough" — so the result says which it was, and the model can say so too.

Plus the transport rules any Shopify client needs and most skip: a THROTTLED GraphQL response is a 200 and must be retried, not read as success; a 401 must not be retried, because waiting will not fix a bad token; backoff must actually grow.

Verified, and not verified

Verified, by the self-test, on every run: 189 assertions covering the handshake, framing, notification handling, id presence, error mapping, schema strictness, retry and backoff policy, SKU quoting, null-quantity handling, threshold boundaries, and scan exhaustion. Wire shapes were taken from the official mcp Python SDK's types.py (LATEST_PROTOCOL_VERSION, CallToolResult, ServerCapabilities), not from memory.

Not verified: this has never been run against a live Shopify store. There is no credential in this repo and no recorded API session. The Shopify Admin GraphQL queries are written to the documented schema, and every code path around them is tested against a transport double — but the round trip against a real shop is unproven, and the test doubles are my model of Shopify's behaviour, not Shopify.

That distinction is the honest one, and it is the same line drawn in gpt-ads-feed. A README that blurs it is asking to be trusted on the wrong thing.

Assertions that can fail

mutation_test.sh injects known defects into copies of the source and asserts --self-test goes red for each, naming which assertion caught it. It also flags a NO-OP EDIT when a search pattern has gone stale — because a mutation that does not apply tests nothing while looking green, which is the failure mode that makes a suite worse than useless: trusted and empty.

It found real weaknesses in the suite on its first run, and all three were the same shape: the defect was detected, but by an exception rather than by a named assertion, so the message explained nothing and every assertion after it never ran.

Two were an unhandled KeyError: 'result', from indexing a reply that the defect had turned into a JSON-RPC error. Fixed by routing result access through a shape guard, so the same defect now reports a tool crash returns a result, so the loop survives: reply is a JSON-RPC error {'code': -32603, ...} and the three following assertions each still report their own verdict.

The third was a bare setup call — S.Tools(c).search_products(...), present only to make the assertion below it meaningful. When the throttle branch was disabled it raised, aborting the test before that assertion ran. Fixed with completes(), the exact inverse of raises(): the defect now reports a 200-with-THROTTLED is survivable, not a hard failure: raised ShopifyError: Throttled [THROTTLED], naming the rule and keeping the cause.

Three more defects surfaced only when the server was packaged as an .mcpb bundle and launched the way a host launches it, which no test had ever done:

1. The code read SHOPIFY_SHOP; this README and the bundle manifest both told users to export SHOPIFY_SHOP_DOMAIN. Anyone following the docs got a permanently unconfigured server. Every one of the 180 assertions passed, because none of them compared the code against the docs.
2. tools/list returned [] until credentials existed, so a host saw an empty server and reported it broken — and the readable no store is configured message on tools/call was unreachable, since nothing was listed to call. The docstring above that code stated the opposite requirement, and the test below it asserted the defect: eq(tools, [], ...). The list never depended on credentials; descriptors() touched no instance state at all, and is now a staticmethod.
3. --self-test was advertised in the module docstring but crashed inside the bundle, which shipped only the server file. The bundle now ships the suite.

The first fix then broke the harness in a way worth recording. The new assertion failed when README.md was absent, and the harness copied only two files, so it fired inside every mutant. The run still printed 17 caught, but six of those were credited to README.md is present instead of their own labels: six real assertions could have been dead with the suite still green. A missing README is a packaging fact, not a code defect. The load-bearing comparison now runs against the module docstring, which travels with the source, and the harness copies the README so the cross-check is real.

All 23 mutations are caught by an assertion that names what broke, and each is credited to its own label.

Use it

export SHOPIFY_SHOP_DOMAIN=your-shop.myshopify.com
export SHOPIFY_ADMIN_TOKEN=shpat_...          # read_products, read_inventory
python3 shop_mcp.py

Claude Desktop / any MCP host:

{
  "mcpServers": {
    "shop": {
      "command": "python3",
      "args": ["/absolute/path/to/shop_mcp.py"],
      "env": {
        "SHOPIFY_SHOP_DOMAIN": "your-shop.myshopify.com",
        "SHOPIFY_ADMIN_TOKEN": "shpat_..."
      }
    }
  }
}

With no credentials set it still completes a handshake and serves tools/list, then returns isError with the missing variable named. A host that cannot read tools/list reports "broken server" and sends you looking in the wrong place.

MIT.