Which integrations are available for this server?

Provides comprehensive Shopify checkout branding management through AI-powered tools, allowing customization of colors, typography, sections, form controls, and design systems on Shopify Plus stores.

How do I use Shopify Checkout Branding MCP Tool?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Shopify Checkout Branding MCP Tool Change the primary color to #5A31F4" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Shopify Checkout Branding MCP Tool

by shandut

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Shopify Checkout Branding MCP Tool

A Model Context Protocol (MCP) server for comprehensive Shopify checkout branding management through AI-powered tools. This production-ready server enables AI assistants like Claude and Cursor to programmatically customize every aspect of your Shopify Plus checkout - from colors and typography to sections, form controls, and complete design systems.

🚀 Production-Ready: Full API compatibility, intelligent value mapping, enhanced tool descriptions, and safety-first defaults for accurate AI-driven checkout customization.

✅ Cursor MCP Support Fixed!

The MCP server now works correctly with Cursor. The JSON communication issue has been resolved. See CURSOR-MCP-SETUP.md for details.

Related MCP server: Figma Copilot

🎯 Quick Start

For Claude Desktop Users

Install and configure:

# Clone and setup
git clone https://github.com/shandut/Shopify-Checkout-Branding-MCP-Tool.git
cd shopify-checkout-mcp-tool
npm install
npm run build

# Create .env file with your credentials
cp env.template .env
# Edit .env with your Shopify store details

Configure Claude Desktop (see Configuration section below)
Use natural language in Claude:

"Show me all checkout profiles"
"Center the logo and make it 150px wide"
"Change the primary color to #5A31F4"

For Cursor/HTTP API Users

Start the HTTP server:

npm run start:http

Test the API:

node test-http.js

🚀 Features

Core Tools

List Checkout Profiles: Retrieve all checkout profiles with TEST/PUBLISHED status
Read Current Branding: Get complete branding configuration and design system
Update Branding: Comprehensive customization with intelligent defaults
- 🔒 Safety Feature: Automatically targets TEST/draft profile by default
- Use useProductionProfile: true to explicitly update live checkout
Upload Logos: Stream images from URLs directly to Shopify CDN
Upload Custom Fonts: Upload WOFF/WOFF2/TTF/OTF fonts for unique typography

Styling Capabilities

Colors: Background, text, primary (buttons), surface colors with hex validation
Typography: Font families (Shopify or custom), weights (100-900), base size (12-16), ratios (1.0-1.5)
- Custom font support for primary (body text) and secondary (headings) surfaces
- Configurable font loading strategies (BLOCK, SWAP, FALLBACK, OPTIONAL)
Corner Radius: NONE, SMALL, BASE, LARGE for all elements
Shadows: 5 levels (SMALL_100, SMALL_200, BASE, LARGE_100, LARGE_200)
Padding: 14 variants (NONE through LARGE_500)
Sections: Independent main area and order summary styling with dividers
Form Controls: Borders, labels (INSIDE/OUTSIDE), corner radius
Color Schemes: 4 schemes for different section contexts
Header: Logo visibility, banner images, cart links, alignment, dividers
Background Images: Support for header banner, main area, order summary
Container Dividers: Configurable style (BASE/DASHED/DOTTED), width, visibility
Cart Link: Custom content type (ICON/IMAGE/TEXT) with image support

API Intelligence

Multi-version Support: Compatible with API versions 2024-10 through 2026-01
Value Mapping: Automatic conversion for API compatibility
Enhanced Descriptions: Detailed tool documentation for better AI understanding
Error Recovery: Intelligent handling of validation errors

📋 Prerequisites

Node.js 18+ with TypeScript support
Shopify store with Admin API access
Shopify Admin API token with appropriate scopes:
- read_checkout_branding_settings
- write_checkout_branding_settings
- write_files (for logo uploads)

🛠️ Installation

⚠️ Security Note

Never commit your actual API credentials to version control!

Copy env.template to .env for your credentials
.env is already in .gitignore to prevent accidental commits
All example configurations use placeholder values

Setup Steps

Clone the repository:

git clone https://github.com/shandut/Shopify-Checkout-Branding-MCP-Tool.git
cd shopify-checkout-mcp-tool

