Skip to main content
Glama
devlimelabs

Lulu Print MCP Server

by devlimelabs

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 dev

Dockerのインストール

# 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認証情報を取得する

  1. https://developers.lulu.com/で Lulu 開発者アカウントにサインアップしてください。

  2. テストするには、 https://developers.sandbox.lulu.com/でサンドボックス アカウントを作成してください。

  3. APIキーページに移動します

  4. クライアントキーとクライアントシークレットをコピーします

2. 環境変数を設定する

# Create a configuration file
cp .env.example .env

Lulu 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=false

Claude 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 サーバーをカーソル構成ファイルに追加します。

  1. カーソル設定を開く( Cursor → Settings 、またはMacの場合はCmd+, )

  2. 機能セクションに移動する

  3. 「モデルコンテキストプロトコル」の設定を見つける

  4. 次の構成を追加します。

{
  "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 構成に追加します。

  1. プロジェクトディレクトリに.windsurf/config.jsonファイルを作成または編集します。

  2. 次の構成を追加します。

{
  "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_CHANGED

Webhook 送信リスト

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

説明

0850X1100BWSTDLW060UW444MNG

8.5インチ x 11インチの白黒標準リネンラップ。ネイビーのリネンとゴールドの箔を使用。

0600X0900FCSTDPB080CW444GXX

6インチ×9インチのフルカラー標準ペーパーバック(光沢カバー付き)

0700X1000FCPRECO060UC444MXX

7インチ×10インチのフルカラープレミアムコイル綴じ、マットカバー付き

0600X0900BWSTDPB060UW444MXX

6インチ×9インチの白黒標準ペーパーバック(マットカバー付き)

Lulu 価格計算ツールを使用すると、特定のニーズに合わせた SKU を生成できます。

サンドボックスでのテスト

テストに Lulu サンドボックス環境を使用するには:

  1. https://developers.sandbox.lulu.com/でサンドボックス アカウントを作成します。

  2. サンドボックスAPI認証情報を取得する

  3. .envファイルでLULU_USE_SANDBOX=true設定します。

  4. または、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 tools
calculate-print-job-costA

Calculate the cost of a print job without creating it

ParametersJSON Schema
NameRequiredDescriptionDefault
product_idYesLulu product ID
quantityYesNumber of copies

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

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 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.

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 ('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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
product_idYesLulu product ID

TDQS

B3.1/5.0
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. 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.

Conciseness5/5

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.

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 (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.

Parameters3/5

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.

Purpose4/5

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.

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 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.

  1. 2 tool updates
    • First observedcalculate-print-job-cost
    • First observedget-product-details

TDQS

B3.2/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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 npm
    GPL 2.0