Hoplix Print on Demand

Create a campaign

create_campaign

Creates a new campaign: the seller's design printed on a catalogue product (plus optional additional products), with selling price and colours. The design is an image uploaded on a personal Hoplix upload page (front_design_upload_id / back_design_upload_id) or a public http(s) URL of a PNG or JPG image (front_image_url / back_image_url). A transparent PNG at the size given in the product "pixel" field gives the best print. A public campaign gets its own page on Hoplix at the chosen url; a private one is only for the seller's own orders. Returns the campaign id.

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": {
      "name": "<name>",
      "product_code": "<product_code>",
      "product_colors": "<product_colors>",
      "product_price": "<product_price>"
    },
    "name": "create_campaign"
  }
}

Input Schema

Name	Required	Description
`url`	No	Public page slug: letters, digits and hyphens, must be unused (required unless private)
`name`	Yes	Campaign name
`private`	No	true = private campaign, only for the seller's own orders (default false)
`description`	No	Campaign description shown on the public page (defaults to the name)
`product_code`	Yes	Catalogue product code of the main product
`product_price`	Yes	Selling price in EUR, VAT included; for public campaigns at least the base cost (base-cost-back when printing front and back)
`back_image_url`	No	Public http(s) URL of the back design (PNG or JPG), only for products with two print sides
`product_colors`	Yes	Colours of the main product, from the product colours
`front_image_url`	No	Public http(s) URL of the front design (PNG or JPG)
`additional_products`	No	Other products with the same design, among the additional products of the main product
`back_design_upload_id`	No	UPL-... id of an uploaded image, used as back design (alternative to back_image_url)
`front_design_upload_id`	No	UPL-... id of an uploaded image, used as front design (alternative to front_image_url)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false and destructive=false, so the mutation profile is known. The description adds real context beyond that: a public campaign generates a live page at the chosen slug, a private one is confined to the seller's own orders, the url must be unused, and price must clear the base cost for public campaigns. It does not mention failure modes (slug collision, invalid upload id) or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded in the first clause, followed by design-source, print-quality, visibility, and return-value details in a logical order. It is dense but nearly every sentence carries information; the transparent-PNG sentence is the one borderline nicety, though it is actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter creation tool with no output schema, the description covers the essentials: what is created, the two design input modes, public vs private semantics, price constraint, and the return value (campaign id). Missing are error behavior and any note that required product/colour values come from get_product, but nothing critical to correct invocation is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-field meaning the schema cannot: the design is either a front/back upload id or a front/back URL, transparent PNG at the product's 'pixel' size yields the best print, and back designs apply only to two-sided products. That is genuine added interpretation of how parameters relate to each other.

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 gives a specific verb and resource ('Creates a new campaign') and then defines the resource concretely: a seller's design printed on a catalogue product with selling price and colours. It distinguishes this from sibling read tools (get_campaign, list_campaigns) by making clear this is the creation entry point that returns a campaign id.

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?

It explains the two design-source routes (an uploaded UPL-... id vs a public PNG/JPG URL) and the public vs private campaign choice, which guides parameter selection. However, it never states when to reach for this tool versus create_order or the design-upload tools, and gives no prerequisites such as needing to obtain a product_code or upload id first.

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

All Hoplix Print on Demand tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.