Skip to main content
Glama
Sign In

Hoplix Print on Demand

by com.hoplix
OverviewDiscussionsAdmin

Place an order

create_order

Places a real order that Hoplix prints and ships, with the same checks and prices as an order quote. Nothing is charged: the order is created unpaid and goes into production only after the seller pays it from the Orders page of the Hoplix account (the payment link is also sent by email), unless the account has agreed billing terms. order_reference is mandatory and unique: an existing reference is never ordered twice. With test=true the order is only validated and recorded as a test (TEST-... 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": {
      "order_reference": "<order_reference>",
      "products": "<products>",
      "shipping_mode": "<shipping_mode>",
      "shipping_info": "<shipping_info>"
    },
    "name": "create_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
testNotrue = test order: validated and priced, nothing is produced or charged
productsYesProducts to order
shipping_infoYesDelivery address
shipping_modeYesShipping method
order_referenceYesThe seller's own unique reference for this order (letters, digits, dot, underscore, hyphen; max 50)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: nothing is charged, the order is created unpaid, production starts only after the seller pays via the Orders page or emailed link, billing-terms accounts are exempt, and duplicate order_reference values are never ordered twice. The test=true path and its TEST-... id are also disclosed, which is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with the core action and the no-charge guarantee, then the payment/production flow, then the reference constraint and test mode. It is a single dense paragraph, but each sentence carries distinct information; only the parenthetical about the email link is close to redundant.

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 5-parameter mutation with nested objects and no output schema, the description covers the payment lifecycle, idempotency-by-reference, and test mode thoroughly. The one gap is that it never says what a successful real order returns (an order id), only what a test order returns.

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 already 100%, so the baseline is 3; the description adds real meaning on top by declaring order_reference mandatory and unique (rejecting duplicates) and by explaining what test=true actually does. It does not elaborate on shipping_mode or the nested product/address fields, but the schema covers those.

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?

States a specific verb and resource ('Places a real order that Hoplix prints and ships') and immediately scopes it against the quote path ('same checks and prices as an order quote'), which lets an agent separate it from quote_order without opening either schema.

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?

Gives clear conditions: use it for a real order, use test=true to validate without producing, and it references the quote as the equivalent non-committing check. It stops short of explicitly naming quote_order as the alternative to call first, so the routing is implied rather than stated.

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

Resources