MCP server for RuneLore, a B2B supplier of finished printed products (custom-designed mugs, t-shirts, hoodies, tote bags, hats, socks) for independent shops. Four tools: search_designs (search the design library), get_product_blueprint (product specs and pricing), compose_preview (render a design on a product), place_order (create an order). No account or API key needed.
Scored across 4 tools
Each tool has a distinct action-resource: search designs, read product blueprint, compose a product preview, and place an order. Boundaries are clear, with no overlapping functionality that would cause misselection.
All tools use the same runelore. namespace and snake_case verb_noun pattern: search_designs, get_product_blueprint, compose_preview, place_order. There is no mixed casing or inconsistent verb style.
Four tools is a focused, well-scoped set for the artwork-to-order workflow. Each tool has a clear role, and there is no evident bloat or severe under-provisioning.
The core flow from design search through preview and order placement is covered, but order lifecycle is incomplete: no get/list/cancel order or payment-status tool, and broader product/design retrieval is limited. These are notable gaps for a commerce workflow, though agents might work around some by using returned IDs.
Place supplied or library artwork on a product. Returns temporary previews; never publishes inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Canonical numeric product ID from get_product_blueprint, supplied as a string (for example "19"). | |
| designId | No | Case-sensitive artwork ID returned by search_designs; supply this or fileBase64 plus mediaType, never both. | |
| mediaType | No | MIME type of fileBase64: image/png or image/jpeg; omit when using a library designId. | |
| placement | Yes | A placement name or surfaceId from this product blueprint with composable:true (for example "wrap" or "front"). | |
| transform | Yes | Artwork position and dimensions on the blueprint’s 1000×1000 print-area grid; X/Y anchor the unrotated top-left corner and the two axes can have different physical scales. | |
| fileBase64 | No | Standard padded base64 image bytes without a data-URL prefix; PNG/JPEG only, at most 6 MB decoded and 4096 pixels per side; use with mediaType instead of designId. |
| Name | Required | Description |
|---|---|---|
| product | Yes | Canonical physical product ID used for this composition. |
| previews | Yes | Map of view name to absolute PNG URL; fetch exactly as returned before expiry. |
| expiresAt | Yes | ISO 8601 UTC expiry deadline; previews normally last 30 minutes and can disappear sooner on restart or eviction. |
| placement | Yes | Public placement name used for this composition. |
| transform | Yes | Accepted placement on the 1000 × 1000 print-area grid. |
| variantId | Yes | Default size/color variant selected from the product blueprint. |
| designName | Yes | Library artwork name, or Custom design for an uploaded image. |
| previewKind | Yes | Preview method: artwork composited onto a product photograph. |
| compositionId | Yes | Case-sensitive temporary composition ID accepted by place_order before expiry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety is partly covered. The description usefully adds that output is temporary and that inventory is never published, which clarifies the boundary of this write-ish operation beyond what the annotations convey.
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?
Two compact sentences, front-loading the action and immediately qualifying the non-publishing, temporary nature. No waste.
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?
With a full input schema, an output schema covering return values, and annotations covering safety, the description is nearly complete. The only gap is explicit routing guidance to the sibling tools, which is implied rather than stated.
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 rich per-parameter docs (product ID format, designId vs fileBase64/mediaType mutual exclusion, placement surfaceId, transform grid) already carry the semantics. The description adds no additional parameter meaning, so baseline 3 applies.
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?
States a specific verb and resource: 'Place supplied or library artwork on a product.' The added clause 'Returns temporary previews; never publishes inventory' distinguishes it from the publish-oriented sibling place_order, though it does not name the sibling explicitly.
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 phrase 'never publishes inventory' implies this is the preview step versus the actual order/publish step, and the schema params point to get_product_blueprint and search_designs as prior steps. However, there is no explicit when-to-use guidance or named alternative in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a product’s printable dimensions, 1000-grid and available preview views.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Canonical numeric product ID as a string (for example "19"); use a returned product ID, not a product-name filter. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Display name of the physical product. |
| size | Yes | Size label of the selected default variant. |
| slug | Yes | Canonical product ID accepted by compose_preview.product. |
| color | Yes | Color label of the selected default variant. |
| trade | Yes | Suggested shop or trade collection ID for this product. |
| variantId | Yes | Selected default size/color variant ID. |
| placements | Yes | Verified supported print placements; an empty array means no composable placement is available. |
| availability | No | Current supplier availability for the selected default variant; this is not a warehouse quantity. |
| sourceVersion | Yes | Version fingerprint of the product blueprint; a changed version invalidates older previews. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds a modest amount of context by naming the data returned (1000-grid, preview views), but discloses nothing about error behavior, missing-product handling, or payload size.
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?
A single front-loaded sentence with zero filler; the payload contents are listed immediately after the verb and resource. Nothing could be removed without losing 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?
With an output schema present, the description need not document return values, and annotations carry the safety profile, so the gaps are minor. It is nearly complete for a single-parameter read tool, with only usage routing left unaddressed.
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% and the single parameter's schema text already explains the canonical numeric string ID and warns against name filters. The description adds no parameter-level detail, so the baseline 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?
States a specific verb ("Read") and resource (a product's blueprint) and enumerates the returned content: printable dimensions, 1000-grid, preview views. This is far more informative than a bare name restatement, though it does not explicitly contrast itself with siblings like compose_preview or search_designs.
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?
There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as search_designs or compose_preview. The only implied usage signal is loader semantics from the phrasing, which the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an unpaid order and Stripe payment URL. Only the customer or their authorized agent completes payment at Stripe.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Valid receipt email address, up to 254 characters; payment details are entered only on the returned Stripe checkout page. | ||
| items | Yes | One to 20 order lines, each with a quantity and exactly one finishedProductId, compositionId, or composition. | |
| requestId | No | Optional idempotency key of 8–128 letters, digits, underscores or hyphens; use a new key per intended order and reuse it unchanged with identical details for retries. | |
| shippingAddress | Yes | Recipient delivery address used to confirm shipping and tax; supply the documented fields only. |
| Name | Required | Description |
|---|---|---|
| orderId | Yes | Identifier of the newly created or idempotently reused unpaid order. |
| paymentUrl | Yes | Hosted Stripe Checkout URL for customer-authorized payment; card details go to Stripe only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare write/idempotent/open-world/non-destructive, and the description adds genuinely new behavioral context beyond them: the order is created UNPAID and the only payment path is the customer completing checkout at Stripe. It does not cover retry/idempotency semantics (requestId) or what the returned URL looks like, but the two-phase payment disclosure is real added value.
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?
Two short, front-loaded sentences with zero filler; the core action comes first and the payment-flow constraint second.
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?
With a 100% covered schema, an output schema (which handles return values like the Stripe URL), and annotations covering the write/idempotent profile, the description is nearly sufficient. The remaining gap is that it never states where the line-item selectors must come from (compose_preview / search_designs), leaving the prerequisite chain to the schema descriptions.
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 fully documents items, shippingAddress, email and requestId. The description adds no parameter-level meaning beyond what the schema already states, so the baseline 3 applies.
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?
States a specific verb+resource ('Create an unpaid order') plus the notable output artifact ('Stripe payment URL'). It is clearly distinct from the sibling read/prep tools (compose_preview, get_product_blueprint, search_designs), though it never names them or explicitly contrasts itself.
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?
Usage is implied: the second sentence clarifies that the caller does not pay here and that the customer pays at Stripe, which tells the agent this is the order-placement step. However there are no explicit when-to-use/when-not rules, no statement of prerequisites (e.g. needing a compositionId from compose_preview or a finishedProductId from search_designs), and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search RuneLore artwork by trade, product or words. Returns paginated designs and preview URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional case-insensitive words matched against artwork names, categories and aliases; up to 200 characters, with an empty string meaning no text filter. | |
| limit | No | Requested page size, default 24; anonymous requests support 1–100, and limits up to 200 require bulk access. | |
| trade | No | Optional trade or seasonal collection name/ID (for example Gym, barbershop, or halloween), up to 80 characters. | |
| cursor | No | Opaque base64url nextCursor from the previous page; reuse the same filters and limit, or omit for the first page. | |
| product | No | Optional canonical product ID or product-name substring (for example "19" or "mug"), up to 80 characters. |
| Name | Required | Description |
|---|---|---|
| designs | Yes | Matching public library artwork on this page. |
| products | No | Matching physical products; present only when the request includes a product filter. |
| nextCursor | Yes | Opaque cursor for the next page, or null at the end; reuse the same filters and limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, covering the safety profile. The description adds that results are paginated and include preview URLs, but with an output schema present, the return-value claim is largely redundant and no auth or rate-limit context is added beyond what the schema's limit parameter already explains.
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?
Two sentences, zero filler, with the core purpose front-loaded ahead of the return-value note. Every clause earns its place.
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?
With a full output schema, thorough annotations, and 100% parameter coverage, the description only needs to frame the tool's purpose, which it does. The remaining gap is routing guidance relative to siblings, which is absent.
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 documents every parameter including the anonymous-vs-bulk limit distinction and cursor reuse rules. The description's "by trade, product or words" restates the parameters without adding syntax or format detail, so the baseline of 3 applies.
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?
States a specific verb and resource ("Search RuneLore artwork") plus the three query facets, which lets an agent grasp the tool's role immediately. It does not explicitly contrast itself with siblings like compose_preview or get_product_blueprint, so it stops short of a 5.
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?
There is no statement of when to use this tool versus the sibling tools, and no prerequisites or exclusions are given. The search facets hint at how to query but not when this is the right tool versus get_product_blueprint or compose_preview.
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.
runelore.compose_previewrunelore.get_product_blueprintrunelore.place_orderrunelore.search_designs
Add one secure layer between your agents and this server.