lulu-print-mcp

Create webhook

create_webhook

Subscribe a URL to Lulu events so Lulu POSTs updates, including print job status changes when an order changes status, to that endpoint.

Instructions

Subscribe a URL to Lulu events. Lulu then POSTs to the URL whenever a subscribed event happens, e.g. PRINT_JOB_STATUS_CHANGED when an order changes status.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "topics": "<topics>"
    },
    "name": "create_webhook"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	URL that will receive the event POSTs.
`topics`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds genuine value beyond the annotations by explaining the asynchronous delivery model (Lulu POSTs to the URL on event occurrence). However, it says nothing about duplicate subscriptions, idempotency/conflict behavior (idempotentHint is false), delivery retries, or authentication of the POSTs — meaningful gaps for an openWorld write tool.

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?

Two tight sentences with zero filler; the core action comes first and the behavioral explanation follows. Every sentence earns its place.

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 non-idempotent create tool with no output schema, the definition covers purpose and delivery mechanism but omits what is returned (webhook id), duplicate-handling, and error conditions. Adequate but with clear gaps.

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 coverage is 50%: 'url' is documented in the schema, while 'topics' has no description, only a single-value enum. The description partially compensates by naming a subscribed event (PRINT_JOB_STATUS_CHANGED) and its trigger, but does not explain the topics array semantics or how to format values.

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?

States a specific verb and resource ('Subscribe a URL to Lulu events') and explains the resulting behavior. It is clearly distinguishable from delete_webhook/update_webhook by the 'subscribe' framing, though it never explicitly names a sibling to contrast with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies the use case (receive event notifications instead of polling), but there is no explicit when-to-use vs. when-not, and no mention of siblings like test_webhook for verification or update_webhook for changing an existing subscription.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.