Claude Desktop 및 기타 MCP 클라이언트를 통한 주문형 인쇄 서비스를 위한 Lulu Print API와의 통합을 제공하는 MCP(Model Context Protocol) 서버입니다.
책 및 기타 인쇄물에 대한 인쇄 작업을 만들고 관리합니다.
주문 생성부터 배송까지 주문 상태를 추적하세요
주문하기 전에 비용을 계산하세요
주문당 여러 라인 항목 지원
인쇄하기 전에 내부 PDF 파일을 검증하세요
치수 검사를 통해 표지 PDF 파일 검증
페이지 수를 기준으로 필요한 표지 크기를 계산합니다.
자세한 검증 상태 및 오류 보고 받기
사양에 따라 제품 비용을 계산합니다.
배송비와 세금 계산 포함
다양한 배송 레벨 지원(MAIL에서 EXPRESS까지)
자세한 비용 내역을 확인하세요
목적지별로 사용 가능한 배송 옵션을 검색합니다.
국제 배송 지원
표준 우편부터 익스프레스 배송까지 다양한 서비스 수준
인쇄 작업 상태 변경 구독
웹훅 엔드포인트 관리
웹훅 전달 테스트
웹훅 제출 내역 보기
Related MCP server: OpenPrints MCP
지엑스피1
# 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# 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-mcphttps://developers.lulu.com/ 에서 Lulu 개발자 계정에 가입하세요
테스트를 위해 https://developers.sandbox.lulu.com/ 에서 샌드박스 계정을 만드세요.
API 키 페이지로 이동하세요
클라이언트 키와 클라이언트 비밀번호를 복사하세요
# 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 서버를 추가하세요.
# 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"
}
}
}
}Windsurf 구성에 이 MCP 서버를 추가하세요:
프로젝트 디렉토리에서 .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)웹훅 구독 만들기:
create-webhook
url: Webhook endpoint URL
topics: Array of events (currently supports ["PRINT_JOB_STATUS_CHANGED"])모든 웹훅 구독 나열:
list-webhooks웹훅 세부 정보 받기:
get-webhook
id: Webhook ID웹훅 업데이트:
update-webhook
id: Webhook ID
url: New URL (optional)
topics: New topics (optional)
is_active: Enable/disable (optional)웹훅 삭제:
delete-webhook
id: Webhook ID테스트 웹훅 보내기:
test-webhook
id: Webhook ID
topic: PRINT_JOB_STATUS_CHANGED웹훅 전달 시도 목록:
list-webhook-submissions
webhook_id: Filter by webhook (optional)
page: Page number (optional)
page_size: Results per page (optional)Lulu는 27자로 구성된 SKU 시스템을 사용하여 제품을 식별합니다.
형식 : Trim Size + Color + Print Quality + Bind + Paper + PPI + Finish + Linen + Foil
상품코드 | 설명 |
| 네이비 리넨과 골드 호일이 들어간 8.5" x 11" 흑백 표준 리넨 랩 |
| 광택 커버가 있는 6" x 9" 풀컬러 표준 페이퍼백 |
| 매트 커버가 있는 7" x 10" 풀컬러 프리미엄 코일 바인딩 |
| 6" x 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 자격 증명에 필요한 권한이 있는지 확인하세요.
URL을 통해 PDF 파일에 공개적으로 액세스할 수 있는지 확인하세요.
Lulu 문서에서 파일 형식 요구 사항을 확인하세요.
페이지 수와 치수가 제품 사양과 일치하는지 확인하세요.
인터넷 연결을 확인하세요
방화벽 설정이 api.lulu.com에 대한 HTTPS 연결을 허용하는지 확인하세요.
자세한 요청/응답 로그를 보려면 디버그 모드를 활성화하세요.
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
MIT
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 |
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 specifications and details for a Lulu product
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Lulu product ID |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate-print-job-costget-product-detailsScored 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.
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.
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.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
