TailorKit MCPは、eコマース向けの強力な製品カスタマイズフレームワークです。これにより、マーチャントはインタラクティブなパーソナライゼーションエクスペリエンスを構築できます。テンプレート管理、レイヤーコントロール、Shopifyとの連携機能を備え、最小限の開発労力でカスタマイズ可能な製品を提供できます。
このMCP（モデルコンテキストプロトコル）サーバーは、ClaudeをはじめとするAIアシスタントをTailorKit APIに接続し、eコマースプラットフォーム向けのカスタマイズ可能な商品テンプレートの管理を可能にします。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 (文字列、デフォルト: "New Template"): テンプレートの名前
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.
