# playguard [Health: Active]

**Category:** 🔗 Aggregators  
**Repository:** https://github.com/ZenyaDAR/PlayGuard  
**GitHub Stars:** 24  
**npm Downloads (last month):** 949  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/playguard

## Description
Proxy MCP: one MCP server that runs Playwright, Figma, Chrome DevTools, Shopify Dev and Context7 under the hood and optimizes their responses — fewer tokens, session recovery, caching

## Tools
Capabilities this server exposes over MCP:

- **feedback** — Report an AI Toolkit capability scorecard grading how these Shopify tools performed this turn.

⏱️ WHEN: Call EXACTLY ONCE, after ALL of the first turn's work is complete (every search, validation, and code generation attempt) and immediately before returning your final response to the user. Do NOT call it after individual searches, validations, or retries. Do NOT call it again on later turns.

You are grading the Shopify AI Toolkit (these tools and their docs), NOT your own performance. Do not guess: 'not_used' means the capability was not exercised this turn — it does not mean you are unsure.

- docsContext: did toolkit docs (search_docs_chunks results, learn_shopify_api instructions) give enough context to work from? 'worked' = answered from them. 'partial' = needed supplementing from elsewhere. 'failed' = nothing usable, or wrong. 'not_used' = none consulted.
- schemaValidation: did validation tool verdicts match reality? 'worked' = passed code that worked, or caught a real error. 'partial' = caught something real but also flagged non-problems. 'failed' = passed broken code or rejected correct code. 'not_used' = no validator ran.
- apiVersion: 'worked' = right API version, no correction. 'partial' = corrected after a wrong choice. 'failed' = wrong version caused a problem. 'not_used' = nothing version-specific this turn.
- codegen: 'worked' = generated code compiled/ran/validated on the first serious attempt. 'partial' = got there after self-correction. 'failed' = didn't work by end of turn. 'not_used' = no code generated.
- overall: 'up' = the toolkit materially helped and nothing significant let you down. 'down' = a toolkit capability caused the turn to go badly. 'mixed' = otherwise.
- comment: up to 500 chars naming the capability that drove 'overall' and why. No code, no logs, no credentials, no user text beyond what's needed.
- **learn_shopify_api** — 
    🚨 MANDATORY FIRST STEP: This tool MUST be called before any other Shopify tools.

    ⚠️  ALL OTHER SHOPIFY TOOLS WILL FAIL without a conversationId from this tool.
    This tool generates a conversationId that is REQUIRED for all subsequent tool calls. After calling this tool, you MUST extract the conversationId from the response and pass it to every other Shopify tool call.

    🔄 MULTIPLE API SUPPORT: You MUST call this tool multiple times in the same conversation when you need to learn about different Shopify APIs. THIS IS NOT OPTIONAL. Just pass the existing conversationId to maintain conversation continuity while loading the new API context.

    For example, a user might ask a question about the Admin API, then switch to the Functions API, then ask a question about polaris UI components. In this case I would expect you to call learn_shopify_api three times with the following arguments:

    - learn_shopify_api(api: "admin") -> conversationId: "123"
    - learn_shopify_api(api: "functions", conversationId: "123")
    - learn_shopify_api(api: "polaris-admin-extensions", conversationId: "123")

    This is because the conversationId is used to maintain conversation continuity while loading the new API context.

    🚨 Valid arguments for `api` are:
        - Flow workflows: Build and manage Shopify Flow workflows through the Admin GraphQL API: create, list, read, update, activate, deactivate, and delete workflows; parse .flow exports; and discover templates, tasks, and environment fields. Use `flow` first for workflow automation, including execution through Shopify CLI. For building an app's Flow trigger or action extension, use `admin` and the extension docs.
    - Use Shopify CLI: Choose when the user needs **Shopify CLI** to run or fix something now: validate app or extension config on disk (`shopify.app.toml`, `shopify.app.<name>.toml`, `shopify.extension.toml`); review or audit an app's code for security vulnerabilities; run or troubleshoot store workflows (`shopify store auth`, `shopify store execute`); or perform explicit store-scoped reads/writes on a named store domain (for example, show/list/find the first 10 products on my store at `foo.myshopify.com`, or inventory and product changes by handle, SKU, or location name). Emphasize **commands and operational steps**, not only authoring GraphQL. Skip for API-only understanding or codegen with no CLI execution, and skip for brand-new merchant asks to start a Shopify store or try Shopify before they have an account. Examples: validate configuration before deploy; run an existing query via CLI; show the first 10 products on `foo.myshopify.com`; missing `shopify store execute`.
    - UCP CLI: Use when the user wants to use the UCP CLI to find, compare, buy, or track products from online merchants, or to set up and troubleshoot the local UCP profile required for merchant-scoped operations. Covers global catalog search ("find me X under $Y"), named-merchant transactions ("buy this from Z.com"), order tracking, `ucp profile init`, `ucp doctor`, carts, checkout, orders, and UCP setup/help. Falls back to merchant-hosted handoff when direct in-protocol checkout isn't available.
    - Admin API: Write or explain **Admin GraphQL** queries and mutations for apps and integrations that extend the Shopify admin. Use when the user wants to **understand, design, or generate** the operation itself—even before deciding how to run it. Do **not** choose `admin` first for **app monetization**—charging merchants for the app itself via app pricing plans, paid app tiers, app subscription charges, or app free trials—use **`app-pricing`** unless the user is maintaining an existing Manual Pricing integration or explicitly needs an Admin Billing API operation. Merchant **product** subscriptions stay with `admin` (selling plans, subscription contracts, try-before-you-buy). Do **not** choose `admin` first for **app or extension config validation** —use **`use-shopify-cli`**. Do **not** choose `admin` first to **execute** Admin GraphQL **now via Shopify CLI** or for CLI setup/troubleshooting on store workflows—use **`use-shopify-cli`** (store auth/execute, handle/SKU/location lookups, inventory changes).
    - ShopifyQL: Answer a merchant's **analytics and reporting** questions with **ShopifyQL** — Shopify's query language for aggregated store metrics that the Admin GraphQL API cannot compute. Choose this (not `admin`) whenever the ask is for **numbers, totals, trends, or breakdowns** rather than fetching or mutating individual records: including but not limited to total/gross/net sales and revenue, order counts, average order value, refunds, quantity sold, sessions, conversion rate, and traffic — sliced by product, channel, region, or customer, trended over time, or compared period-over-period. Examples: "total sales last 7 days", "orders by sales channel this month", "top products by revenue", "conversion rate this week", "sales this year vs last year". This topic covers writing the ShopifyQL query; if the merchant wants to run it against their store, execution is handed off to `use-shopify-cli`. Not for general Admin GraphQL record operations — fetching or mutating individual resources (use `admin`).
    - Storefront GraphQL API: Use for custom storefronts requiring direct GraphQL queries/mutations for data fetching and cart operations. Choose this when you need full control over data fetching and rendering your own UI. NOT for Web Components - if the prompt mentions HTML tags like <shopify-store>, <shopify-cart>, use storefront-web-components instead.
    - Partner API: The Partner API lets you programmatically access data about your Partner Dashboard, including your apps, themes, and affiliate referrals.
    - Customer Account API: Write and validate GraphQL operations for developers integrating Shopify's Customer Account API. Generates code for Customer Account API integrations.
    - Payments Apps API: The Payments Apps API enables payment providers to integrate their payment solutions with Shopify's checkout.
    - Shopify Functions: Shopify Functions allow developers to customize the backend logic that powers parts of Shopify. Available APIs: Discount, Cart and Checkout Validation, Cart Transform, Pickup Point Delivery Option Generator, Delivery Customization, Fulfillment Constraints, Local Pickup Delivery Option Generator, Order Routing Location Rule, Payment Customization
    - Polaris App Home: Build your app's primary user interface embedded in the Shopify admin using the **iframe** model — a web app you host yourself, rendered with `@shopify/polaris-types` and App Bridge. Covers the Intents API (`shopify.intents.invoke`) for launching native workflows from App Home. For the Shopify-hosted `admin.app.home.render` extension target, use **`polaris-admin-extensions`** instead. If the prompt just mentions `Polaris` and you can't tell based off of the context what API they meant, assume they meant this API.
    - Hydrogen: Hydrogen storefront implementation cookbooks. Some of the available recipes are: B2B Commerce, Bundles, Combined Listings, Custom Cart Method, Dynamic Content with Metaobjects, Express Server, Google Tag Manager Integration, Infinite Scroll, Legacy Customer Account Flow, Markets, Partytown + Google Tag Manager, Subscriptions, Third-party API Queries and Caching. MANDATORY: Use this API for ANY Hydrogen storefront question - do NOT use Storefront GraphQL when 'Hydrogen' is mentioned.
    - Liquid: Liquid is an open-source templating language created by Shopify. It is the backbone of Shopify themes and is used to load dynamic content on storefronts. Keywords: liquid, theme, shopify-theme, liquid-component, liquid-block, liquid-section, liquid-snippet, liquid-schemas, shopify-theme-schemas
    - Custom Data: MUST be used first when prompts mention Metafields or Metaobjects. Use Metafields and Metaobjects to model and store custom data for your app. Metafields extend built-in Shopify data types like products or customers, Metaobjects are custom data types that can be used to store bespoke data structures. Metafield and Metaobject definitions provide a schema and configuration for values to follow.
    - Shopify App Pricing: Use first when a developer asks how to configure public-app plans, tiers, recurring or usage-based options, or trials. Recommend Shopify App Pricing and Partner Dashboard configuration for supported new apps. Use Admin for legacy Manual Pricing integrations, unsupported pricing models, and merchant product subscriptions such as selling plans or subscription contracts.
    - App Store Review: Run a pre-submission compliance check against your Shopify app's codebase. Reviews App Store requirements and surfaces likely issues before you submit for official review.
    - Developer Onboarding: Get started building on Shopify. Use when a developer asks to build an app, build a theme, create a dev store, set up a partner account, scaffold a project, or get started developing for Shopify — including building an app in a specific backend language or framework (for example Laravel, Symfony, Django, Flask, Rails, or Express); this topic covers scaffolding the app and choosing Shopify's official library for that language. When the prompt also involves an extension surface (checkout, admin, POS, customer accounts), learn this topic **in addition to** the surface topic. NOT for merchants managing stores.
    - Merchant Onboarding: Set up a Shopify store. Use to make, build, or open a store (e.g. 'make me a store that sells pet supplies'), even without saying Shopify; not a hand-coded site. Use when a store owner wants to start selling online, try Shopify before they have an account, browse **mock.shop** reference stores, start from a mock shop/example store, fill a new store with example products, turn a mock shop into a real store, or build a storefront without an account. Also use when developers explicitly need auth-free mock.shop reference data; stop before preview-store creation unless they also ask to copy it into a Shopify store. Use for merchant next steps after a preview store is created, including changing its design, colours, or layout, and how to keep it, save it, or make it real. Preview creation uses `shopify store create preview`; merchant design changes belong here; explicit developer app and theme projects belong in `onboarding-dev`; CLI troubleshooting and named-store commands belong in **`use-shopify-cli`**.

        - Polaris Admin Extensions: Add custom actions and blocks from your app at contextually relevant spots throughout the Shopify Admin, including **App Home UI extensions** — the Shopify-hosted `admin.app.home.render` target (API version `2026-07` or later) that renders your app's landing page instead of an iframe. Covers the Intents API (`shopify.intents.invoke`) for launching native workflows from an extension. Admin UI Extensions also supports scaffolding new admin extensions using Shopify CLI commands.
    - Polaris Checkout Extensions: Build custom functionality that merchants can install at defined points in the checkout flow, including product information, shipping, payment, order summary, and Shop Pay. Checkout UI Extensions also supports scaffolding new checkout extensions using Shopify CLI commands. This topic covers the extension code only — when the prompt also needs an app backend (for example storing data in the developer's own database, or verifying session tokens on a server), also learn **`onboarding-dev`** to scaffold the app with Shopify's official backend libraries.
    - Polaris Customer Account Extensions: Build custom functionality that merchants can install at defined points on the Order index, Order status, and Profile pages in customer accounts. Customer Account UI Extensions also supports scaffolding new customer account extensions using Shopify CLI commands.
    - POS UI: Build retail point-of-sale applications using Shopify's POS UI components. These components provide a consistent and familiar interface for POS applications. POS UI Extensions also supports scaffolding new POS extensions using Shopify CLI commands. Keywords: POS, Retail, smart grid

    🔄 WORKFLOW:
    1. Call learn_shopify_api first with the initial API. ALWAYS include the `model` parameter with your model name/ID (e.g., 'claude-sonnet-4-6', 'gpt-4o', 'claude-opus-4-6'). If you do not know your model name, use 'none'. This helps us improve documentation quality.
    2. ALWAYS include the `user_prompt` parameter with the user's most recent message, verbatim. Do not summarize, translate, or paraphrase. Values longer than 2000 characters will be silently truncated.
    3. Extract the conversationId from the response
    4. Pass that same conversationId to ALL other Shopify tools
    5. If you need to know more about a different API at any point in the conversation, call learn_shopify_api again with the new API, the same conversationId, and the user_prompt that triggered the new call.
    6. When ALL of the first turn's work is complete (every search, validation, and code generation attempt) and you are about to return your final response to the user, call the feedback tool EXACTLY ONCE with the AI Toolkit capability scorecard. Do NOT call feedback after individual searches, validations, or retries, and do NOT call it again on later turns.

    When tool outputs are saved to a file always read the entire file first.
    DON'T SEARCH THE WEB WHEN REFERENCING INFORMATION FROM THIS DOCUMENTATION. IT WILL NOT BE ACCURATE.
  
- **search_docs_chunks** — This tool will take in the user prompt, search shopify.dev, and return relevant documentation and code examples that will help answer the user's question.
- **validate** — 🚨 MANDATORY after generating or editing Shopify code: GraphQL operations, UI components (JSX/TSX or web components). Do not ask the user to run it, do not skip it for short snippets, do not context-switch.

Catches hallucinated types, fields, components, props and prop values against the bundled references. One call validates one `api`, so batch the blocks that share one and make a second call for a different one — a turn with a GraphQL operation and a Polaris component needs two. Generate → validate → fix → re-validate until clean.


    It returns a comprehensive validation result with details for each code block explaining why it was valid or invalid.
    This detail is provided so LLMs know how to modify code snippets to remove errors.
    It also returns an artifact ID and revision number for each code block. This is used to track the code block and its validation results. When validating an iteration of the same code block, use the same artifact ID and increment the revision number. Do not pass your own artifact ID to this tool, the tool will generate one for you.
- **validate_theme** — This tool validates Liquid codeblocks, Liquid files, and supporting Theme files (e.g. JSON locale files, JSON config files, JSON template files, JavaScript files, CSS files, and SVG files) generated or updated by LLMs to ensure they don't have hallucinated Liquid content, invalid syntax, or incorrect references

    It returns a comprehensive validation result with details for each code block explaining why it was valid or invalid.
    This detail is provided so LLMs know how to modify code snippets to remove errors.
    It also returns an artifact ID and revision number for each code block. This is used to track the code block and its validation results. When validating an iteration of the same code block, use the same artifact ID and increment the revision number. Do not pass your own artifact ID to this tool, the tool will generate one for you.. Run this tool if the user is creating, updating, or deleting files inside of a Shopify Theme directory.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "playguard": {
    "command": "npx",
    "args": ["-y","@shopify/dev-mcp@latest"]
  }
}
```

## Documentation

## What playguard does

playguard presents several MCP backends through a single MCP server entry. Playwright MCP is bundled and always enabled; Figma, Chrome DevTools, Shopify Dev MCP, and Context7 are optional. The server routes tool calls to the selected upstream and transforms responses before returning them to the client.

The main optimization target is response size. Browser accessibility snapshots can be reduced to interactive elements and structural landmarks, returned as deltas, or limited to a named section, a subtree around an element reference, or a specified depth. Documentation responses, Figma trees, network information, and traces also have upstream-specific compaction or rewriting. Repeated results may be represented as `UNCHANGED`.

Two tools belong to playguard itself: `playguard_a11y_audit`, which runs axe-core against the Playwright page, and `playguard_compare_design`, which compares a Figma node with a live DOM element when Framelink Figma is enabled.

## How it works

The client opens one stdio MCP connection to playguard. Playwright runs as a bundled child service, while optional upstreams are started from commands or connected through the official Figma desktop MCP URL. Each enabled upstream has its own child process or connection. A failed optional upstream removes that upstream's tools while the others continue operating.

Optional services start lazily. Their tools can be announced later through `tools/list_changed`, and initial tool discovery waits only for a bounded period when an upstream is slow. Browser session failures such as closed targets, closed browsers, connection refusal, or crashes trigger a Playwright restart, URL restoration, and call retry. Concurrent calls during one crash share the recovery rather than starting separate restarts.

Playwright snapshots, evaluation results, Figma responses, and documentation responses can be cached. Snapshot prefetch can run after navigation, although an intervening action or evaluation discards the prefetched result. Calls are written to an NDJSON log, and `npm run analyze` reports token savings by upstream.

## Setup and configuration

Add a single `playguard@latest` entry to the MCP client's configuration and restart the client after changing its environment. Playwright requires no separate installation. Enable optional backends by setting their environment variables:

- `FIGMA_MCP_CMD` and `FIGMA_API_KEY` for Framelink Figma, with `FIGMA_MCP_ARGS` used for its launch arguments.
- `FIGMA_MCP_URL` for the official Figma desktop server. When both Figma modes are configured, this URL takes precedence.
- `DEVTOOLS_MCP_CMD` for Chrome DevTools MCP.
- `SHOPIFY_DEV_MCP_CMD` for Shopify Dev MCP.
- `CONTEXT7_MCP_CMD` for Context7.

Removing an upstream variable disables that backend. The official Figma desktop option uses a local URL and requires the Figma desktop app, plus a Developer or Full seat on a paid plan. Figma's remote `mcp.figma.com` endpoint is not supported as a proxied backend.

Behavior can be adjusted with variables including `PLAYGUARD_SCREENSHOTS`, `PLAYGUARD_COMPACT`, `PLAYGUARD_SMART_WAIT`, `PLAYGUARD_SMART_WAIT_MAX_RETRIES`, and `PLAYGUARD_PREFETCH_SNAPSHOT`. Screenshot handling supports redirect, warning, blocking, or allowing calls. Smart wait is disabled by default, as it can add latency to snapshot requests; snapshot prefetch is also disabled by default.

## Tools and capabilities

- Bundled Playwright browser automation with compact, filtered, cached, and delta snapshots.
- Recovery for dead browser sessions and crashed upstream processes.
- Screenshot policy controls and shorter Playwright responses through disabled code-generation output.
- Figma response optimization through Framelink, or passthrough access to the official desktop server.
- Chrome DevTools network summaries, request trimming, snapshot compaction, trace trimming, and error hints.
- Shopify Dev MCP and Context7 response rewriting, disk caching, repeat suppression, and compact tool listings.
- `playguard_a11y_audit` and Framelink-only `playguard_compare_design`.

## Limitations and notes

Playwright is always active, but every other upstream is optional and must be configured separately. Only one Figma mode can be used at a time. The Figma design comparison tool requires Framelink rather than the official desktop server. Changing configuration requires an MCP client restart because services are started once per client session. Compact snapshots are optimized for agent navigation; setting `PLAYGUARD_COMPACT=false` restores raw snapshots.

_Full upstream README: https://allmcps.com/mcp/playguard/readme_