MyDesigns
REMOTE · MCP.MYDESIGNS.IO
Create print-on-demand products, publish them to your MyDesigns store, and track sales.
Available components
Last scanned (18 hours ago)
Scores higher than 45% of remote servers
Reachable. Last reached 4 Nov 2026.
Category E-commerce
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security57
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (remove_store_domain). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability78
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 7560 tokens (~198/item across 38 items; 34 tools + 4 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (24% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 36 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
- Supports UI / widget rendering.Pass
Unverified: 1 category
A category scored 0 because we could not verify it: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 65
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Probed https://mcp.mydesigns.io/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=mydesigns.io | CN=YE2,O=Let's Encrypt,C=US | 12 Oct 2026 | 10 Jan 2027 | ECDSA 256 | ECDSA-SHA384 | 6d32610e032a6df8e27303c5be0ee907c55 |
| SANs: *.mydesigns.io, mydesigns.io | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.mydesigns.io. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| io. | present | 38690 | 8 | Verified |
| mydesigns.io. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.mydesigns.io/mcp | Verified | 200 | |
| http (plaintext) | http://mcp.mydesigns.io/mcp | HTTPS enforced | 301 | https://mcp.mydesigns.io/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_store_domain Add store domain ~142
Connect a domain the seller already owns to a store; it does not buy one. A root domain (example.com) also adds its www version. Needs a paid plan. The result lists the store's domains with the DNS record to add for each: give the seller those exact values to add where they bought the domain. A domain usually goes live a few minutes to a few hours after the record is added; check it then with check_store_domain.
| Name | Type | Req | Description |
|---|---|---|---|
| hostname | string | yes | The domain alone, e.g. shop.example.com or example.com: no https:// and no path. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
check_store_domain Check store domain ~60
Check again whether a domain is live, after the seller added its DNS record. While it is not live, the result repeats the record to add and any problem found with it.
| Name | Type | Req | Description |
|---|---|---|---|
| domainId | string | yes | The domain id from list_store_domains. |
No output schema declared.
No examples provided.
create_designs Create designs (Dream AI) ~640
Create designs, the app's Dream AI: make 1 to 10 designs for the seller with AI, one per prompt, and save them in their MyDesigns designs. No product is made. When the seller asks for Dream AI or the dreamer, or to dream designs, use this tool. Use it too when the seller wants designs only, or wants to see the designs before choosing products; when they want products, create_products makes the designs and the products in one call. Plan exactly as many designs as the seller asked for, each with its own idea; for more than 10, call again with the rest. The designs are generated together, about 1.5 AI credits each on the default model (other models cost more or less), and take up to a minute or two. Before designs the seller did not clearly ask for (redos, more versions, a vague "make them pop"), tell them they cost credits and wait for a yes. A design that could not be made is listed with the reason and the others are still made. A card shows the seller the designs, so do not put the images in your reply. To make products from them later, give create_products their designIds, never their prompts again: a prompt makes a new design and costs credits again.
| Name | Type | Req | Description |
|---|---|---|---|
| aspectRatio | string|null | – | The shape of all the designs as width:height, e.g. "1:1" (default), "2:3", "3:4", "16:9". Each model has its own sizes, so the closest one it has is used. |
| designs | array | yes | The designs to make, 1 to 10. |
| folderId | integer|null | – | The folder id from list_folders that the designs go in. Leave it out for the seller's first folder. |
| model | string|null | – | The AI model for all the designs. Leave it out for GPT Image 2.5 Sunburst; use another only when the seller asks for it. gpt-image-2.5-sunburst, gpt-image-2.5-flare, gpt-image-2, gpt-image-1.5, gpt-i… |
| Name | Type | Req | Description |
|---|---|---|---|
| designs | array | yes | – |
| problems | array | yes | – |
| status | string | yes | – |
No examples provided.
create_folder Create folder ~117
Make a design folder, at the top level or inside another folder. Names must differ from the other folders in the same place; check list_folders first to reuse one that already exists. Then pass its id as folderId to create_products, create_designs or deep_search_designs.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | The folder name, e.g. the niche or the store it is for. |
| parentId | integer|null | – | The folder id from list_folders to put it inside; leave it out for a top-level folder. |
No output schema declared.
No examples provided.
create_products Create products ~461
Create 1 to 10 print-on-demand products for the seller, one per design: generate each design from a prompt with AI (or use an existing design), then make them into products with one of the seller's product profiles, which sets the products, colors, sizes, prices and mockups. Find the profile with list_profiles first: when the seller named a product (a tee, a Gildan 5000, a mug), search for it and use a profile only if it clearly fits. When the seller named no product, or nothing fits, show them a few profiles and ask which to use; never pick one for them. Plan exactly as many products as the seller asked for, each with its own design idea, and count them before calling; for more than 10, call again with the rest. The designs are generated together, about 1.5 AI credits each (a reused designId costs none), and take up to a minute or two. Before new designs the seller did not clearly ask for (redos, more versions, a vague "make them pop"), tell them they cost credits and wait for a yes. A design that could not be made is listed with the reason and the others still go ahead. The products are saved together in the seller's MyDesigns products, not put in any store; they are not drafts. They are then made in the background over a few minutes: check them with get_product_status and the one jobId returned here, and tell the seller when they are ready. Show the seller the design images.
| Name | Type | Req | Description |
|---|---|---|---|
| folderId | integer|null | – | The folder id from list_folders that new designs go in. Leave it out for the seller's first folder. A reused designId stays where it is. |
| products | array | yes | The products to make, 1 to 10, each from its own design. |
| profileId | integer | yes | The profile id from list_profiles, one the seller asked for or chose. Never guess one. When more than one profile fits what they asked for (two t-shirts, say), ask which before calling, even when the… |
| Name | Type | Req | Description |
|---|---|---|---|
| failedDesigns | array | yes | – |
| jobId | string | yes | – |
| productGroupId | integer | yes | – |
| products | array | yes | – |
| status | string | yes | – |
| variantCountPerProduct | integer | yes | – |
No examples provided.
create_store Create store ~305
Open a new MyDesigns store for the seller. It is live at its link right away but empty: put products in it with publish_products. It can take orders only once it is on a payout account. Check list_stores first: the plan limits how many stores a seller can have, and when the seller has a payout account that is ready, ask whether to use it for this store, naming it by the stores already on it, and on their yes pass it as payoutAccountId; with none ready, the seller sets up payouts in the MyDesigns app. Before calling, tell the seller the name and the web link you will use and wait for their yes: the link cannot be changed later.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | yes | Short description of what the store sells. |
| name | string | yes | Store name buyers see. |
| payoutAccountId | integer|null | – | The id of one of the seller's payout accounts from list_stores to put the store on, so it can take orders. Only one that is ready; ask the seller first. |
| slug | string | yes | The store's web link name, not a postal address: lowercase letters, digits and hyphens, e.g. funny-dog-tees, so the link becomes https://funny-dog-tees.mdstore.io. Make it from the store name when th… |
No output schema declared.
No examples provided.
create_store_images Create store images ~290
Make images for one of the seller's stores with Dream AI and put them on it: the logo, the banner across the top of the home page, a separate banner for phones, and the favicon (the small icon in the browser tab). MyDesigns picks the model, shape and size each image needs and puts it on the store straight away, in place of the one there; the images are not saved in the seller's designs. A favicon given no prompt is made from the logo in the same call, at no extra cost. It costs AI credits: 1.5 for a logo or a favicon, 3 for a banner or a phone banner. Before calling, tell the seller the cost and which of their current images it replaces, and wait for their yes. When they do not like one image, call again with only that one. Images you make with your own image tool stay in this chat and cannot be put on the store: use this instead. Make one call at a time for a store, never several at once. For the seller's own image, use upload_store_image; to take an image off, use update_store. An image with an error in the result was not set: tell the seller.
| Name | Type | Req | Description |
|---|---|---|---|
| images | array | yes | The images to make, each at most once. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
deep_search_designs Deep search designs ~421
Deep search, the app's Scout AI: MyDesigns researches what really sells for one or more niches on Amazon right now and makes designs from each, each with a title, description and tags. It is heavy research that takes a few minutes, so do your own research and use create_products by default; offer deep search only when the seller wants to know what sells or wants ideas from real sales data, tell them it uses up to 1.5 AI credits per design, and start it only after they agree. Needs a Pro plan or higher; one deep search runs at a time, so put every search term in one call, one per line: they run as one job, like the Scout AI page. Then check it with get_deep_search_results and the jobId returned here, show the seller the designs, and make products from the ones they pick with create_products and their designIds.
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | How many designs to make for each search term, 1 to 10. |
| folderId | integer|null | – | The folder id from list_folders that the designs go in. Leave it out for the seller's first folder. |
| instructions | string|null | – | The seller's own instructions for how every design looks, in their words, as on the Scout AI page, e.g. "light colored text and elements, so they stand out on black shirts". Leave it out when the sel… |
| niche | string | yes | The search terms, in the seller's words, one per line and up to 20, e.g. "funny nurse" or "funny nurse\nfishing dad". |
| productType | string | – | The kind of product the designs are for: standard_tshirt (default), premium_tshirt, pullover_hoodie, crewneck_sweatshirt, long_sleeve, tank_top, mug, tumbler, tote_bag, throw_pillow, paper_poster, ca… |
No output schema declared.
No examples provided.
delete_design_from_card Delete design from card ~49
Move one design to the seller's trash. The designs card calls this when the seller deletes a design from it.
| Name | Type | Req | Description |
|---|---|---|---|
| designId | integer | yes | The design's id, from the card. |
No output schema declared.
No examples provided.
delete_designs Delete designs ~122
Move designs the seller does not want to their MyDesigns trash, by the designIds create_designs, deep search or an upload gave. Use it only when the seller asked to delete them; when it is not clear which ones they mean, ask. They can restore them from the trash in the MyDesigns app for a while. The AI credits the designs cost are not given back. Never use a deleted designId again, for create_products or anything else.
| Name | Type | Req | Description |
|---|---|---|---|
| designIds | array | yes | The designIds to delete, up to 50. |
No output schema declared.
No examples provided.
get_account Get account ~149
Get the signed-in MyDesigns account: its id, name, email, subscription plan code (TIER_0 is the free plan) and the subscription that plan comes from: where it is billed (STRIPE, SHOPIFY, PKS, or NONE for the free plan), the plan type (STARTER, PRO, PRO_PLUS), the plan name, status, frequency (MONTHLY, YEARLY, LIFETIME), list price, when it renews or ends, any coupon, and for Stripe the amount the last invoice actually charged after discounts. Fields a billing source does not have are null. aiCredits is how many AI credits the seller has left; new designs spend them.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_deep_search_results Get deep search results ~166
The designs a deep_search_designs run has made, by its jobId. RUNNING: still researching or designing, which usually takes a few minutes; the designs so far are listed; check again later, not over and over. DONE: all made. A card shows the seller each design's image and title, so do not put the images in your reply. The titles are long, search-friendly ones: shorten them for create_products if the seller wants. A design on trademarkHold has text a trademark check flagged; tell the seller before they sell it. Problems say why a niche found nothing or a design was skipped. NOT_FOUND: no deep search by that id for this seller.
| Name | Type | Req | Description |
|---|---|---|---|
| jobId | string | yes | The jobId deep_search_designs returned. |
| Name | Type | Req | Description |
|---|---|---|---|
| designs | array | yes | – |
| jobGuid | string | yes | – |
| problems | array | yes | – |
| status | string | yes | – |
No examples provided.
get_order Get order ~163
Get one MyDesigns order by its id: the seller and their shop, the payment method, the billing address, every print partner with its own fulfillment status, created date and tracking, and every line with its partner, SKUs, print areas and manufacturing cost. One order can hold several fulfillments at the same partner, so a partner name is not unique. An admin token reaches any order; any other token reaches only that seller's own orders. userId, userEmail, providerCode and isPrintify are for support staff: when talking to the seller, name the marketplace in words (MyDesigns Store, Etsy) and leave those out.
| Name | Type | Req | Description |
|---|---|---|---|
| orderId | integer | yes | The MyDesigns order id, the number shown on the order page. |
No output schema declared.
No examples provided.
get_product_status Get product status ~159
Check whether products started with create_products are made yet, or products sent with publish_products are in the store yet, by the jobId each call returned. CREATING: still being made or published, which usually takes a few minutes; check again later, not over and over. READY: all made (or all in the store). FAILED: done, but some or all were not made; the failed list gives each one's designId and the reason, and the design is kept, so it can be tried again with that designId. NOT_FOUND: no such product job for this seller, or one started only seconds ago.
| Name | Type | Req | Description |
|---|---|---|---|
| jobIds | array | yes | The jobId of each create_products call to check, up to 25. |
No output schema declared.
No examples provided.
get_store_stats Get store stats ~167
Get a store's real performance over the last N days: orders, items sold, revenue, profit and fees in USD, visits, and its top products, each compared with the N days before. Fees are everything the sales cost the seller: making and shipping the products plus marketplace fees, so call them costs, not fees alone. Top products are ranked by net sales, then by page views; only products with tracked page views are listed, so one that sold without a tracked view is missing from the list. The numbers come from daily rollups, so today's activity can be missing.
| Name | Type | Req | Description |
|---|---|---|---|
| days | integer | – | How many days back to look, e.g. 7, 30 or 90. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
list_designs List designs ~169
List the seller's designs with their folder, title, tags and picture, folder by folder in the order list_folders gives, about 50 at a time. Give folderId for one folder, and search to find designs by title, tags or file name. When nextCursor is set there are more: call again with it and the same folderId and search. A cursor counts designs by place, so after moving or deleting designs it would skip some: start again without it.
| Name | Type | Req | Description |
|---|---|---|---|
| cursor | string|null | – | The nextCursor of the call before, for the next designs. |
| folderId | integer|null | – | The folder id from list_folders; leave it out for all folders. |
| search | string|null | – | Words to look for in the title, tags or file name. |
No output schema declared.
No examples provided.
list_folders List folders ~65
List the seller's design folders with how many designs each holds. parentId is the folder it sits in, null for a top-level one. New designs go in the first top-level folder unless create_products, create_designs or deep_search_designs is given a folderId.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_orders List orders ~116
List the seller's orders, newest first, 16 per page: order id, date, status, which shop or store it came from, the buyer's name, the total in USD and the items. Use it for the seller's latest orders or to find an order's id; get_order gives one order in full.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, from 1. |
| storeId | integer|null | – | Only this store's orders: a store id from list_stores. Leave it out for every shop. |
No output schema declared.
No examples provided.
list_product_types List product types ~141
Search the MyDesigns print-on-demand catalog: the blank products a design can be printed on (t-shirts, mugs, ...), with brand, product code, price range, number of variants and the print partners that make it. 24 per page. This is the catalog, not what the seller can make today: a product is made only from a profile, so use list_profiles for that.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, starting at 1. |
| search | string|null | – | Words to search for, e.g. 'gildan 5000', 'hoodie' or 'mug'. Leave empty to browse. |
No output schema declared.
No examples provided.
list_products List products ~209
List the seller's products, newest first, 24 per page: title, the blanks it is made on, when it was made, where it is (the store or shop it is in, or none when it is not in a store yet), price range, public link, status, how many items have been ordered, and the designId it is made from, which create_products can reuse at no credit cost. Leave storeId out to see every product, for questions like "did my last products go live" or "what is not in a store yet".
| Name | Type | Req | Description |
|---|---|---|---|
| inStore | boolean|null | – | true: only products in a store or shop. false: only products not in one yet. |
| page | integer | – | Page number, starting at 1. |
| search | string|null | – | Words to search for in the product title. |
| storeId | integer|null | – | Only this store's products: a store id from list_stores. Leave it out for every product. |
No output schema declared.
No examples provided.
list_profiles List product profiles ~215
List the product profiles a product can be made from. A profile is a saved set of products (t-shirt, mug, ...) with their print partner, colors, sizes, prices and mockups, so a design becomes a product without choosing each of those. Shows the seller's own profiles, or MyDesigns' public ones. Each has its products with colors, sizes and price range. These are the only products the seller can make: when neither their own nor the public profiles have one, it cannot be made. 24 per page.
| Name | Type | Req | Description |
|---|---|---|---|
| page | integer | – | Page number, starting at 1. |
| publicProfiles | boolean | – | True for MyDesigns' public profiles, false for the seller's own. Look at the seller's own first; use the public ones when they have none or none fits. |
| search | string|null | – | Words to search for in the profile name or its products' names and kinds, e.g. 't-shirt', 'mug' or 'gildan'. |
No output schema declared.
No examples provided.
list_store_domains List store domains ~80
List a store's own domains (like shop.example.com): whether each is live, which one is the main link buyers land on, and for each one not live yet the DNS record the seller must add where they bought the domain. A store has up to 3 domains.
| Name | Type | Req | Description |
|---|---|---|---|
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
list_stores List stores ~93
List the signed-in seller's MyDesigns stores with their public link, whether they can take orders yet (payouts connected), how many more stores the plan allows, and each store's about and contact details and seller info, with the seller info still missing. payoutAccounts are the seller's payout accounts, with the stores already on each, that a store can be put on with create_store or update_store.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
move_designs Move designs ~149
Move designs into another of the seller's folders, by the ids list_designs gives, up to 100 at a time. Before moving more than a few, show the seller which go where and wait for their yes. Each folder is set up with its own image slots and fields, and designs move only between folders set up the same way; the result says which could not move and why. Those the seller moves in the MyDesigns app, where they choose where each image and field goes.
| Name | Type | Req | Description |
|---|---|---|---|
| designIds | array | yes | The design ids from list_designs, up to 100. |
| folderId | integer | yes | The folder id from list_folders to move them into. |
No output schema declared.
No examples provided.
product_creation_progress Product creation progress ~41
How far a product job has got. The product card calls this while it is open.
| Name | Type | Req | Description |
|---|---|---|---|
| jobId | string | yes | The jobId create_products returned. |
| Name | Type | Req | Description |
|---|---|---|---|
| failed | array | yes | – |
| jobId | string | yes | – |
| ready | integer | yes | – |
| readyDesignIds | array | yes | – |
| status | string | yes | – |
| total | integer | yes | – |
No examples provided.
publish_products Publish products ~233
Put products into one of the seller's MyDesigns stores, where buyers can see and order them. Give either the jobId a create_products call returned, once get_product_status says READY (or FAILED, which publishes the ones that were made), or the productIds of products from list_products that are not in a store yet, e.g. ones made in an earlier chat. Products already in a store cannot be published again. Ask the seller which store when they have more than one; never pick one for them. The products then go into the store in the background over a few minutes: check with get_product_status and the jobIds returned here, and tell the seller when they are live.
| Name | Type | Req | Description |
|---|---|---|---|
| jobId | string|null | – | The jobId create_products returned. Give this or productIds. |
| productIds | array|null | – | Product ids from list_products, of products not in a store yet. Products made at different times go in one set at a time, each with its own jobId. Give this or jobId. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
remove_store_domain Remove store domain ~61
Disconnect a domain from its store; the seller keeps owning it. If it was the main link, the store's MyDesigns link takes over. Ask the seller before removing one.
| Name | Type | Req | Description |
|---|---|---|---|
| domainId | string | yes | The domain id from list_store_domains. |
No output schema declared.
No examples provided.
save_store_image Save store image ~86
Puts one file from the store image upload card on the store. The card calls this.
| Name | Type | Req | Description |
|---|---|---|---|
| base64 | string | yes | The file, base64. |
| image | string | yes | Which image: logo, banner, mobile_banner or favicon. |
| name | string | yes | The file's name. |
| storeId | integer | yes | The store id upload_store_image answered with. |
| Name | Type | Req | Description |
|---|---|---|---|
| height | integer|null | yes | – |
| image | string | yes | – |
| shapeNote | string|null | yes | – |
| width | integer|null | yes | – |
No examples provided.
save_uploaded_design Save uploaded design ~65
Saves one file from the upload card as a design. The card calls this.
| Name | Type | Req | Description |
|---|---|---|---|
| base64 | string | yes | The file, base64. |
| folderId | integer | yes | The folder id upload_designs answered with. |
| name | string | yes | The file's name. |
| Name | Type | Req | Description |
|---|---|---|---|
| designId | integer | yes | – |
| name | string | yes | – |
No examples provided.
set_store_main_domain Set store main domain ~98
Choose the store's main link: one of its domains, or with no domainId its own MyDesigns link. Its other links send buyers to the main one. Choose a domain only once it is live.
| Name | Type | Req | Description |
|---|---|---|---|
| domainId | string|null | – | The domain id from list_store_domains; leave it out to make the store's MyDesigns link main. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
update_seller_info Update seller info ~418
Change the seller info of one of the seller's stores: who sells there (a person or a business), their legal address and how to reach them. The store's legal pages show it, so fill it only with what the seller tells you: never guess or make up a name, address or tax number. Only the values given change, but the store keeps seller info only when it is complete, as the app does: when list_stores shows some missing, ask the seller for all of it first, then make one call.
| Name | Type | Req | Description |
|---|---|---|---|
| addressCity | string|null | – | City. |
| addressCountry | string|null | – | Two-letter country code, e.g. US or DE. |
| addressLine1 | string|null | – | Street and number. |
| addressLine2 | string|null | – | Second address line: suite, floor or unit. |
| addressState | string|null | – | State or province, e.g. IL; needed in the United States and Canada. |
| addressZip | string|null | – | ZIP or postal code. |
| clear | array|null | – | Fields to remove, any of: dbaName, addressLine2, addressState, phone, vatId, registrationNumber. |
| dbaName | string|null | – | The name a business trades under, when it is not its legal name. |
| legalEmail | string|null | – | Email for legal notices, shown on the legal pages. |
| legalName | string|null | – | The person's full legal name, or the business's legal name. |
| phone | string|null | – | Phone number. |
| registrationNumber | string|null | – | A business's company registration number, e.g. HRB 12345. |
| sellerType | string|null | – | individual when a person sells in their own name, business when a company does. Needed the first time; ask the seller. |
| storeId | integer | yes | The store id from list_stores. |
| vatId | string|null | – | VAT or tax ID, e.g. DE123456789. |
No output schema declared.
No examples provided.
update_store Update store ~566
Change a store's name, description, accent color, banner text, the logo's size and whether the store name shows next to it in the header, or its About page: the about text, the contact email, phone and address, and links to its social media. Only the values given change; everything else stays as it is; images are made with create_store_images or uploaded with upload_store_image, and the seller info is changed with update_seller_info. To remove a value or an image and go back to the store's default, name it in clear. payoutAccountId puts the store on one of the seller's payout accounts from list_stores: ask the seller first, naming the account by the stores already on it.
| Name | Type | Req | Description |
|---|---|---|---|
| aboutText | string|null | – | Text for the store's About section. |
| accentColor | string|null | – | Accent color as a hex code, e.g. #1E88E5. |
| bannerHeadline | string|null | – | Big headline on the home page banner. |
| bannerSubtitle | string|null | – | Smaller line under the banner headline. |
| clear | array|null | – | Fields to remove, any of: accentColor, bannerHeadline, bannerSubtitle, aboutText, contactEmail, contactPhone, contactAddress, socialLinks (all of them) or one link by its name (instagram, tiktok, fac… |
| contactAddress | object|null | – | Postal address shown on the About page. Only the parts given change. |
| contactEmail | string|null | – | Email buyers can write to, shown on the About page. |
| contactPhone | string|null | – | Phone number shown on the About page. |
| description | string|null | – | New store description. |
| logoSize | string|null | – | How big the logo is in the store's header: small, medium (the default), large or extra_large. |
| name | string|null | – | New store name. |
| payoutAccountId | integer|null | – | The id of one of the seller's payout accounts from list_stores to put the store on, so it can take orders. Only one that is ready; ask the seller first. |
| showStoreNameInHeader | boolean|null | – | Whether the store name shows in the header next to the logo; turn it off when the logo already has the name in it. A store with no logo always shows its name. |
| socialLinks | object|null | – | Links to the store's social media pages, shown on the About page, each a full link such as https://instagram.com/yourstore. Only the links given change. |
| storeId | integer | yes | The store id from list_stores. |
No output schema declared.
No examples provided.
upload_designs Upload designs ~128
Open a card where the seller uploads their own images (PNG or JPEG, up to 20 MB each) as designs. Use it when the seller wants products from art they already have: you cannot take an image from the chat, and never write a prompt to recreate one. The card saves the files and then gives you their designIds, which create_products takes instead of a prompt, at no credit cost. Uploading costs nothing.
| Name | Type | Req | Description |
|---|---|---|---|
| folderId | integer|null | – | The folder id from list_folders to save the designs in. Leave it out for the seller's first folder. |
| Name | Type | Req | Description |
|---|---|---|---|
| folderId | integer | yes | – |
| folderName | string | yes | – |
| maxFileBytes | integer | yes | – |
| note | string | yes | – |
No examples provided.
upload_store_image Upload store images ~182
Open a card where the seller uploads their own images for one of their stores: the logo, the banner across the top of the home page, a separate banner for phones, or the favicon (the small icon in the browser tab). Use it when the seller already has the image: you cannot take an image from the chat. The card resizes each file and puts it on the store straight away, in place of the one there; it is not saved in the seller's designs. Free. Nothing comes back to you: when the seller says they are done, the images are on the store.
| Name | Type | Req | Description |
|---|---|---|---|
| images | array|null | – | The images the seller wants to upload, any of: logo, banner, mobile_banner, favicon. Leave it out for the logo and the banner. |
| storeId | integer | yes | The store id from list_stores. |
| Name | Type | Req | Description |
|---|---|---|---|
| maxFileBytes | integer | yes | – |
| note | string | yes | – |
| slots | array | yes | – |
| storeId | integer | yes | – |
| storeName | string | yes | – |
No examples provided.
How do I install the MyDesigns MCP server?
MyDesigns is a hosted endpoint at https://mcp.mydesigns.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.mydesigns.io
claude mcp add --transport http io-mydesigns-mcp 'https://mcp.mydesigns.io/mcp'
What is the MyDesigns MCP server?
MyDesigns is an MCP server listed in the public MCP registry as io.mydesigns/mcp. Create print-on-demand products, publish them to your MyDesigns store, and track sales. This page covers its hosted endpoint (https://mcp.mydesigns.io/mcp).
Is the MyDesigns MCP server safe to use?
MyDesigns scores 65 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the MyDesigns MCP server expose?
MyDesigns exposes 34 tools: get_store_stats, list_store_domains, add_store_domain, check_store_domain, set_store_main_domain, and 29 more. Their descriptions and schemas cost roughly 6,526 tokens of context every time the server is loaded.
Does the MyDesigns MCP server require authentication?
No. We connected to MyDesigns without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the MyDesigns MCP server still maintained?
MyDesigns is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.