Install dependencies:

npm install

Build the project:

npm run build

Configure environment variables:

cp env.template .env

Edit .env with your Shopify credentials:

SHOPIFY_STORE_DOMAIN=your-store.myshopify.com
SHOPIFY_ADMIN_TOKEN=shpat_your_admin_api_token_here
SHOPIFY_API_VERSION=2026-01
PORT=8787  # Only if using HTTP wrapper

🔧 Configuration

For Claude Desktop

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "shopify-checkout": {
      "command": "node",
      "args": ["/path/to/shopify-checkout-mcp-tool/dist/index.js"],
      "env": {
        "SHOPIFY_STORE_DOMAIN": "your-store.myshopify.com",
        "SHOPIFY_ADMIN_TOKEN": "shpat_your_admin_api_token_here",
        "SHOPIFY_API_VERSION": "2026-01"
      }
    }
  }
}

For Cursor or Other Tools (HTTP Mode)

Run with HTTP wrapper enabled:

npm run start:http

The server will be available at http://localhost:8787

📚 Available MCP Tools

1. `shopify_list_checkout_profiles`

Lists all checkout profiles in your store.

Input: None required Output: Array of profiles with id, name, and status

2. `shopify_get_checkout_branding`

Retrieves current branding settings for a specific profile.

Input:

profileId (string): Shopify GID of the checkout profile

Output: Current logo configuration and color scheme

3. `shopify_update_checkout_branding`

Updates branding settings for a checkout profile. 🔒 Defaults to TEST profile for safety.

Input:

profileId (string, optional): Shopify GID - if not provided, auto-selects TEST profile
useProductionProfile (boolean, optional): Set to true to update live checkout (default: false)
logoWidth (number, optional): Width in pixels (1-1000)
logoPosition (enum, optional): "LEFT", "CENTER", or "RIGHT"
colors (object, optional):
- background: Hex color (e.g., "#FFFFFF")
- surface: Hex color
- text: Hex color
- primary: Hex color for buttons
- primaryText: Hex color for button text
control (object, optional): Form control styling
- color: "TRANSPARENT"
- border: "NONE" or "FULL"
- cornerRadius: Corner style
- labelPosition: "INSIDE" or "OUTSIDE"
imageId (string, optional): ID of uploaded logo

4. `shopify_upload_logo_from_url`

Uploads an image from a URL to Shopify Files.

Input:

url (string, required): Public HTTPS URL of the image
filename (string, optional): Desired filename
mimeType (string, optional): Image MIME type

Output: Image ID and CDN URL for use in branding updates

5. `shopify_upload_custom_font_from_url`

Uploads a custom font file from a URL to Shopify Files for use in checkout typography.

Input:

url (string, required): Public HTTPS URL of the font file (WOFF, WOFF2, TTF, or OTF)
filename (string, optional): Desired filename for the font
mimeType (string, optional): Font MIME type (auto-detected if not provided)
fontWeight (number, optional): Font weight (100-900, default 400 for regular, 700 for bold)
isBold (boolean, optional): Mark as bold variant (sets weight to 700)

Output:

genericFileId: File ID to use in checkout branding configuration
url: CDN URL of the uploaded font
weight: Font weight value
filename: The filename of the uploaded font

💡 Usage Examples

Via MCP (in Claude Desktop)

After configuring Claude Desktop, you can use natural language:

"Can you reduce my checkout logo width by half and center it?"

Claude will:

Call shopify_get_checkout_branding to get current width
Calculate new width (50% of current)
Call shopify_update_checkout_branding with new settings
Verify changes with another shopify_get_checkout_branding call

Via HTTP API (for Cursor)

# List all checkout profiles
curl http://localhost:8787/profiles

# Get current branding
curl http://localhost:8787/profiles/gid://shopify/CheckoutProfile/123/branding

# Update branding (safer - auto-targets TEST profile)
curl -X POST http://localhost:8787/branding \
  -H "Content-Type: application/json" \
  -d '{
    "logoWidth": 150,
    "logoPosition": "CENTER",
    "colors": {
      "primary": "#5A31F4",
      "background": "#FFFFFF"
    }
  }'

