TailorKit MCP es un potente framework de personalización de productos para comercio electrónico que permite a los comerciantes crear experiencias de personalización interactivas. Ofrece gestión de plantillas, control de capas e integración con Shopify para ofrecer productos personalizables con un mínimo esfuerzo de desarrollo.
Este servidor MCP (Protocolo de Contexto de Modelo) conecta a Claude y a otros asistentes de IA con la API de TailorKit, lo que les permite gestionar plantillas de productos personalizables para plataformas de comercio electrónico. Con TailorKit MCP, los asistentes de IA pueden crear, recuperar y manipular plantillas de productos y sus capas directamente mediante conversaciones en lenguaje natural.
Related MCP server: tray-mcp-server
get_list_templates
Obtenga una lista de plantillas con dominio de tienda
Entradas requeridas:
shopDomain (cadena): el dominio de la tienda que termina en .myshopify.com
Entradas opcionales:
limit (número, predeterminado: 5): número máximo de plantillas a devolver
page (número, predeterminado: 1): Número de página para paginación
sort (cadena, valor predeterminado: "updatedAt__desc"): El orden de clasificación
filter (cadena): cadena de filtro para la búsqueda de plantillas
Devoluciones: Listado de plantillas con sus detalles
get_detail_template
Obtenga información detallada sobre una plantilla específica
Entradas requeridas:
_id (cadena): El ID de la plantilla
shopDomain (cadena): el dominio de la tienda que termina en .myshopify.com
Devoluciones: Información detallada de la plantilla, incluidas capas y configuraciones.
create_template
Crear una nueva plantilla para una tienda
Entradas requeridas:
shopDomain (cadena): el dominio de la tienda que termina en .myshopify.com
name (cadena, predeterminado: "Nueva plantilla"): Nombre de la plantilla
dimension (objeto): Ancho, alto, unidad de medida y resolución
Entradas opcionales:
_id (cadena, formato: uuid): ID personalizado para la plantilla
layers (matriz): configuración inicial de capas
Devoluciones: Confirmación de creación de plantilla con ID de plantilla
get_list_layers_of_template
Obtener todas las capas para una plantilla específica
Entradas requeridas:
_id (cadena): El ID de la plantilla
shopDomain (cadena): el dominio de la tienda que termina en .myshopify.com
Devuelve: Lista de todas las capas en la plantilla con sus propiedades
Agregue lo siguiente a su claude_desktop_config.json :
{
"mcpServers": {
"tailorkit-mcp": {
"command": "node",
"args": ["path/to/your/dist/index.js"],
"env": {
"HOST": "https://your-api-host.com",
"ACCESS_TOKEN": "your-access-token"
}
}
}
}HOST : Obligatorio. La URL del host para la API de TailorKit.
ACCESS_TOKEN : Obligatorio. Su token de acceso a la API de TailorKit para autenticación.
Vaya a Settings -> Preferences -> Generate access token
npm install @sellersmith/tailorkit-mcpgit clone https://github.com/sellersmith/tailorkit-mcp.git
cd tailorkit-mcp
npm install
npm run build# Install dependencies
npm install
# Build the project
npm run build
# Run the server locally
node dist/index.jsEste servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.
Create a new template with shop domain
| Name | Required | Description | Default |
|---|---|---|---|
| _id | No | The id of the template | |
| dimension | No | The dimension of the template | |
| layers | No | The layers of the template | |
| name | Yes | The name of the template | New Template |
| shopDomain | Yes | The shop domain ends with .myshopify.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it's idempotent, error handling, or what happens on success/failure. For a creation tool with complex inputs, this is inadequate.
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, efficient sentence with no wasted words. However, it's too brief given the tool's complexity—it could benefit from 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?
For a creation tool with 5 parameters (including nested objects), no annotations, and no output schema, the description is incomplete. It doesn't explain the template's purpose, what happens after creation, or error cases, leaving significant gaps for the agent.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'shop domain' but doesn't explain parameter relationships or usage beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 the action ('Create a new template') and mentions the resource ('template'), but it's vague about what a template is and doesn't differentiate from sibling tools like 'get_list_templates' or 'get_detail_template'. It mentions 'with shop domain' but doesn't explain why that matters.
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 on when to use this tool versus alternatives like 'get_list_templates' for viewing templates. The description doesn't mention prerequisites, context, or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detail template with template id and shop domain
| Name | Required | Description | Default |
|---|---|---|---|
| _id | Yes | The id of the template | |
| shopDomain | Yes | The shop domain ends with .myshopify.com |
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 states the tool retrieves a template but doesn't describe what 'detail' includes, whether it's a read-only operation, potential error conditions, or the response format. This leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and parameters without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool that retrieves data. It doesn't explain what 'detail' entails, the return format, or any behavioral aspects like error handling. For a read operation with no structured output documentation, more context is needed.
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 mentions the two parameters ('template id and shop domain'), but the input schema already provides 100% coverage with clear descriptions for both. The description adds no additional meaning beyond what's in the schema, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 action ('Get detail template') and identifies the required resources ('template id and shop domain'), making the purpose understandable. However, it doesn't differentiate this tool from its sibling 'get_list_templates' (which presumably lists templates rather than retrieving details of a specific one), preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'get_list_templates' or 'create_template'. It mentions the required parameters but doesn't explain the context or prerequisites for invoking this tool, 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.
Get list layers of template with template id and shop domain
| Name | Required | Description | Default |
|---|---|---|---|
| _id | Yes | The id of the template | |
| shopDomain | Yes | The shop domain ends with .myshopify.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this is a read-only operation, potential side effects, error handling, or rate limits, leaving significant gaps for a tool that likely queries data.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating purpose from parameter mentions.
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 incomplete. It lacks details on return values (e.g., what 'layers' entail), error conditions, or behavioral traits, which are critical for a tool with two required parameters and likely data retrieval functionality.
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 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond what's in the schema (e.g., it repeats that template id and shop domain are needed without extra context), meeting the baseline for high coverage.
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 action ('Get list layers') and the resource ('template'), specifying it requires template id and shop domain. It distinguishes from siblings like 'get_detail_template' by focusing on layers rather than template details, but doesn't explicitly contrast with 'get_list_templates' which might list templates rather than layers.
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 on when to use this tool versus alternatives is provided. The description mentions required parameters but doesn't specify use cases, prerequisites, or exclusions compared to sibling tools like 'get_detail_template' or 'create_template'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list templates with shop domain
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | The filter | |
| limit | No | The limit of the templates | |
| page | No | The page number | |
| shopDomain | No | The shop domain ends with .myshopify.com | |
| sort | No | The sort order | updatedAt__desc |
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 mentions the required 'shop domain' context but fails to describe critical behaviors: whether this is a read-only operation, if it requires authentication, how pagination works with 'limit' and 'page', or what the return format looks like. For a list retrieval tool with zero annotation coverage, this leaves 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential context ('with shop domain'). Every part earns its place, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It lacks information on return values, error handling, authentication needs, and how parameters like 'filter' and 'sort' function. Without annotations or output schema, the agent has insufficient context to use the tool effectively beyond basic parameter passing.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond implying that 'shopDomain' is required (though it's not marked as required in the schema). It doesn't explain parameter interactions or provide additional context beyond what's in the schema, meeting the baseline for high coverage.
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 verb ('Get') and resource ('list templates'), making the purpose understandable. It specifies the required context ('with shop domain'), which helps differentiate it from generic template retrieval tools. However, it doesn't explicitly distinguish from sibling tools like 'get_detail_template' or 'get_list_layers_of_template', preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_detail_template' for single templates or 'create_template' for creation, nor does it specify prerequisites or exclusions. The agent must infer usage from the name and parameters alone.
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.0create_templateget_detail_templateget_list_layers_of_templateget_list_templatesScored across 4 tools
Each tool has a clearly distinct purpose: create_template for creation, get_detail_template for retrieving a single template's details, get_list_layers_of_template for listing layers within a template, and get_list_templates for listing all templates. There is no overlap in functionality, and an agent can easily distinguish between them based on their specific actions.
The naming follows a consistent verb_noun pattern with 'create', 'get_detail', 'get_list_layers_of', and 'get_list' as verbs, all using snake_case. However, there is a minor deviation: 'get_detail_template' uses 'detail' as an adjective, while others use 'list' as part of the noun phrase, but overall it remains readable and predictable.
With 4 tools, this is well-scoped for a template management server. Each tool serves a distinct and necessary function in the template lifecycle, from creation to retrieval and listing, making the count appropriate and efficient for the domain.
The toolset covers creation and retrieval (get_detail, get_list_templates, get_list_layers_of_template) but lacks update and delete operations for templates. This is a notable gap that could limit agent workflows, as users cannot modify or remove templates once created, though basic CRUD is partially covered.
Connect AI to store orders, products and inventory with scoped access and human approvals.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
Connect your AI assistant to Revensi OS agents, workflows, and business data.
Manage your Savanto store from your AI: catalog, content, prompts, and analytics, by chat.
