Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@printify-mcp-server Show me my recent orders."
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.
A Model Context Protocol server for the Printify API.
All 49 of Printify's published operations are reachable. Printify's API is entirely merchant-facing, so unlike most providers in this family there is nothing here an ordinary token cannot call — and the catalogue says so rather than quietly claiming a smaller surface.
MIT licensed.
npm install -g @nasdigitaluk/printify-mcpGet a token from Printify → My Profile → Connections → Personal Access Tokens.
{
"mcpServers": {
"printify": {
"command": "printify-mcp",
"env": {
"PRINTIFY_API_KEY": "your-token",
"PRINTIFY_SHOP_ID": "12345678"
}
}
}
}Related MCP server: OpenPrints MCP
Variable | |
| Required. |
| Optional but recommended. Nearly every route is scoped to a shop; set this and it is filled in whenever you leave it out. |
| Refuse anything that changes state. |
| Allow writes, refuse anything irreversible or chargeable. |
This is the thing that makes Printify different from the other servers in this family, and it shapes how the tools are classified.
destructive here does not mean "deletes something". It means irreversible or chargeable:
Operation | Why |
| Places a real order. |
| Same, expedited. |
| Commits an existing order to print. |
| Opens a chargeable support case. |
| Same. |
every | The ordinary meaning. |
Classifying order placement as a plain write would have made MCP_NO_DESTRUCTIVE useless to exactly the person it exists to protect. 8 of the 49 operations are destructive by this definition, and there is a test asserting each one.
printify_get_shipping_cost is a POST that changes nothing, so it is classified read — it is the call that tells you what an order will cost before you commit to it, and a read-only server should still be able to make it.
Nine tools cover 49 operations. Every tool description is paid for in the model's context window on every turn, so the common path gets purpose-built tools and everything else goes through one dispatcher.
Tool | |
| Browse the catalogue. Start here. |
| Call any operation by id. |
| Your shops and their ids. |
| Products in a shop. |
| One product in full. |
| Artwork into the media library. |
| Orders in a shop. |
| Mark a product published to its channel. |
| What an order would cost, before placing it. |
printify_call is declared destructive because it can reach a destructive operation. A read-only server has to refuse it outright rather than inspect the id after the fact.
Artwork must be a publicly reachable URL. Printify fetches it server-side, so a local file path cannot work — and the schema refuses file://, javascript: and anything with embedded credentials rather than letting it fail confusingly at the provider.
curl -o vendor/printify-openapi.json https://developers.printify.com/openapi.json
npm run generate
npm testThe coverage test compares the catalogue against the vendored spec, so an endpoint Printify adds fails the build rather than making this README untrue.
Printify declares every parameter by $ref into components.parameters. That broke the first version of the shared generator, which filtered on p.in === "path" — a $ref object has no in, so all of them were dropped and the catalogue claimed these operations took no path parameters at all.
It surfaced because the dispatcher refuses a path it cannot fully resolve and blames the catalogue rather than the caller. Without that guard, the first call would have gone out with a literal {shop_id} in the URL and come back as an opaque 404. The generator now resolves refs, and also takes path parameters from the route template as the authority, so an undeclared one cannot go missing.
npm test # 13 tests
PRINTIFY_API_KEY=x npm run smoke # real MCP over stdio@nasdigitaluk/mcp-server-core.
MIT.
Call any Printify operation by id. shop_id is filled in from PRINTIFY_SHOP_ID when you leave it out.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| params | No | ||
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It does disclose one useful behavior: shop_id is automatically filled from PRINTIFY_SHOP_ID when omitted. However, it does not disclose that this can invoke arbitrary operations including mutations, how errors surface, auth requirements, or any side effects.
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 two short sentences with no filler, and the most important purpose is front-loaded. The shop_id note is valuable and earns its place. It loses one point because the phrasing 'any Printify operation' is vague and could be more informative without much extra length.
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?
For a generic operation-calling tool with no annotations, no output schema, and fully undocumented body/params, two sentences are not enough. Missing guidance includes how operation IDs are discovered, how body and params map to a specific operation, what the response looks like, and whether the call is safe or mutating.
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 description coverage is 0%, so the description must compensate. It adds meaning to operation_id as the operation identifier and explains the shop_id fallback, which is genuinely useful beyond the schema. But body and params remain completely unexplained in both schema and description, leaving the agent without enough information to construct a valid call.
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 states a clear verb ('call') and a resource ('any Printify operation') identified by operation_id. It is not a tautology and does distinguish itself as a generic dispatcher from the specific sibling tools, though 'any operation' is broad and does not name the siblings explicitly.
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?
There is no guidance on when to use this tool versus the many sibling tools like printify_list_orders or printify_get_product. 'Call any Printify operation' implies broad use but does not explain when the generic dispatcher is preferred over specialized operations, nor does it mention the relationship to printify_list_operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One product in full, including variants, images and print areas.
| Name | Required | Description | Default |
|---|---|---|---|
| shop_id | Yes | Your shop id. printify_get_shops lists them. | |
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It communicates the response content (variants, images, print areas) and the verb 'get' implies a read operation, but it does not explicitly state that there are no side effects, auth requirements, or error behaviors. This is adequate but not rich.
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?
A single sentence that immediately communicates the tool's purpose and key return fields. No filler, no repetition, and every word contributes value.
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 description covers the main return contents but, given no output schema, it does not fully specify the return structure. It also omits guidance on how to obtain or validate product_id and does not explicitly frame when to use this tool versus list_products. For a simple two-parameter GET tool this is close to sufficient but has notable 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?
Schema description coverage is only 50%: shop_id is described, but product_id only has minLength. The tool description adds no parameter-specific meaning, failing to explain that product_id likely comes from list_products or how to identify it. The description does not compensate for the missing product_id schema 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 retrieves one product in full, including variants, images, and print areas. The phrase 'One product in full' distinguishes it from sibling printify_list_products, which handles multiple products.
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 gives clear context that this is for retrieving a single product's complete details, implying it should be used over list_products when the full product object is needed. However, it does not explicitly mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What an order would cost to ship, before placing it. Worth calling first — placing an order is chargeable and cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| shop_id | Yes | Your shop id. printify_get_shops lists them. | |
| address_to | Yes | ||
| line_items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any side effects or behaviors of calling the tool itself. It only mentions that placing an order is chargeable, which is about the order, not the tool. Since no annotations are provided, the description carries the full burden, and it fails to state whether the tool is read-only, non-destructive, or has any other behavioral implications.
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 short and to the point, but the first sentence is awkward and grammatically unclear ('What an order would ship'). While concise in length, the structure could be improved for clarity. It is not overly verbose, but the phrasing detracts from its effectiveness.
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 description provides some context by mentioning that placing an order is chargeable and cannot be undone, which helps justify the tool's use. However, it does not describe what the tool returns (e.g., a shipping cost value) or any other details that would help an agent understand the full scope. Given there is no output schema, some explanation of the output would be beneficial. Overall, it is minimally complete.
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 has three parameters, but only shop_id has a description ('Your shop id. printify_get_shops lists them.'), which is helpful. However, address_to and line_items have no descriptions, and the tool description itself adds no additional meaning to these parameters. With only 33% schema coverage, the semantics are insufficiently explained.
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 states 'What an order would ship, before placing it', which is ambiguous and poorly worded. It implies a shipping cost estimate but does not explicitly say 'cost to ship'. The context about placing an order clarifies its purpose somewhat, but the first sentence lacks precision.
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 says 'Worth calling first — placing an order is chargeable and cannot be undone', which clearly indicates the tool should be used before placing an order. This provides a concrete usage scenario, though it does not explicitly contrast with alternative tools. The guidance is practical and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The shops connected to this Printify account, with their ids.
| 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 carries the full burden of behavioral disclosure, but it only describes the return content, not the operation's behavior. It does not mention read-only safety, authentication, pagination, failure modes, or response format beyond the mention of ids.
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 short sentence with no filler, and it front-loads the essential information about what the tool returns. It could be slightly more polished with an explicit verb, but it is economically written.
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?
For a zero-parameter read operation with no output schema, the description is mostly complete: it states the scope ('connected to this Printify account') and the key return field ('ids'). It omits deeper behavioral or formatting details, but nothing critical is missing for an agent to select and call this simple 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?
The tool has zero parameters and an empty input schema, so parameter documentation is not required. The description's mention of 'ids' gives a useful hint about the response shape, and there is nothing left unclear about invocation arguments.
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 identifies the resource ('shops connected to this Printify account') and the payload ('their ids'), which distinguishes it from sibling tools focused on products, orders, shipping, and uploads. It lacks an explicit verb like 'list' or 'retrieve', so it is slightly less direct than an imperative description.
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?
No guidance is provided about when to use this tool versus alternatives such as printify_list_products or printify_list_orders. There are no stated exclusions, prerequisites, or sibling routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse all 49 operations in the Printify API. Every one is reachable — Printify's API is entirely merchant-facing, so unlike most providers there is nothing here an ordinary token cannot call. Use this to find an operation id for printify_call.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filter by id, path, tag or summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the API is merchant-facing and that all operations are reachable with an ordinary token, adding meaningful auth/permission context. It could mention more about the output format, but the essentials are covered.
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 concise and front-loaded, with the main purpose in the first sentence and the usage guidance in the last. One of the sentences ('Printify's API is entirely merchant-facing...') is contextual but earns its place by clarifying reachability and token permissions.
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?
For a simple listing tool with one optional parameter and no output schema, the description provides adequate context: what the tool does, how it relates to printify_call, and that all operations are accessible. It could be more explicit about what the returned entries look like, but the core calling scenario is well covered.
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 already provides 100% coverage with a clear description for the single optional 'search' parameter. The description adds general context about finding an operation id but does not need to re-explain parameter semantics. Baseline 3 is appropriate.
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 states a specific verb ('Browse'), the resource (all 49 operations in the Printify API), and clearly explains its role as a discovery tool for finding operation ids to use with printify_call. This clearly distinguishes it from the sibling operation tools.
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 gives clear context that this is the intended tool for browsing available operations and specifically instructs the agent to use it to find an operation id for printify_call. It does not explicitly state when not to use it, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orders in a shop, most recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| status | No | Filter by Printify order status. | |
| shop_id | Yes | Your shop id. printify_get_shops lists them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It does disclose one meaningful behavior: results are ordered 'most recent first'. However, it does not mention pagination behavior, return shape, or any caveats beyond the ordering trait, leaving gaps in transparency.
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 very short and front-loads the resource and ordering, with no filler or redundant statements. It is efficient, but it is telegraphic and could benefit from a verb or slightly more context without becoming verbose.
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?
With four parameters, no annotations, and no output schema, the description is too sparse to be fully contextual. It only states the resource and sort order, omitting pagination semantics, status filtering intent, output expectations, and how this tool relates to sibling order/list tools.
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 description adds no parameter-level meaning; it does not explain page, limit, status, or shop_id beyond what the schema already says. Since schema description coverage is only 50%, the description needed to compensate for the undocumented page and limit parameters but does not.
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 identifies the resource ('orders'), scopes it to 'a shop', and specifies the ordering ('most recent first'), which makes the core operation clear. It lacks an explicit verb like 'list' or 'retrieve', but the tool name and phrasing imply listing. It is distinguishable from sibling list tools by naming the 'orders' resource.
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 gives no guidance on when to use this tool versus alternatives such as printify_list_products or printify_list_operations. It does not mention whether this is the default order lookup or when filtering by status would be appropriate. Usage context is only weakly implied by 'Orders in a shop'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Products in a shop, paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| shop_id | Yes | Your shop id. printify_get_shops lists them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It adds only 'paginated'; it does not mention authentication, read-only status, response shape, error behavior, or pagination semantics. This is minimal disclosure for an unannotated tool.
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 extremely concise with no filler or repetition. The core facts—resource, scope, and pagination—are front-loaded in a single short phrase.
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 annotations and no output schema, the description is too thin for an agent to confidently invoke the tool. Missing context includes what a product object looks like, how pagination works, how to obtain a shop_id, and which sibling tools are preferable in different situations.
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 description coverage is only 33%, and the description does not compensate. The 'paginated' hint vaguely relates to page and limit, but the description explains none of the parameters beyond what the schema already names.
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 identifies the resource ('products') and scope ('in a shop') and hints at behavior ('paginated'). It distinguishes the tool from siblings like printify_get_product by plurality, though it lacks an explicit verb and doesn't name alternatives.
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?
No guidance is given about when to use this tool versus siblings such as printify_get_product or printify_list_orders. The description states only what the tool returns, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a product as published to its connected sales channel. Note this tells Printify the product is live; the storefront itself is updated by whatever integration owns that channel.
| Name | Required | Description | Default |
|---|---|---|---|
| shop_id | Yes | Your shop id. printify_get_shops lists them. | |
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. The note explicitly discloses that Printify is only told the product is live and that the storefront itself is updated by the channel's integration owner, which is a valuable non-obvious nuance. It does not cover auth, idempotency, or error behavior, but the most misleading interpretation is directly addressed.
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 two concise sentences with no filler. The core action is front-loaded, and the clarifying caveat about the storefront update follows immediately, making the structure efficient and easy to parse.
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?
For a state-changing tool with no annotations and no output schema, the description covers the essential purpose and a key limitation. However, it omits prerequisites such as the product needing to be connected to the sales channel and does not explain how to obtain or validate product_id, which leaves some practical invocation 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?
Schema description coverage is 50%: shop_id is documented in the schema, but product_id only has minLength and no semantic description. The tool description adds no parameter-level meaning; it merely restates the 'product' concept already present in the tool name. The missing product_id guidance is not compensated elsewhere.
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 states a specific action ('Mark a product as published') against a clear resource ('its connected sales channel') and adds a clarifying note that this is a Printify status signal, not a storefront update. This distinguishes it from the sibling listing/reading tools such as printify_list_products and printify_get_product.
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 gives useful context: the tool is used to mark a product live on its connected sales channel. However, it does not explicitly state when to prefer this tool over alternatives, mention exclusions, or name a sibling fallback, so the usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload artwork to the Printify media library so it can be placed on a product. Takes a publicly reachable URL — Printify fetches it server-side, so a local file path will not work.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Publicly reachable URL of the image. | |
| file_name | Yes | Name to store it under, e.g. design.png. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key server-side behavior: Printify fetches the image from the provided URL, which is why local paths fail. This goes beyond the schema by explaining the underlying mechanism. It does not mention overwrite behavior or return values, but for a simple upload tool the critical failure mode is disclosed.
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?
Two sentences, front-loaded with the tool's purpose, and the second sentence delivers the key constraint. Every word earns its place with no redundancy or filler.
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?
For a two-parameter upload tool with no output schema or annotations, the description covers the essential workflow: upload to media library for later product placement, and the URL requirement. It does not describe the return value or how to reference the uploaded image, but the core invocation knowledge is complete enough for an agent to make a correct call.
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%, so the schema already documents both parameters. The description adds meaning to the 'url' parameter by explaining why it must be publicly reachable — Printify fetches it server-side — and explicitly warns against local paths. This is a meaningful addition beyond the schema's own field descriptions.
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 states a specific verb and resource: 'Upload artwork to the Printify media library so it can be placed on a product.' This clearly differentiates the tool from its siblings, which are mostly get/list/publish operations. No other sibling handles uploading media, so the purpose is unmistakable.
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 gives clear context: upload artwork before placing it on a product, and use a publicly reachable URL. It also provides an explicit exclusion by warning that 'a local file path will not work.' However, it does not explicitly name alternative tools or state when not to use this tool beyond the URL limitation.
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.
v1.0.0printify_callprintify_get_productprintify_get_shipping_costprintify_get_shopsprintify_list_operationsprintify_list_ordersprintify_list_productsprintify_publish_productprintify_upload_imageScored across 9 tools
Most tools map cleanly to distinct actions such as shipping quotes, image upload, product retrieval, and order listing. printify_call and printify_list_operations form a clear discovery-plus-execution pair, but printify_call can technically overlap with every dedicated tool, creating mild ambiguity.
All tools consistently use a printify_ prefix with snake_case verb_noun names, such as list_products, get_product, upload_image, and publish_product. The sole outlier, printify_call, is still verb-first and fits the overall pattern well.
Nine tools is a well-scoped count for this server's purpose. It covers shops, products, orders, shipping, image upload, publishing, and includes a generic API call mechanism without feeling bloated.
Core read operations and several key actions are provided as first-class tools, while all 49 API operations are reachable through printify_list_operations and printify_call. The main gap is that a high-value action like creating an order lacks a dedicated wrapper, though it can be worked around through the generic call path.
Print-on-demand fulfillment: manage orders, catalog and account from AI clients. Writes ask first.
Print-on-demand catalog, listings, and fulfillment for AI agents.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
Read shops, catalog blueprints, print providers, products and orders; create and publish products.