# Update production checkout (explicit)
curl -X POST http://localhost:8787/branding \
  -H "Content-Type: application/json" \
  -d '{
    "useProductionProfile": true,
    "logoWidth": 150,
    "colors": {
      "primary": "#5A31F4"
    }
  }'

# Upload new logo
curl -X POST http://localhost:8787/files \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/new-logo.png",
    "filename": "checkout-logo.png"
  }'

# Upload custom fonts
curl -X POST http://localhost:8787/fonts \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/myfont-regular.woff2",
    "fontWeight": 400
  }'

# Apply custom font to checkout
curl -X POST http://localhost:8787/branding \
  -H "Content-Type: application/json" \
  -d '{
    "designSystem": {
      "typography": {
        "primary": {
          "customFontGroup": {
            "base": {
              "genericFileId": "gid://shopify/GenericFile/123456",
              "weight": 400
            },
            "bold": {
              "genericFileId": "gid://shopify/GenericFile/789012",
              "weight": 700
            },
            "loadingStrategy": "SWAP"
          }
        }
      }
    }
  }'

🏗️ Architecture

src/
├── index.ts           # Application entry point
├── mcpServer.ts       # MCP server implementation
├── httpServer.ts      # Optional Fastify HTTP wrapper
├── shopify.ts         # GraphQL client for Shopify API
├── branding.ts        # Business logic for branding operations
├── schemas.ts         # Zod schemas for validation
└── logging.ts         # Pino logger with security redaction

🔐 Security

Token Protection: API tokens are never logged or exposed in responses
Input Validation: All inputs validated using Zod schemas
Rate Limiting: Automatic retry with exponential backoff for Shopify API limits
HTTPS Only: Only accepts HTTPS URLs for image uploads
Scoped Permissions: Limited to checkout branding and file operations

🧪 Testing

Run tests:

npm test

Test against a development store:

npm run test:integration

📝 Development

Start development server with hot reload:

npm run dev

Build for production:

npm run build

Start production server:

npm start

🚦 Error Handling

The server handles various error scenarios:

400: Invalid input or validation errors
403: Missing required Shopify API scopes
429: Rate limited (automatic retry with backoff)
500: Unexpected server errors

🤝 Contributing

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

⚠️ Known Limitations & Important Notes

Typography Field Restrictions

The customizations.global.typography field has strict limitations:

✅ Allowed: kerning (BASE, LOOSE, EXTRA_LOOSE), letterCase (NONE, LOWER, TITLE, UPPER)
❌ NOT Allowed: font, size, weight (use designSystem.typography for these)

Other API Limitations

Global Corner Radius: Only accepts NONE value
Control Color: Only accepts TRANSPARENT value
Logo Format: SVG files cannot be used for checkout logos
Enum Values: Some enum values differ between API versions (e.g., UPPER vs UPPERCASE)

🆘 Support

For issues, questions, or suggestions:

Open an issue on GitHub
Check existing issues for solutions
Review Shopify Admin API documentation

🗺️ Roadmap

Support for multiple store configurations
Bulk profile updates
Preview generation before applying changes
Backup and restore functionality
WebSocket support for real-time updates
Integration with Shopify webhooks
Support for theme-based branding
A/B testing capabilities

Available Tools

5 tools

shopify_get_checkout_brandingA

Retrieve complete checkout branding configuration including design system and customizations.

  Returns two main sections:
  1. DESIGN SYSTEM: Foundation settings for colors, typography, corner radius
     - colors.global.brand: The PRIMARY BUTTON COLOR
     - colors.schemes: Detailed color schemes with primaryButton, secondaryButton, control colors
     - typography: Font families and sizes
  
  2. CUSTOMIZATIONS: Specific UI element settings
     - HEADER: Logo (visibility, maxWidth), banner image, cartLink (contentType, image), divided, alignment, padding
     - FOOTER: Content visibility, color scheme, padding
     - MAIN: Background image, section styling, divider settings
     - ORDER SUMMARY: Background image, section styling, divider settings
     - primaryButton, secondaryButton, control, textField, select elements
  
  The profileId is optional - defaults to TEST profile for safety.

ParametersJSON Schema

