printful-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Catalog, file, sync product, mockup, and store tools are clearly separated. There is no overlap between tools like getProducts (catalog) and getSyncProducts (store products).
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern (e.g., getProducts, createSyncProduct, updateSyncVariant, deleteSyncProduct). All use camelCase with descriptive verbs, and even uploadFileFromUrl is predictable. No mixed naming conventions.
Tool Count4/5
23 tools is on the higher end but appropriate for the broad scope of Printful's API: catalog browsing, file management, product lifecycle, mockups, and store management. Each tool covers a distinct function, so the count feels justified rather than excessive.
Completeness4/5
The tool set covers the core workflow: browse catalog, upload designs, create/update/delete sync products and variants, generate mockups, and manage stores. Minor gaps exist, such as no file deletion or order management tools, but the primary product creation and management lifecycle is well covered.
Average 3.5/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states 'Update' without explaining permissions, idempotency, partial-update behavior, side effects on related entities, or error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the verb and resource. It avoids verbosity, though 'etc' is slightly lazy and could be more precise without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, all schema-documented) and sibling context, the description is minimally viable. However, the absence of annotations and any note about return values or side effects leaves the mutation behavior underspecified. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The description's mention of 'price, files' merely repeats parameter names and adds no new semantics beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a sync variant'), with examples of fields ('price, files'). It distinguishes from sibling read/delete tools like getSyncVariant and deleteSyncVariant. However, the 'etc' is vague and doesn't enumerate all possible fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like createSyncProduct or updateSyncProduct. There are no exclusions, prerequisites, or contextual hints beyond the basic 'Update' action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Delete a sync variant' without addressing irreversibility, permissions, side effects, or error conditions. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, and concise sentence that efficiently conveys the core purpose. However, it could have included additional context without becoming verbose, so it is effective but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a destructive operation, lacking any mention of permanence, requirements, or implications. With no annotations and no output schema, the description should provide more context to ensure safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameter. The description adds no extra meaning beyond what is already in the schema, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Delete') and the target resource ('sync variant'), making it distinct from sibling tools like getSyncVariant and updateSyncVariant. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or alternatives. The description only states the action, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. It only states 'Get list of all files' without mentioning pagination, status filtering, return format, or rate limits. The word 'all' is potentially misleading given the limit and offset parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with the verb and resource stated directly. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 optional params, no output schema), the description provides the basic purpose but lacks context about pagination semantics, what 'library' refers to, or how results are returned. It is minimally sufficient but not fully self-contained without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters (limit, offset, status) with descriptions. The tool description adds no extra meaning beyond the schema and does not clarify how 'all files' interacts with pagination, so it neither improves nor degrades the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and identifies the resource as 'files in your Printful library'. It distinguishes from getFile (singular) but does not explicitly differentiate from getPrintfiles or other list operations, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like getFile, getPrintfiles, or uploadFile. There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely states 'Get', which implies read-only, but does not describe return format, error handling (e.g., 404 on missing), authentication requirements, or any side effects. This is a minimal behavioral description with significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'Get a single sync variant', with no fluff or redundant information. It is front-loaded with the primary action and resource, making it highly efficient for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but minimal. It does not mention what a sync variant is or what the return value looks like, but for a simple getter this may be enough. However, the lack of output schema or behavioral context leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'sync_variant_id' with description 'Sync variant ID'. The description adds no additional parameter semantics beyond this. Since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single sync variant' uses a specific verb ('Get') and resource ('sync variant') and includes the modifier 'single' to indicate singular scope. It clearly distinguishes from plural siblings like getSyncProducts and from other resources like getSyncProduct, though it doesn't explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as getSyncProduct or getProductVariant. There is no mention of exclusions, prerequisites, or preferred use cases, leaving the agent to infer usage from naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does not disclose whether the fetch is server-side, whether the operation is synchronous, what constraints exist on the URL or file size, authentication requirements, or what the return value indicates. 'Add a file' is too opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear verb and object, front-loaded with the action and resource. It contains no wasted words and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool, the description states the core purpose and source, and the schema covers both parameters fully. However, the absence of any behavioral context, return semantics, or usage guidance leaves gaps that matter in practice, making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the description adds little beyond restating the URL source. The 'from a URL' phrase aligns with the 'url' parameter but provides no extra semantic depth, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and names the resource ('file to Printful library') with the source method ('from a URL'). It is clear and largely self-contained, but it does not explicitly differentiate from the sibling tool 'uploadFile', relying instead on the URL source to imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to prefer this tool over 'uploadFile' or any other file-related sibling, nor does it mention prerequisites, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Update', implying mutation, but does not mention required permissions, whether fields are partially updated, what happens to unspecified fields, or what the response will be. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. Every word contributes to stating the core purpose, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description fails to explain expected behavior beyond the basic update action. For a mutation tool with side effects, this is incomplete; it should mention what is updated, whether it partially updates, and what the response might be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the schema already documents parameter meanings. The description adds no extra parameter-level detail, and the schema's short descriptions are adequate, landing at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing sync product', using a specific verb ('Update') and resource ('sync product'). It distinguishes from sibling tools like createSyncProduct, deleteSyncProduct, and updateSyncVariant by indicating the exact operation and object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as createSyncProduct or updateSyncVariant. The description simply states what it does but gives no context, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Get info' without elaborating on what info is returned, whether the file must exist, or how errors are handled. This is a minimal but not misleading description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description gives minimal but sufficient context: it retrieves info about a previously uploaded file. However, it lacks details about return format or error conditions, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with the 'file_id' parameter described as 'The file ID'. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get info') and resource ('previously uploaded file'), making clear this is a singular retrieval operation. It distinguishes from the sibling 'getFiles' which likely lists files, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'getFiles' or 'uploadFile'. The phrase 'previously uploaded file' hints at a prerequisite but doesn't explicitly state exclusions or alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden but only states 'Get info'. It does not mention error handling, permissions, rate limits, or return format, providing minimal insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description is adequate but incomplete. It provides the core purpose but lacks usage guidance and behavioral transparency, which are needed for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a clear description for the variant_id parameter. The tool description adds no additional meaning beyond what the schema already documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get info about a specific product variant' clearly states the action (get) and resource (product variant), distinguishing it from sibling tools like getProduct and getSyncVariant. The specificity of 'a specific product variant' aligns with the singular variant_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as getProduct or getSyncVariant. The description does not mention any context, prerequisites, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action 'Switch to a different store' without explaining side effects (e.g., whether it changes session state, if it is reversible, or what happens on invalid store_id). This is a significant gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose and a key caveat. There is no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool it has a clear purpose, but it lacks important context such as what 'switching' entails (e.g., does it affect the current session?), what the expected return value is (no output schema), and how to obtain a valid store_id. The description is sparse and does not fully enable correct invocation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter store_id, which has a clear description. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a different store' clearly states the action and resource, and the parenthetical '(for accounts with multiple stores)' adds context. It distinguishes from sibling read-only tools like getStore and getStores, though it does not explicitly state that it changes the active store context for subsequent API calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'for accounts with multiple stores.' It implies when to use it, but does not mention alternatives or explicitly state when not to use it (e.g., accounts with a single store). This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose the destructive nature of the operation. It does not mention that deletion is permanent or irreversible, nor does it clarify any cascading effects on associated variants or other data. This is a significant gap for a delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the tool's purpose. Every word contributes, and there is no unnecessary content or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and no annotations, the description is too minimal. It omits important behavioral context such as irreversibility, result/return value, and any related side effects, leaving the agent with insufficient information to fully understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, including a description for the only parameter (sync_product_id). The tool description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and the target resource ('sync product'), and the phrase 'from your store' adds context. This distinguishes it from siblings like deleteSyncVariant and aligns with the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as deleteSyncVariant or updateSyncProduct. Usage is implied from the name and the sibling list, but no direct 'when to use' or 'when not to use' is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It claims to return 'all' sync products but does not mention pagination (despite limit/offset parameters), default filtering behavior, rate limits, or authentication needs. This ambiguity could lead to incorrect assumptions about the result set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word adds value, and the clarifying parenthetical 'your created products' is efficient and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks essential context for a list operation: it does not clarify that results are paginated, what the default page size is, or the meaning of 'all' given the status filter. There is no output schema to fill these gaps, making the description incomplete for confident tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds no additional parameter-specific detail, such as how limit/offset interact or the meaning of 'all' for the status filter. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get list'), the resource ('all sync products'), and adds clarifying context ('your created products') that distinguishes it from getProducts, which may include Printful's general catalog. This is specific and immediately actionable for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and purpose, but the description provides no explicit guidance on when to choose this over alternatives like getProducts or getSyncProduct, nor any exclusions or prerequisites. It lacks a clear 'when to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Get list of product categories', which implies a read operation but does not mention authentication, pagination, return format, or any potential side effects. This is minimal and lacks helpful context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence, front-loaded with the action and resource, with no wasted words. It is appropriately sized for a tool with no parameters and simple functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), but the description is minimal. It states the existence of a list but does not elaborate on the structure of categories, whether results are sorted, or any caveats like empty lists. While not inadequate for a basic get-list, it could provide more return-value context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema information to augment. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter details, which is appropriate. No additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'list of product categories'. It is distinct from all sibling tools, which focus on products, variants, files, sync operations, mockup tasks, and stores, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies its use when needing product categories, but there is no explicit context or exclusions, such as 'use getCategories for catalog browsing' or 'prefer getProducts for individual items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. The verb 'Get' clearly indicates a read-only retrieval operation, which is transparent and non-destructive. Yet it does not disclose details such as what 'available' means, whether the product must exist, or what the response contains, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of seven words, front-loaded with the verb and resource. Every word is necessary, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema, so the description is partially complete. It states the purpose and the required input, but it does not describe the return value format, pagination, or the meaning of 'available'. Without an output schema, the description should provide more detail about what the caller receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with product_id described as 'Product ID'. The description adds 'for a product' which reinforces the parameter's purpose but does not provide additional semantics beyond what the schema already states. The baseline of 3 applies because there is no meaningful value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves mockup templates for a product using the specific verb 'Get' and resource 'mockup templates'. It is distinguishable from sibling tools like getProduct or createMockupTask because no other sibling references mockup templates, though it does not explicitly compare itself to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a product' implies the tool is used when you have a product_id and need its mockup templates. However, it does not provide explicit guidance on when to use this tool versus alternatives, mention exclusions, or describe required prerequisites beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states what the tool returns, but does not disclose potential side effects (likely none for a getter), required permissions, output format, error behavior, or whether the result is a single object or list. This is a significant gap given the lack of annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, and lists the key info types in parentheses. It is concise with no filler or unnecessary words, earning high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately states the purpose and the kind of information returned. However, it does not specify whether the response is a single object or an array, nor cover edge cases like invalid product IDs or empty results. Given the absence of an output schema, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a description for product_id ('The product ID'), so the baseline is 3. The description adds no additional meaning about the parameter, but it does not need to compensate since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get printfile info') and the resource ('a product'), and further specifies the type of info returned (dimensions, DPI, placement areas). This distinguishes it from sibling tools like getProducts, getProduct, and getFile, which target different resources or use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving printfile details, providing clear context for when it would be used. However, there is no explicit guidance on when to use this tool versus alternatives such as getProductVariant or getFile, nor any mention of exclusions or prerequisites beyond the required product_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Get information' without disclosing whether it is read-only, what store is referenced, or any side effects. This adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no superfluous words, perfectly concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description is minimally adequate, but it lacks context about which store is returned (active store?), authentication requirements, and return format. Absence of output schema and annotations raises the burden, making a brief description sufficient only at a basic level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter details. The baseline of 4 applies as there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets information about the Printful store. The singular 'store' distinguishes it from sibling tool getStores (plural), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus getStores or changeStore. There is no mention of prerequisites, the active store context, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses that the tool returns a task ID, implying asynchronous generation, and mentions 'with your design' to indicate a dependency on prior file upload. However, it does not explain permission requirements, error conditions, or how to poll for completion. The task ID disclosure is useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences that immediately state the primary action and its key result (task ID). It avoids repeating schema details and contains no filler. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema with 100% coverage and no output schema, the description appropriately focuses on the essential return value (task ID) and the goal of generating mockups. It relies on the sibling getMockupTask for more detailed status/result information. While it could mention async behavior more explicitly, the task ID implicitly conveys that. Overall, it is adequately complete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 6 parameters, so the baseline is 3. The description adds minimal parameter meaning beyond saying 'with your design', which loosely references the files array. It does not elaborate on option_groups or variant_ids, but the schema already defines these clearly. The description does not compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Generate product mockup images with your design' and clarifies it returns a task ID for status checks. This clearly distinguishes it from sibling tools like getMockupTask (which retrieves task status) and getMockupTemplates (which lists templates). The purpose is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you need a design and want mockup images. It hints at the follow-up workflow by mentioning 'Returns a task ID to check status', but does not explicitly name the alternative getMockupTask or state when not to use this tool. The guidance is implicit rather than clearly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description conveys that this is a read operation (check/get) but does not explicitly state that it has no side effects, or disclose behavior such as possible statuses, error handling, or rate limits. With no annotations provided, the description carries the full burden but offers only basic behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence of 10 words, perfectly front-loaded with the action and resource, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema or annotations, the description adequately covers the purpose and expected result (status and URLs). It could benefit from mentioning what happens during task processing, but overall it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description of the single parameter (task_key, 'Task key from createMockupTask') at 100% coverage. The description adds no additional meaning about the parameter format or semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Check', 'get') and a clear resource ('mockup generation task'), and explicitly states the outcome (result URLs). This clearly distinguishes it from siblings like createMockupTask (creation) and getMockupTemplates (template listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after task creation via the phrase 'check status', but does not explicitly state when to use it versus alternatives, nor mention exclusions. The schema's parameter description hints at 'from createMockupTask', but that is not in the tool description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, and 'with all its variants' gives some behavioral context, but it does not disclose error behavior, permissions, or return format details beyond that. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the essential purpose without unnecessary words. Every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool, the description covers the core purpose and return scope ('all its variants'). It does not detail the output structure, but no output schema exists, and the tool's simplicity makes this acceptable. Slight gap: no mention of what happens if not found, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter 'sync_product_id' is already well described in the schema, including the '@external_id' option. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('sync product') and scope ('single' with 'all its variants'). It distinguishes itself from the plural sibling getSyncProducts and the more generic getProduct by specifying 'sync product' and 'single'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one sync product with variants, but it does not explicitly state when to choose this tool over siblings like getSyncProducts or getProduct. No exclusions or alternative guidance is provided, so it relies on the implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool uploads a file and returns a file ID for product creation, which is useful behavioral context. However, it omits details like permissions, file size limits, or side effects (e.g., file persists on Printful). This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word serves a purpose. It is concise and easy to parse without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema covers all parameters, and the description explains the return value's purpose despite no output schema. It lacks details on file formats or limits, but given its simplicity, the description is sufficiently complete for an agent to understand its role and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both file_path and type have descriptions). The description adds no extra parameter semantics beyond mentioning the upload and its return value, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Upload a design file (image) to Printful.' It also mentions the key outcome (returns file ID for creating products). However, it does not explicitly distinguish from the sibling tool uploadFileFromUrl, though the parameter schema clarifies the local file path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you have a design file and need a file ID for product creation. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over uploadFileFromUrl based on the local path requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds useful context that this creates a 'listing draft' (not a live product) and is scoped to the Printful store. However, it does not disclose side effects, permissions, rate limits, or what happens on success or failure, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no filler or repetition. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a complex nested variants structure, the schema provides excellent input coverage. However, there is no output schema and the description does not mention what the tool returns (e.g., the created product or ID), nor does it address any prerequisites beyond what the schema already notes. The description is adequate but lacks some completeness for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (name, variants, thumbnail, external_id) and their nested properties are already fully described in the schema. The description adds no parameter-specific information beyond the redundant mention of 'with variants.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new sync product with variants') and the specific resource ('sync product' in the Printful store), and clarifies it creates a 'listing draft,' distinguishing it from get/update/delete sync product tools and mockup creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: use this tool when creating a new sync product. It does not explicitly mention alternatives or exclusions, but the verb 'create' and resource name make the intended use obvious among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions that the tool returns 'all variants (sizes, colors)', which is a useful behavioral trait. However, it doesn't disclose whether the operation is read-only (though implied by 'Get'), any authentication requirements, or error behaviors. For a simple get-by-id operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose ('Get detailed info') and then specifies the scope. Every word adds value, with no wasted text or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one required parameter and no output schema. The description clearly states the tool's coverage ('including all variants'), which is sufficient for an agent to understand what to expect. It doesn't go into response format, but for such a simple get operation, the description is adequately complete. It slightly misses explaining when to prefer this over getProductVariant, but the name and description already hint at the distinction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the single parameter 'product_id' with a description 'The Printful product ID'. Since schema description coverage is 100%, the baseline is 3. The tool description adds no additional information about the parameter beyond what the schema already provides, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed info about a specific product including all variants (sizes, colors)'. It uses a specific verb ('Get') and resource ('specific product'), and explicitly distinguishes from sibling tools like 'getProducts' (plural) and 'getProductVariant' by emphasizing both a single product and its full variant set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need detailed information about one specific product and its variants. While it doesn't explicitly exclude alternatives, the phrasing 'specific product' and 'including all variants' provides clear context for choosing this over getProducts or getProductVariant. It lacks explicit when-not-to-use guidance, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions 'all printable products' suggesting a listing operation, but does not disclose pagination, response format, authentication requirements, or any edge-case behavior. It is adequate but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb 'Get' and the resource, with optional illustrative examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description provides sufficient context for basic use. It could benefit from clarifying that it lists catalog products as opposed to sync products, but sibling names help fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with category_id described as 'Filter by category ID'. The description does not add extra parameter semantics beyond the schema, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get list of all printable products in the Printful catalog' with concrete examples (t-shirts, mugs, posters). This distinguishes it from singular 'getProduct' and other sibling tools like 'getCategories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving catalog products, but does not explicitly state when to use this vs alternatives like getProduct (singular) or getSyncProducts (store products). Context is clear but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 behavioral disclosure. It only says 'Get list', which implies a read operation, but does not state that it has no side effects, whether authentication is required, or any rate limits or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool without an output schema, the description is adequate. It clearly says what is returned (list of stores) and the scope (linked to the account). However, it does not describe the return fields or any positional nuances, but the simplicity of the tool makes this less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline score is 4. The description adds no parameter information, which is fine since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list'), the resource ('all stores'), and the scope ('linked to your Printful account'). It distinguishes from siblings like getStore (singular) by explicitly indicating 'all stores'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it: to retrieve all stores linked to the account. However, it does not explicitly mention alternatives (e.g., getStore for a single store) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![printful-mcp MCP server](https://glama.ai/mcp/servers/Jasuni69/printful-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Jasuni69/printful-mcp)

Score Badge

Copy to your README.md:

[![printful-mcp MCP server](https://glama.ai/mcp/servers/Jasuni69/printful-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Jasuni69/printful-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jasuni69/printful-mcp'

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