Lulu Print MCP Server
Lulu Print MCP サーバー
Claude Desktop やその他の MCP クライアントを通じてオンデマンド印刷サービス用の Lulu Print API との統合を提供するモデル コンテキスト プロトコル (MCP) サーバー。
特徴
📚 印刷ジョブ管理
書籍やその他の印刷物の印刷ジョブの作成と管理
注文の作成から配送までのステータスを追跡
注文前にコストを計算する
注文ごとに複数の明細項目をサポート
📄 ファイル検証
印刷前に内部PDFファイルを検証する
寸法チェックで表紙PDFファイルを検証
ページ数に基づいて必要な表紙の寸法を計算する
詳細な検証ステータスとエラーレポートを取得する
💰 コスト計算
仕様に基づいて製品コストを計算する
送料と税金の計算を含める
さまざまな配送レベル(メール便から速達便まで)をサポート
詳細なコストの内訳を取得する
🚚 配送管理
目的地別に利用可能な配送オプションを取得する
国際配送のサポート
通常郵便から速達便まで、さまざまなサービスレベル
🔔 ウェブフック
印刷ジョブのステータス変更を購読する
Webhookエンドポイントを管理する
Webhook配信のテスト
Webhook の送信履歴を表示する
Related MCP server: OpenPrints MCP
インストール
グローバルインストール
# Install the package globally
npm install -g @devlimelabs/lulu-print-mcp
# Start the server
lulu-print-mcp地域開発
# Clone the repository
git clone https://github.com/devlimelabs/lulu-print-mcp.git
cd lulu-print-mcp
# Install dependencies
npm install
# Set up development environment
npm run setup:dev
# Start the development server
npm run devDockerのインストール
# Build and run with Docker Compose
docker-compose up -d
# Or build and run the Docker image directly
docker build -t lulu-print-mcp .
docker run -p 3000:3000 lulu-print-mcp構成
1. Lulu API認証情報を取得する
https://developers.lulu.com/で Lulu 開発者アカウントにサインアップしてください。
テストするには、 https://developers.sandbox.lulu.com/でサンドボックス アカウントを作成してください。
APIキーページに移動します
クライアントキーとクライアントシークレットをコピーします
2. 環境変数を設定する
# Create a configuration file
cp .env.example .envLulu API 資格情報を使用して.envファイルを編集します。
# Required: Your Lulu API credentials
LULU_CLIENT_KEY=your_client_key_here
LULU_CLIENT_SECRET=your_client_secret_here
# Optional: API endpoints (defaults are provided)
LULU_API_URL=https://api.lulu.com
LULU_SANDBOX_API_URL=https://api.sandbox.lulu.com
LULU_AUTH_URL=https://api.lulu.com/auth/realms/glasstree/protocol/openid-connect/token
LULU_SANDBOX_AUTH_URL=https://api.sandbox.lulu.com/auth/realms/glasstree/protocol/openid-connect/token
# Use sandbox environment for testing (default: false)
LULU_USE_SANDBOX=false
# Enable debug logging (default: false)
DEBUG=falseClaude Desktopでの使用
この MCP サーバーを Claude Desktop 構成ファイルに追加します。
# Run the Claude Desktop setup script
npm run setup:claude指示に従ってClaude Desktopの設定ファイルを更新してください。スクリプトは次のような設定ファイルを生成します。
{
"mcpServers": {
"lulu-print": {
"command": "lulu-print-mcp",
"env": {
"LULU_CLIENT_KEY": "your_client_key",
"LULU_CLIENT_SECRET": "your_client_secret"
}
}
}
}カーソルとの使用
この MCP サーバーをカーソル構成ファイルに追加します。
カーソル設定を開く(
Cursor → Settings、またはMacの場合はCmd+,)機能セクションに移動する
「モデルコンテキストプロトコル」の設定を見つける
次の構成を追加します。
{
"mcpServers": {
"lulu-print": {
"command": "node",
"args": ["/path/to/global/lulu-print-mcp/dist/index.js"],
"env": {
"LULU_CLIENT_KEY": "your_client_key",
"LULU_CLIENT_SECRET": "your_client_secret"
}
}
}
}またはグローバルにインストールされている場合:
{
"mcpServers": {
"lulu-print": {
"command": "lulu-print-mcp",
"env": {
"LULU_CLIENT_KEY": "your_client_key",
"LULU_CLIENT_SECRET": "your_client_secret"
}
}
}
}ウィンドサーフィンでの使用
この MCP サーバーを Windsurf 構成に追加します。
プロジェクトディレクトリに
.windsurf/config.jsonファイルを作成または編集します。次の構成を追加します。
{
"mcpServers": {
"lulu-print": {
"command": "lulu-print-mcp",
"env": {
"LULU_CLIENT_KEY": "your_client_key",
"LULU_CLIENT_SECRET": "your_client_secret"
}
}
}
}Windsurf を使用した開発セットアップの場合:
{
"mcpServers": {
"lulu-print": {
"command": "tsx",
"args": ["src/index.ts"],
"cwd": "/path/to/lulu-print-mcp",
"env": {
"LULU_CLIENT_KEY": "your_client_key",
"LULU_CLIENT_SECRET": "your_client_secret"
}
}
}
}利用可能なツール
コスト計算
印刷ジョブのコストを計算する
印刷ジョブを作成せずにコストを計算します。
calculate-print-job-cost
line_items: Array of items to price
- pod_package_id: Product SKU (e.g., "0600X0900BWSTDPB060UW444MXX")
- page_count: Number of pages
- quantity: Number of copies
shipping_address: Delivery address
- street1: Street address
- city: City name
- country_code: 2-letter ISO country code
- postcode: Postal code
- phone_number: Contact phone
shipping_option: MAIL | PRIORITY_MAIL | GROUND | EXPEDITED | EXPRESS印刷ジョブ管理
印刷ジョブの作成
新しい印刷ジョブ注文を作成します。
create-print-job
line_items: Array of books to print
- title: Book title
- cover_url: URL to cover PDF
- interior_url: URL to interior PDF
- pod_package_id: Product SKU
- quantity: Number of copies
shipping_address: Delivery address
- name: Recipient name
- street1: Street address
- city: City
- country_code: 2-letter ISO code
- postcode: Postal code
- phone_number: Phone
contact_email: Email for order communication
shipping_level: MAIL | PRIORITY_MAIL | GROUND | EXPEDITED | EXPRESS
external_id: Your order reference (optional)印刷ジョブの一覧
オプションのフィルターを使用して印刷ジョブを一覧表示します。
list-print-jobs
page: Page number (optional)
page_size: Results per page (optional)
status: Filter by status (optional)
created_after: Filter by creation date (optional)
created_before: Filter by creation date (optional)印刷ジョブの取得
特定の印刷ジョブの詳細を取得します。
get-print-job
id: Print job ID印刷ジョブの更新
印刷ジョブを更新する(支払い前のみ):
update-print-job
id: Print job ID
external_id: New reference (optional)
contact_email: New email (optional)印刷ジョブのキャンセル
印刷ジョブをキャンセルする(未払いの場合のみ):
cancel-print-job
id: Print job ID印刷ジョブのステータスを取得する
印刷ジョブの現在のステータスを取得します。
get-print-job-status
id: Print job ID印刷ジョブのコストを取得する
印刷ジョブの詳細なコストを取得します。
get-print-job-costs
id: Print job ID印刷ジョブの統計情報を取得する
一定期間にわたる印刷ジョブの統計を取得します。
get-print-job-statistics
start_date: Start date (YYYY-MM-DD) (optional)
end_date: End date (YYYY-MM-DD) (optional)
group_by: DAY | WEEK | MONTH (optional)ファイル検証
内部ファイルの検証
内部 PDF ファイルを検証します。
validate-interior-file
file_url: URL to interior PDF
pod_package_id: Product SKU (optional, for normalization)内部検証の取得
検証ステータスを確認します:
get-interior-validation
validation_id: ID from validate-interior-fileカバー寸法を計算する
必要なカバー寸法を計算します。
calculate-cover-dimensions
pod_package_id: Product SKU
page_count: Number of interior pages
unit: IN | MM | PT (optional, default: PT)カバーファイルの検証
表紙の PDF ファイルを検証します。
validate-cover-file
file_url: URL to cover PDF
pod_package_id: Product SKU
page_count: Number of interior pagesカバー検証を取得する
カバー検証ステータスを確認します:
get-cover-validation
validation_id: ID from validate-cover-file配送
配送オプションを取得する
利用可能な配送オプションを取得します:
get-shipping-options
country_code: 2-letter ISO country code
state_code: State/province code (optional)
quantity: Number of items (optional)
pod_package_id: Product SKU (optional)
page_count: Number of pages (optional)
level: Filter by specific level (optional)ウェブフック
ウェブフックの作成
Webhook サブスクリプションを作成します。
create-webhook
url: Webhook endpoint URL
topics: Array of events (currently supports ["PRINT_JOB_STATUS_CHANGED"])ウェブフック一覧
すべての Webhook サブスクリプションを一覧表示します。
list-webhooksウェブフックを取得する
Webhook の詳細を取得します。
get-webhook
id: Webhook ID更新ウェブフック
Webhook を更新します。
update-webhook
id: Webhook ID
url: New URL (optional)
topics: New topics (optional)
is_active: Enable/disable (optional)ウェブフックの削除
Webhook を削除します。
delete-webhook
id: Webhook IDテストウェブフック
テスト Webhook を送信します。
test-webhook
id: Webhook ID
topic: PRINT_JOB_STATUS_CHANGEDWebhook 送信リスト
Webhook 配信の試行を一覧表示します。
list-webhook-submissions
webhook_id: Filter by webhook (optional)
page: Page number (optional)
page_size: Results per page (optional)Lulu製品SKU
Lulu では、製品を識別すべく 27 文字の SKU システムを使用しています。
フォーマット: Trim Size + Color + Print Quality + Bind + Paper + PPI + Finish + Linen + Foil
一般的な例
SKU | 説明 |
| 8.5インチ x 11インチの白黒標準リネンラップ。ネイビーのリネンとゴールドの箔を使用。 |
| 6インチ×9インチのフルカラー標準ペーパーバック(光沢カバー付き) |
| 7インチ×10インチのフルカラープレミアムコイル綴じ、マットカバー付き |
| 6インチ×9インチの白黒標準ペーパーバック(マットカバー付き) |
Lulu 価格計算ツールを使用すると、特定のニーズに合わせた SKU を生成できます。
サンドボックスでのテスト
テストに Lulu サンドボックス環境を使用するには:
https://developers.sandbox.lulu.com/でサンドボックス アカウントを作成します。
サンドボックスAPI認証情報を取得する
.envファイルでLULU_USE_SANDBOX=true設定します。または、CLIを実行するときに
--sandboxフラグを使用します:lulu-print-mcp --sandbox
サンドボックスモードの場合:
支払いにはテスト用のクレジットカード番号を使用する
注文は実際の生産には送られない
開発とテストに最適
コマンドラインオプション
lulu-print-mcp [options]
Options:
-s, --sandbox Use Lulu sandbox environment instead of production
-d, --debug Enable debug logging
-h, --help Display help
-V, --version Display versionトラブルシューティング
認証の問題
クライアントキーとシークレットが正しいことを確認してください
適切な環境を使用しているか確認する(本番環境とサンドボックス環境)
API認証情報に必要な権限があることを確認する
ファイル検証エラー
PDFファイルがURL経由で公開されていることを確認する
Luluのドキュメントでファイル形式の要件を確認してください
ページ数と寸法が製品仕様と一致していることを確認します
ネットワークの問題
インターネット接続を確認してください
ファイアウォール設定でapi.lulu.comへのHTTPS接続が許可されていることを確認します。
詳細なリクエスト/レスポンスログを表示するにはデバッグモードを有効にします
貢献
貢献を歓迎します!お気軽にプルリクエストを送信してください。
ライセンス
マサチューセッツ工科大学
Available Tools
2 toolscalculate-print-job-costA
Calculate the cost of a print job without creating it
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Lulu product ID | |
| quantity | Yes | Number of copies |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly indicates this is a read-only calculation tool (not creating anything), which is helpful. However, it doesn't mention potential limitations like rate limits, authentication requirements, or what specific cost components are included in the calculation.
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 communicates the essential purpose without any wasted words. It's appropriately sized for a simple calculation tool and front-loads the key information.
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 2-parameter calculation tool with no annotations and no output schema, the description provides adequate but minimal context. It clearly states the purpose but doesn't explain what the output looks like (cost format, currency, breakdown) or any prerequisites for successful calculation.
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 fully documents both parameters. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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 specific action ('calculate the cost') and resource ('print job'), and explicitly distinguishes it from the alternative action of creating a print job. This provides excellent clarity about what the tool does and what it doesn't do.
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 clear context about when to use this tool ('without creating it'), which implicitly suggests it's for cost estimation before actual creation. However, it doesn't explicitly mention when NOT to use it or provide specific alternatives beyond the implied contrast with creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-product-detailsB
Get specifications and details for a Lulu product
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Lulu product ID |
TDQS
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. The description states it 'gets' details, implying a read-only operation, but doesn't clarify permissions, rate limits, error conditions, or what 'specifications and details' includes. For a tool with zero annotation coverage, this is insufficient 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.
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 without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness.
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 low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format. Without annotations or output schema, the agent must rely heavily on the description, which is incomplete for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'product_id' documented as 'Lulu product ID'. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('specifications and details for a Lulu product'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'calculate-print-job-cost', which appears unrelated but could potentially overlap in product context. The description is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. With only one sibling tool that seems unrelated (cost calculation), the lack of explicit usage guidelines leaves the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
calculate-print-job-cost - First observed
get-product-details
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one calculates costs for print jobs, while the other retrieves product specifications. There is no overlap in functionality, making it impossible for an agent to confuse them.
Both tools use a verb-object naming pattern, but they mix conventions: 'calculate-print-job-cost' uses kebab-case, while 'get-product-details' uses hyphenation inconsistently with the first. The verbs 'calculate' and 'get' are clear but not perfectly aligned in style.
With only two tools, the server feels thin for a print service domain. It lacks essential operations like creating print jobs, managing orders, or handling payments, which are core to such a service. The count is too low for the apparent scope.
The tool surface is severely incomplete for a print service. It covers cost calculation and product details but misses critical operations such as job creation, order submission, status tracking, and payment processing, leaving significant gaps that will cause agent failures.
Maintenance
Related MCP Connectors
Furgonetka MCP Server is an extension for LLMs (such as Claude) that integrates AI assistants with Poland's most popular courier brokerage platform. The server enables models to interact directly with services from various couriers (including InPost, DPD, DHL, UPS, and Poczta Polska) through a single, unified interface. With this integration, your AI stops just "writing about logistics" and starts actually managing it.
Publish and schedule videos to TikTok, YouTube Shorts, Instagram, Facebook, LinkedIn, Pinterest, Bluesky, Threads and X from Claude, Cursor or any MCP client. Upload once, post everywhere, track views in unified analytics, and retry failed posts. Official platform APIs only, free plan available. Docs: https://docs.multi-upload-tool.com/mcp
Connect Amazon Seller Central to Claude or ChatGPT via MCP. Orders, inventory, pricing, fees, FBA.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
Related MCP Servers
- AlicenseAqualityDmaintenanceConnects Printful's print-on-demand API to AI assistants like Claude and Cursor to automate business operations. It enables users to browse catalogs, manage orders, generate mockups, and calculate shipping rates through natural language.1930MIT

OpenPrints MCPofficial
AlicenseNot gradedqualityDmaintenanceEnables AI agents to browse products, upload designs, place print orders, track shipments, and manage account balance via natural language.14 npmMIT- AlicenseNot gradedqualityDmaintenanceEnables users to connect Claude with various 3D printer management systems, allowing tasks like printer status monitoring, file management, print job control, and STL file manipulation.186 npmGPL 2.0
- FlicenseNot gradedqualityCmaintenanceEnables Claude to create, update, and publish print-on-demand products on Printify directly from chat, including managing shops, products, and orders.-