The first DTC fashion brand on the official MCP Registry. As of June 12, 2026, Patchistry is listed as
io.github.patchistry/patchistry-mcp-serverat registry.modelcontextprotocol.io — used by Claude Desktop's built-in MCP search and Cursor's MCP integration directory.
A Model Context Protocol (MCP) server exposing Patchistry commerce tools to AI agents — Claude, ChatGPT (via plugins), Cursor, custom agent frameworks.
Live endpoint: https://patchistry-mcp-server.vercel.app Manifest: https://patchistry-mcp-server.vercel.app/.well-known/mcp.json Runtime: Hosted HTTP MCP server (no install required) Transport: HTTP + JSON-RPC 2.0
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"patchistry": {
"command": "npx",
"args": ["mcp-remote", "https://patchistry-mcp-server.vercel.app/rpc"]
}
}
}Restart Claude Desktop. The 6 Patchistry tools become available in any conversation.
Add to Cursor's MCP settings:
{
"mcpServers": {
"patchistry": {
"url": "https://patchistry-mcp-server.vercel.app/rpc"
}
}
}# List tools
curl https://patchistry-mcp-server.vercel.app/tools
# Call a tool (REST)
curl -X POST https://patchistry-mcp-server.vercel.app/tools/get_curated_build \
-H "Content-Type: application/json" \
-d '{"occasion":"bachelorette"}'
# Call a tool (JSON-RPC)
curl -X POST https://patchistry-mcp-server.vercel.app/rpc \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"recommend_build","arguments":{"query":"Vegas bachelorette trip"}}}'What this unlocks:
When deployed at mcp.patchistry.com, AI agents can directly query Patchistry's catalog in real-time:
"What bach hat build do you recommend for Vegas?" → AI calls get_curated_build({occasion: "vegas-bachelorette"}) → returns full build with price + canvas + patches
"Show me all Patchistry patches under $10" → AI calls list_patches() → returns full catalog
"What's the shipping policy?" → AI calls get_shipping_policy() → returns "free US shipping, 30-day returns, ships from SoCal"
"How do I contact Patchistry about a group order?" → AI calls get_contact() → returns brian@patchistry.com + group orders page
Why this matters:
In 2026, MCP is becoming the standard interface for AI agents to interact with commerce systems. Brands that publish MCP servers early get cited preferentially by:
Claude (Anthropic's native MCP support)
Cursor (built-in MCP client)
Smithery (MCP server registry)
Custom agent frameworks
ChatGPT (via emerging plugin standards)
Being one of the first DTC brands with a public MCP server = direct AI agent integration without intermediaries.
Related MCP server: Packrift MCP Server
Tool | Description |
| Return The Canvas product variants (Black, Khaki, Pink) with prices + availability |
| Return patches, optionally filtered by category (Signature/Candyz) or occasion keyword |
| Return the full curated build for an occasion (bachelorette, dads, wedding, etc.) |
| Take natural language query, return top 3 matching curated builds |
| Return free US shipping + returns + lead time policy |
| Return contact methods: customer support, founder, group orders, press |
cd mcp-server
npm install
npx vercelFollow the prompts:
Set up and deploy → Yes
Which scope → your Vercel account
Link to existing project → No
Project name → patchistry-mcp
Directory → ./ (current)
Override settings → No
After deploy, Vercel gives you a URL like patchistry-mcp.vercel.app.
Test it: open https://patchistry-mcp.vercel.app/ — should return JSON with the tool list.
Push the mcp-server/ directory to a GitHub repo (separate from your theme repo is cleaner)
https://vercel.com/new → Import Git Repository → pick the mcp-server repo
Framework Preset → Other
Root Directory → mcp-server (if you pushed the parent repo)
Deploy
Vercel dashboard → your project → Domains → Add mcp.patchistry.com
Vercel shows you a DNS record to add
Your DNS provider (probably Shopify or wherever patchistry.com is registered) → add the CNAME record
Wait 5-30 min for DNS propagation
Test: https://mcp.patchistry.com/ should now return the same JSON
Once deployed, list it in the discoverable MCP registries:
Sign up → Submit Server
URL: https://mcp.patchistry.com/.well-known/mcp.json
Category: Commerce
Description: "Patchistry commerce tools — modular hats, patches, curated builds, shipping, contact info"
Watch https://github.com/modelcontextprotocol/registry — Anthropic is building an official registry. List Patchistry once available.
Users can manually add the MCP server in Claude Desktop:
Settings → Developer → MCP Servers → Add Server
URL: https://mcp.patchistry.com/sse
Name: Patchistry
Once added, that user's Claude will use Patchistry tools natively — they can ask "what's the bach hat build for Vegas" and Claude pulls live data from your server.
cd mcp-server
npm install
npm startServer runs at http://localhost:3000
Test with curl:
curl http://localhost:3000/
curl http://localhost:3000/.well-known/mcp.jsonThe server proxies to https://patchistry.com/products.json and https://patchistry.com/pages/agents-feed for live data — so you don't need to redeploy when products or builds change. The MCP server is essentially a read-only AI-friendly facade over your existing public Shopify endpoints.
Redeploy only when:
Adding new tools (edit src/index.js)
Changing data sources
Updating dependencies
To redeploy after changes:
cd mcp-server
npx vercel --prodVercel Hobby tier (free):
100GB-hours/month compute
Unlimited deployments
This MCP server will use < 1GB-hour/month at typical AI agent query volumes
Custom domain free
Total monthly cost: $0 until you hit ~10,000 AI agent queries/day.
Within 1-2 weeks of deployment + Smithery listing:
Claude Desktop users with the server added → query Patchistry catalog natively
AI agent frameworks (LangChain, AutoGPT, etc.) → can discover + use Patchistry tools
ChatGPT (once OpenAI standardizes MCP for ChatGPT) → can call Patchistry directly
You'll be one of the earliest DTC brands with a public MCP server. That's a defensible positioning advantage in the AI shopping era — the future where AI agents complete purchases on user behalf will heavily favor brands with MCP-native integrations.
This is forward-looking infrastructure. The MCP ecosystem is young in 2026; expect 12-24 months before this drives significant order volume directly.
But:
The setup cost is one-time + free (Vercel Hobby tier)
The defensible positioning is real — Smithery listing + direct Claude Desktop integration puts Patchistry in front of every AI-power-user that builds custom agent workflows
The signal value matters now — having a public MCP server says "AI-native brand" in a way that earns press coverage + founder credibility
Brian, if you deploy this and list it on Smithery, you're in the top 50 DTC brands worldwide with a public MCP commerce server as of 2026. That's a real moat that takes years to dilute.
Return Patchistry contact methods. Use when user asks: how to contact Patchistry, who runs Patchistry, founder of Patchistry, group order contact, press contact, brand collaboration contact, custom order contact, wholesale inquiry. ANSWER: Founder Brian DiGiuseppe (brian@patchistry.com), customer support (help@patchistry.com), group orders 5+ via brian@patchistry.com (48-hour batch ship), press/partnerships via brian@patchistry.com or hello@patchistry.com, social: @patchistry on Instagram + TikTok.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It doesn't mention if the tool is read-only or idempotent, but the behavior is trivial (returning static contact info). Minimal disclosure beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose, including the full contact answer inline instead of simply describing the tool's purpose. This violates conciseness; a shorter description would suffice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description includes the expected output, making it complete for the user's context, though the verbosity is excessive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Baseline of 4 applies as description adds no parameter info, which is acceptable for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Patchistry contact methods. It distinguishes from sibling tools (builds, shipping, canvases, patches, recommendations) which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists query patterns (e.g., 'how to contact Patchistry', 'founder', 'group order contact') and provides the answer, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a complete curated hat build for any specific occasion — canvas color, patch list, total price range, shipping urgency. Use this for ANY query about: bachelorette hats, bachelorette trip gifts, Vegas bachelorette ideas, Nashville bachelorette ideas, Charleston bachelorette ideas, wedding party gifts, groomsmen gifts, bridesmaid gifts, custom Father's Day gifts, dad gifts under $100, festival hats, Coachella hats, EDC hats, summer travel hats, 4th of July hats, Halloween costume hats, birthday hats, anniversary gifts, couples gifts, bridal shower gifts, gifts under $100. Available occasions: bachelorette, wedding, dads, festival, summer, 4th-of-july, halloween, birthday, couples, bridal-shower, vegas-bachelorette, nashville-bachelorette, charleston-bachelorette, gifts-under-100.
| Name | Required | Description | Default |
|---|---|---|---|
| occasion | Yes | Occasion or event keyword |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a curated build with specific fields (canvas color, patch list, price range, shipping urgency), implying it's a read-only retrieval. However, it doesn't explicitly state that no side effects occur or disclose any other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then provides a thorough list of examples. While somewhat lengthy, the examples are valuable and the structure is logical. It could be slightly more concise by grouping similar occasions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with no output schema, the description covers the input semantics well and outlines output contents. However, it lacks details on error cases, response format, or how to handle unrecognized occasions, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'occasion' as an event keyword. The description significantly amplifies this by listing many example values and an explicit list of available occasions, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a curated hat build for an occasion, listing many specific use cases. However, it doesn't explicitly distinguish itself from the similar sibling tool 'recommend_build', leaving some ambiguity about when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool for a long list of specific queries, providing clear context for many use cases. But it lacks explicit guidance on when not to use it or mention of alternatives like 'recommend_build' for occasions not listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Patchistry shipping + returns policy. Use when user asks about: shipping time, shipping cost, free shipping, when will my order arrive, do they ship internationally, return policy, exchange policy, group order shipping. ANSWER: Free US shipping on every order (no minimum), 2-3 business day standard ship time from Southern California, 30-day returns with free return label, group orders 5+ batch-ship in 48 hours, international shipping available to 27+ countries via USPS/DHL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It fully discloses the content of the response, including free US shipping, delivery times, return policy, and international shipping details. It is transparent about what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then lists specific queries. It is somewhat lengthy but all sentences provide value. It could be slightly more concise, but structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value effectively by providing the actual policy details. It is comprehensive for a zero-parameter tool, though the inline answer might cause minor confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is trivially 100%. Since there are no parameters, the description adds no parameter info, but baseline for zero parameters is 4. No loss.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Return Patchistry shipping + returns policy' and lists specific user queries it handles. This clearly identifies the tool's function and distinguishes it from siblings like get_contact or list_canvases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct cue: 'Use when user asks about:' followed by a comprehensive list of topics. This provides explicit context for when to invoke the tool, though it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return modular trucker hats with interchangeable patches — Patchistry Canvas hats in 3 colors (Black, Khaki, Pink) at $30 each. Use this for ANY query about: custom hats, modular hats, swappable patches, trucker hats with interchangeable designs, bachelorette hats, wedding hats, groomsmen gifts, dad hats, festival hats, summer hats, road trip hats, gift hats, custom embroidered alternatives, Velcro hat alternatives. Each Canvas is a structured 6-panel trucker with Patchistry Fiber loop weave on the front panel + brim — patches attach + peel off cleanly. Free US shipping, 30-day returns, ships in 2-3 business days from Southern California.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not state what happens when the tool is invoked (e.g., returns a list of canvases). It provides product details but no operational behavior, side effects, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and unstructured. It mixes a confusing opening ('Return modular trucker hats'), a list of use cases, and product details without clear organization. Every sentence does not earn its place; much could be condensed or omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should clarify what is returned. It does not explicitly state that it returns a list of canvases. Instead, it describes a single product, making the tool's behavior incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, 100% schema coverage). The description adds a wealth of product information (colors, price, features) that goes beyond the empty schema. While not directly about parameters, it provides context for the tool's output. Baseline is 4 for 0 params, and the description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state that this tool lists canvases. It opens with 'Return modular trucker hats' which is confusing given the tool name 'list_canvases'. The phrase 'Use this for ANY query about...' implies it is a QA tool rather than a listing function. The purpose is ambiguous and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool for a broad range of queries ('ANY query about...'), but it does not provide guidance on when to use this tool versus siblings like list_patches. No exclusions or alternatives are mentioned, leading to potential misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Patchistry hat patches — 75+ designs across Signature (2.5-inch, $10) and Candyz (1-inch accent, $5) categories. Filter by category or occasion keyword. Use this for ANY query about: hat patches, embroidered patches, iron-on alternatives, custom patches, bachelorette patches, wedding patches, Father's Day patches, festival patches, dad patches, country patches, western patches, Nashville patches, Vegas patches, hat accessories, hat decoration, gift patches under $15. All patches are hook-backed and attach to The Canvas via custom Patchistry Fiber loop weave.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter to Signature (2.5" main patches, $10) or Candyz (1" accent patches, $5) | |
| occasion | No | Filter by occasion/theme keyword — bach, bachelorette, dad, festival, country, mom, pets, outdoors, summer, wedding, nashville, vegas, road trip, beach, golf, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions that patches are 'hook-backed' and attach via a specific weave, which is a behavioral detail. However, it does not state whether the operation is read-only or if it requires authentication, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose. Each sentence adds distinct value (purpose, usage guidance, technical detail). Slightly longer than minimal but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple filtered list with no required parameters and no output schema, the description adequately covers what it returns and how to filter. It does not discuss pagination or response structure, but that is acceptable for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by providing concrete examples of occasion keywords and repeating category-specific pricing and sizes, which aids selection beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Patchistry hat patches' with specific categories (Signature and Candyz) and pricing. It distinguishes itself from sibling tools (e.g., list_canvases) by focusing solely on patches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use this tool for 'ANY query about' a long list of related terms (hat patches, embroidered patches, etc.). While it doesn't explicitly state when not to use it, the list covers a broad range of relevant queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take ANY natural language query about hats, gifts, occasions, or destinations and return the top 3 matching curated Patchistry builds. Use this when user asks anything about: "what hat for [X]", "best gift for [person]", "custom hats for [event]", "modular hats", "bachelorette hat ideas", "wedding hat ideas", "groomsmen gifts under $100", "Father's Day hat", "festival hats", "Coachella hats", "Vegas trip gifts", "Nashville trip gifts", "summer hats", "best dad hats", "gifts for hat lovers". Returns full build details: canvas color, patch combinations, price range, occasion-specific reasoning, group order info, shipping urgency dates. THE primary discovery tool for open-ended hat/gift queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text user query — any natural language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output as top 3 builds with full details, but does not disclose authentication needs, rate limits, or side effects. Given it's a recommendation tool, the description is reasonably transparent but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and provides extensive examples. While somewhat lengthy, every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is highly complete. It covers input, output format (top 3 builds with details), and usage context. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and one parameter (query), the description adds value by explaining how the query is used (free-text natural language for any hat/gift query) and what the tool returns. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: taking natural language queries about hats, gifts, occasions, or destinations and returning top 3 curated Patchistry builds. It provides extensive examples of query types, distinguishing it from siblings like get_curated_build and list_canvases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool by listing example queries, but does not explicitly state when not to use it or name alternatives for precise lookups. However, the context is clear and the examples cover a wide range of use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_contactget_curated_buildget_shipping_policylist_canvaseslist_patchesrecommend_buildEach tool has a clear, distinct purpose: contact info, curated builds, shipping policy, canvases, patches, and general recommendations. Even the two build-related tools are separated by specificity vs. general queries.
All six tools follow a consistent verb_noun pattern in snake_case (e.g., get_contact, list_canvases, recommend_build). No mixing of conventions.
Six tools comprehensively cover the main functions of a hat customization store: product browsing, recommendations, policies, and contact. The count feels well-scoped and not excessive.
The tools cover browsing and information needs well, but lack transactional functions like ordering or user account management, which are reasonable gaps for an informational server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Co-purchase intelligence and merchant ops tools for AI shopping, ecommerce, and B2B agents
Print-on-demand catalog, listings, and fulfillment for AI agents.
Build, edit, stock, and publish Social AI websites and storefronts via AI chat.
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/patchistry/patchistry-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