Name	Required	Description	Default
`profileId`	No

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It describes the read-only nature and the test default, but does not disclose potential errors, rate limits, or authentication requirements beyond implied safety.

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?

The description is well-structured with bullet points for the two main sections (design system and customizations), making it easy to read. It is slightly lengthy but justified by the complexity of the return object.

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?

Given no output schema, the description provides a comprehensive breakdown of the return structure, including specific fields under design system and customizations. This is complete enough for an agent to understand expected data.

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?

The only parameter profileId has no schema description coverage (0%), but the description adds meaning by stating it is optional and defaults to TEST profile for safety. This provides functional context beyond the schema type 'string'.

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?

The description clearly states the tool retrieves checkout branding configuration, specifying both the verb (retrieve) and resource (complete checkout branding configuration including design system and customizations). It distinguishes from sibling tools like update or upload.

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?

The description mentions that profileId is optional and defaults to TEST profile for safety, providing clear guidance on when to omit the parameter. However, it does not explicitly contrast with siblings like shopify_list_checkout_profiles or shopify_update_checkout_branding.

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

shopify_list_checkout_profilesA

List all checkout profiles in a Shopify Plus store. Returns both TEST/draft and PUBLISHED/live profiles with their IDs, names, and publication status.

  Use this to:
  - Identify available checkout profiles before making updates
  - Find the TEST profile ID for safe testing (isPublished: false)
  - Find the PRODUCTION profile ID for live updates (isPublished: true)
  
  Note: Most stores have 2 profiles - one TEST and one PUBLISHED. Always prefer updating TEST profile first.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description fully handles transparency. It explains that both TEST and PUBLISHED profiles are returned and notes typical store setup. However, it does not mention pagination or rate limits, though the simple nature of the tool (0 params) makes that less critical.

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 concise, uses a clear structure (main sentence, bullet points, note), and every sentence adds value without redundancy. It is front-loaded with the primary purpose.

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?

Given the tool's simplicity (no params, no output schema), the description covers the key information: what the tool does, what it returns, and how to interpret results. It could include field names, but the mention of 'IDs, names, and publication status' is sufficient for most agents.

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?

The tool has zero parameters, so schema coverage is trivially 100% and no parameter documentation is needed. Per guidelines, baseline for 0 params is 4.

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?

The description uses a specific verb ('List') and resource ('checkout profiles in a Shopify Plus store'), and details what is returned (IDs, names, publication status). It clearly distinguishes itself from sibling tools that focus on branding operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides three bullet-pointed use cases (identify before updates, find TEST profile, find PRODUCTION profile) and a note recommending to update TEST first, offering clear when-to-use and best-practice guidance.

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

shopify_update_checkout_brandingA

