TailorKit MCP是一个强大的电商产品定制框架，帮助商家打造交互式个性化体验。它具备模板管理、层级控制和 Shopify 集成功能，能够以最小的开发工作量提供可定制的产品。
该 MCP（模型上下文协议）服务器将 Claude 和其他 AI 助手连接到 TailorKit API，使其能够管理电商平台的可定制产品模板。借助 TailorKit MCP，AI 助手可以直接通过自然语言对话创建、检索和操作产品模板及其层级。
Related MCP server: tray-mcp-server
get_list_templates
获取带有商店域名的模板列表
必需输入：
shopDomain （字符串）：以 .myshopify.com 结尾的商店域名
可选输入：
limit （数字，默认值：5）：返回的最大模板数量
page （数字，默认值：1）：分页的页码
sort （字符串，默认值：“updatedAt__desc”）：排序顺序
filter （字符串）：模板搜索的过滤字符串
返回：模板及其详细信息的列表
get_detail_template
获取有关特定模板的详细信息
必需输入：
_id （字符串）：模板的ID
shopDomain （字符串）：以 .myshopify.com 结尾的商店域名
返回：包括层和设置在内的详细模板信息
create_template
为商店创建新模板
必需输入：
shopDomain （字符串）：以 .myshopify.com 结尾的商店域名
name （字符串，默认值：“新模板”）：模板的名称
dimension （对象）：宽度、高度、测量单位和分辨率
可选输入：
_id （字符串，格式：uuid）：模板的自定义 ID
layers （数组）：初始层配置
返回：模板创建确认，带有模板 ID
get_list_layers_of_template
获取特定模板的所有层
必需输入：
_id （字符串）：模板的ID
shopDomain （字符串）：以 .myshopify.com 结尾的商店域名
返回：模板中所有层及其属性的列表
将以下内容添加到您的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 ：必需。您的 TailorKit API 的主机 URL。
ACCESS_TOKEN ：必需。用于身份验证的 TailorKit API 访问令牌。
转到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.js此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。
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.