Update checkout branding using Shopify's CheckoutBrandingUpsert API.

  🔒 SAFETY: Defaults to TEST/draft profile unless useProductionProfile:true or explicit profileId provided.
  
  🎨 PRIMARY BUTTON COLOR:
  The primary button (Pay Now) color is controlled by:
  • globalBrand: Sets the brand color (EASIEST - just pass hex color)
  • OR designSystem.colors.global.brand: Same as above but in full structure
  • OR designSystem.colors.schemes.scheme1.primaryButton: For detailed control including hover states
  • NOT colors.primary - this field is deprecated, use globalBrand instead
  
  📚 COMPREHENSIVE CAPABILITIES:
  
  DESIGN SYSTEM (Foundation):
  • GLOBAL COLORS:
    - brand: Primary buttons and brand elements (#FF6B00 for orange)
    - accent: Links and focus states
    - success, warning, critical, info: Semantic colors
    - decorative: Highlight colors
  • COLOR SCHEMES (scheme1-4): Each can have:
    - base: Background, text, border, icon, accent colors
    - primaryButton: Background, text, hover state colors
    - secondaryButton: Secondary action button colors
    - control: Form field colors with selected state
  • TYPOGRAPHY:
    - primary/secondary fonts (e.g., "Assistant", "Roboto", "Montserrat")
    - Font weights, sizes, letter spacing
    - Size base (12-18px) and ratio (1.0-1.5)
  • CORNER RADIUS: Variables for small, base, large radii
  
  CUSTOMIZATIONS (Specific Elements):
  • HEADER:
    - Logo: position, width (50-500px), visibility (VISIBLE/HIDDEN)
    - Banner: background image via mediaImageId
    - CartLink: contentType (ICON/IMAGE/TEXT), custom image
    - Alignment, divided (true/false), padding, color scheme
    - Position mapping: LEFT→START, CENTER→INLINE, RIGHT→INLINE_SECONDARY
  • FOOTER: 
    - Content visibility, color scheme
    - padding: NONE|BASE|BASE_500|SMALL|SMALL_100-500|LARGE|LARGE_100-500 (section values)
  • MAIN AREA:
    - Section: 
      * background: BASE|SUBDUED|TRANSPARENT (accepts SOLID→BASE, NONE→TRANSPARENT)
      * shadow: SMALL_100|SMALL_200|BASE|LARGE_100|LARGE_200 (NO 'NONE' or 'BASE_200'!)
      * cornerRadius: NONE|SMALL|BASE|LARGE
      * padding: NONE|BASE|BASE_500|SMALL|SMALL_100-500|LARGE|LARGE_100-500 (NOT button values!)
      * border: NONE|FULL
      * borderWidth: BASE|LARGE|LARGE_100|LARGE_200 (NOT 'NONE' or 'MEDIUM'!)
    - Background image via mediaImageId
    - Divider: borderStyle (BASE/DASHED/DOTTED), borderWidth (BASE|LARGE|LARGE_100|LARGE_200), visibility
    - Color scheme: COLOR_SCHEME1|COLOR_SCHEME2|COLOR_SCHEME3|COLOR_SCHEME4
  • ORDER SUMMARY:
    - Section: Same exact values as main area
    - Background image support
    - Independent divider settings with visibility
    - Separate color scheme
  • CONTENT:
    - Divider: borderStyle, borderWidth, visibility (container divider)
  • GLOBAL DIVIDER:
    - borderStyle (BASE/DASHED/DOTTED), borderWidth (NONE/BASE/MEDIUM)
    - Note: NO visibility on global divider (customizations.divider)
  • BUTTONS:
    - primaryButton/secondaryButton:
      * background: NONE|SOLID
      * border: NONE|FULL
      * cornerRadius: NONE|SMALL|BASE|LARGE
      * blockPadding/inlinePadding: NONE|EXTRA_TIGHT|TIGHT|BASE|LOOSE|EXTRA_LOOSE
      * typography: font, size, weight (BASE|BOLD), kerning, letterCase (NONE|LOWER|TITLE|UPPER)
  • FORM CONTROLS:
    - border: NONE|FULL (exactly these two)
    - color: TRANSPARENT (ONLY this value accepted!)
    - cornerRadius: NONE|SMALL|BASE|LARGE
    - labelPosition: INSIDE|OUTSIDE
  • TEXT FIELDS & SELECTS: Border, typography styling
  • CHECKBOXES: Corner radius
  • HEADINGS: Typography for 3 levels
  • MERCHANDISE THUMBNAILS: Corner radius, border
  • EXPRESS CHECKOUT: Button corner radius
  • OTHER: Choice lists, buyer journey, cart link, dividers, content borders
  
  SIMPLIFIED OPTIONS (for convenience):
  • colors: {background, text, primary→brand, surface} - Legacy support
  • globalBrand: Direct way to set primary button color
  • primaryButtonColor: Override primary button background
  • typography: Simplified font settings
  • logoPosition, logoWidth, imageId: Direct logo control
  
  USAGE EXAMPLES:
  1. Set orange primary button: globalBrand: "#FF6B00"
  2. Full brand colors: designSystem.colors.global.brand: "#FF6B00"
  3. Detailed button control: designSystem.colors.schemes.scheme1.primaryButton.background: "#FF6B00"
  
  API NOTES & CRITICAL ENUM VALUES:
  - SHADOW: ONLY 5 valid values: SMALL_100, SMALL_200, BASE, LARGE_100, LARGE_200
    * NO 'NONE' (use SMALL_100), NO 'BASE_200' (use LARGE_100)
  - BACKGROUND: BASE, SUBDUED, TRANSPARENT (NOT 'SOLID' or 'NONE')
    * Tool maps SOLID→BASE, NONE→TRANSPARENT automatically
  - PADDING: Sections use different values than buttons!
    * Sections: NONE|BASE|BASE_500|SMALL|SMALL_100-500|LARGE|LARGE_100-500
    * Buttons: NONE|EXTRA_TIGHT|TIGHT|BASE|LOOSE|EXTRA_LOOSE
  - BORDERWIDTH: Different for sections vs global divider!
    * Sections/container dividers: BASE|LARGE|LARGE_100|LARGE_200 (NO 'MEDIUM')
    * Global divider: NONE|BASE|MEDIUM
  - DIVIDERS: Global (customizations.divider) has NO visibility field
    * Container dividers (main.divider, orderSummary.divider) DO have visibility
  - letterCase: UPPER not UPPERCASE
  - globalCornerRadius: ONLY accepts NONE (API limitation)
  - control.color: ONLY accepts TRANSPARENT (API limitation)
  - Position: LEFT→START, CENTER→INLINE, RIGHT→INLINE_SECONDARY
  - Changes to TEST profile can be previewed
  - PUBLISHED profile changes are immediately live

ParametersJSON Schema

Name	Required	Description	Default
`profileId`	No
`useProductionProfile`	Yes
`colors`	No
`logoPosition`	No
`logoWidth`	No
`imageId`	No
`designSystem`	No
`customizations`	No
`globalBrand`	No
`primaryButtonColor`	No
`typography`	No

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations, the description fully addresses behavior: defaults to test profile, explains critical enum constraints (e.g., shadow, background mapping), notes API limitations (globalCornerRadius only NONE), and warns about live vs preview changes. No contradictions.

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?

The description is lengthy but well-organized with headings and emojis, front-loading safety and key points. Every section earns its place given the tool's complexity, though some consolidation could improve conciseness.

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?

Given no annotations and no output schema, the description is remarkably complete: covers safety, all customization areas, simplified options, examples, and critical API notes. It leaves nothing essential unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates thoroughly by explaining parameters like globalBrand, primaryButtonColor, and the full designSystem and customizations structures. Provides examples and maps enums to actual values, adding significant meaning beyond the bare schema.

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 'Update checkout branding using Shopify's CheckoutBrandingUpsert API', specifying the action and resource. However, it does not explicitly differentiate from sibling tools like shopify_get_checkout_branding, though the update focus is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., get, list). The safety note about test vs production profiles is provided but does not cover when to choose this tool over others.

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

shopify_upload_custom_font_from_urlA

Upload a custom font from a public HTTPS URL to Shopify Files for use in checkout branding.

  🎨 CUSTOM FONTS ENABLE UNIQUE TYPOGRAPHY:
  Custom fonts allow merchants to use their brand's specific typeface in checkout, creating a cohesive brand experience.
  
  📋 REQUIREMENTS:
  - Font must be in WOFF, WOFF2, TTF, or OTF format (WOFF2 recommended for best performance)
  - URL must be publicly accessible (no authentication)
  - URL must use HTTPS protocol
  - Store must have appropriate webfont license for commercial use
  
  🔄 PROCESS:
  1. Downloads font from provided URL
  2. Uploads to Shopify's CDN as a generic file
  3. Returns genericFileId to use with checkout branding
  
  ⚙️ PARAMETERS:
  - url: HTTPS URL of the font file (required)
  - filename: Optional custom filename (auto-extracted from URL if not provided)
  - mimeType: Optional MIME type (auto-detected from extension: woff2, woff, ttf, otf)
  - fontWeight: Optional weight value 100-900 (default: 400 for regular, 700 for bold)
  - isBold: Optional boolean to mark as bold variant (sets weight to 700)
  
  💡 USAGE WITH CHECKOUT BRANDING:
  After uploading, use the returned genericFileId in shopify_update_checkout_branding:
  
  Example for primary font (body text):
  {
    "designSystem": {
      "typography": {
        "primary": {
          "customFontGroup": {
            "base": {
              "genericFileId": "returned_id",
              "weight": 400
            },
            "bold": {
              "genericFileId": "returned_bold_id",
              "weight": 700
            },
            "loadingStrategy": "SWAP"
          }
        }
      }
    }
  }
  
  Example for secondary font (headings):
  {
    "designSystem": {
      "typography": {
        "secondary": {
          "customFontGroup": {
            "base": {
              "genericFileId": "returned_id",
              "weight": 400
            },
            "bold": {
              "genericFileId": "returned_bold_id",
              "weight": 700
            }
          }
        }
      }
    }
  }
  
  🚀 LOADING STRATEGIES:
  - BLOCK: Block text rendering until font loads (not recommended)
  - SWAP: Show fallback font immediately, swap when custom font loads (recommended)
  - FALLBACK: Short block period, then fallback if not loaded
  - OPTIONAL: Very short block period, may not swap if slow to load
  
  📝 COMPLETE WORKFLOW:
  1. Upload regular font: shopify_upload_custom_font_from_url(url: "https://example.com/myfont-regular.woff2")
  2. Upload bold font: shopify_upload_custom_font_from_url(url: "https://example.com/myfont-bold.woff2", isBold: true)
  3. Apply to checkout: shopify_update_checkout_branding with customFontGroup configuration

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`filename`	No
`mimeType`	No
`fontWeight`	No
`isBold`	No

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description bears full burden. It transparently describes the process (download, upload, return genericFileId), requirements (format, HTTPS), and usage patterns. However, it does not mention error handling, rate limits, or whether previous fonts are overwritten.

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?

Description is well-structured with sections and emojis, front-loading the purpose. It is comprehensive but slightly verbose (e.g., loading strategies section may be excessive). Every section adds value, but could be tightened.

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?

Despite lacking output schema, the description explains the return value (genericFileId) and provides complete examples for both primary and secondary fonts. It covers prerequisites, process, and integration with sibling tools, making it fully self-contained for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description fully defines each parameter's meaning, defaults, and relationships (e.g., isBold sets fontWeight to 700). This compensates completely, adding significant semantic value beyond the schema.

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?

Description explicitly states 'Upload a custom font from a public HTTPS URL to Shopify Files for use in checkout branding.' It clearly identifies the verb (upload), resource (custom font), and purpose (checkout branding), distinguishing it from sibling tools like shopify_upload_logo_from_url and checkout branding updates.

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?

Description provides detailed workflow steps, examples of integration with shopify_update_checkout_branding, and requirements (WOFF/HTTPS). It implies usage context but does not explicitly state when NOT to use or compare to alternatives like other font management tools.

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

shopify_upload_logo_from_urlA

Upload a logo image from a public HTTPS URL to Shopify Files for use in checkout branding.

  Process:
  1. Downloads image from provided URL
  2. Uploads to Shopify's CDN via staged upload
  3. Returns imageId to use with shopify_update_checkout_branding
  
  Requirements:
  - URL must be publicly accessible (no authentication)
  - URL must use HTTPS protocol
  - Supported formats: PNG, JPG, WEBP (not SVG for checkout logos)
  - Recommended dimensions: 200-600px width, maintain aspect ratio
  
  Use the returned imageId with shopify_update_checkout_branding to apply the logo.
  
  Example workflow:
  1. Upload logo: shopify_upload_logo_from_url(url: "https://example.com/logo.png")
  2. Apply to checkout: shopify_update_checkout_branding(imageId: returned_id, logoWidth: 150)

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`filename`	No
`mimeType`	No

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, description covers the process (download, uploaded, staged upload) and requirements, but does not disclose potential failures, rate limits, or side effects. It gives a solid overview but misses some behavioral details.

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?

Well-structured with sections (Process, Requirements, Example workflow). Every sentence adds value. Concise yet informative, no wasted words.

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?

Given no output schema and 3 parameters, description provides process, requirements, example, and return value usage. It lacks error handling or response details, but overall covers essential context for using the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains the 'url' parameter (public HTTPS) and mentions recommended dimensions, but does not clarify 'filename' or 'mimeType'. Partial coverage leaves ambiguity.

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?

Description clearly states action (upload), resource (logo image from URL to Shopify Files), and purpose (checkout branding). It distinguishes from sibling tool shopify_upload_custom_font_from_url by specifying 'logo' and 'checkout branding'.

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?

Provides explicit requirements (public HTTPS, supported formats, dimensions), context (for checkout branding), and an example workflow chaining with shopify_update_checkout_branding. Lacks explicit exclusions (e.g., when not to use), but overall strong guidance.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: getting branding, listing profiles, updating branding, uploading fonts, and uploading logos. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent 'shopify_verb_noun' pattern (e.g., get_checkout_branding, list_checkout_profiles, update_checkout_branding, upload_custom_font_from_url, upload_logo_from_url).

Tool Count5/5

With 5 tools, the set is well-scoped for a checkout branding server: profile listing, branding retrieval/update, and asset uploads. Neither too few nor too many.

Completeness4/5

Covers core workflows: get/list profiles, get/update branding, and upload fonts/logos. Minor gap: no delete functionality for branding or profiles, but these are often available via other means.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

design-system
app.zaklad
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Design Tools Developer Tools
2
Pixelixe
com.pixelixe
Brand-safe MCP for AI agents to create editable, on-brand graphics and automate variants.
Design Tools Marketing App Automation
2
Suparanku
com.suparanku
See and change how AI assistants describe your brand — AI representation management.
Marketing
1
Agent Checkout A
com.agentcheckoutapi
AI shopping gateway for product search, inventory, carts, and merchant-hosted checkout.
E-commerce & Retail Search Payments & Billing
81

Related MCP Servers

MCP Figma
Developer Tools App Automation Content Management Systems
YelowFlash09
A
license
Not graded
quality
D
maintenance
Enables AI assistants to read and modify Figma designs programmatically, supporting design analysis, element creation, text replacement, annotations, auto-layout configuration, and prototype visualization through natural language commands.
Updated 9 months ago (2025-12-02 06:37 UTC)
653
MIT
Figma Copilot
Developer Tools App Automation
xlzuvekas
A
license
B
quality
D
maintenance
Enables AI assistants to interact with Figma designs programmatically, supporting comprehensive design automation including text manipulation with formatting preservation, batch operations, prototyping, auto-layout configuration, and component management.
Updated a year ago (2025-07-08 17:43 UTC)
75
31
4
MIT
F-MCP (Figma MCP Bridge)
Design Tools Developer Tools
atezer
A
license
B
quality
A
maintenance
Enables AI assistants to read, analyze, and modify Figma designs, manage design tokens, and create prototype connections, all while keeping data local.
Updated a month ago (2026-07-31 09:14 UTC)
63
82
9
MIT
Shopify Storefront MCP Server
E-commerce & Retail Customer Data Platforms
QuentinCody
F
license
Not graded
quality
F
maintenance
Enables AI assistants to query and interact with Shopify store data via the Storefront API, including products, collections, carts, and customer information.
Updated a year ago (2025-06-03 21:17 UTC)
9

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shandut/Shopify-Checkout-Branding-MCP-Tool'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Shopify Checkout Branding MCP Tool

✅ Cursor MCP Support Fixed!

🎯 Quick Start

For Claude Desktop Users

For Cursor/HTTP API Users

🚀 Features

Core Tools

Styling Capabilities

API Intelligence

📋 Prerequisites

🛠️ Installation

⚠️ Security Note

Setup Steps

🔧 Configuration

For Claude Desktop

For Cursor or Other Tools (HTTP Mode)

📚 Available MCP Tools

1. shopify_list_checkout_profiles

2. shopify_get_checkout_branding

3. shopify_update_checkout_branding

4. shopify_upload_logo_from_url

5. shopify_upload_custom_font_from_url

💡 Usage Examples

Via MCP (in Claude Desktop)

Via HTTP API (for Cursor)

🏗️ Architecture

🔐 Security

🧪 Testing

📝 Development

🚦 Error Handling

🤝 Contributing

📄 License

⚠️ Known Limitations & Important Notes

Typography Field Restrictions

Other API Limitations

🆘 Support

🗺️ Roadmap

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `shopify_list_checkout_profiles`

2. `shopify_get_checkout_branding`

3. `shopify_update_checkout_branding`

4. `shopify_upload_logo_from_url`

5. `shopify_upload_custom_font_from_url`