4OVER4

Price a 4OVER4 print product

configure_product

Read-onlyIdempotent

Prices one 4OVER4 print product live (business cards, flyers, postcards, banners, stickers or any other) for a quantity, size, paper, finish and turnaround; use it when someone asks what a print job costs or which options it has. For a quantity ladder use price_breaks; for dates use delivery_by_zip. Requires the product slug. Returns the live total and per-piece price, sizes, quantity tiers, turnarounds, options, an order link and a cart link, shown as 4OVER4's own configurator card with its photo; show that card instead of building another form. Customer phrases: "how much for 500 glossy business cards", "16pt postcards in 3 days".

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": {
      "slug": "<slug>"
    },
    "name": "configure_product"
  }
}

Input Schema

Name	Required	Description
`qty`	No	Number of printed pieces, e.g. 500.
`size`	No	Size in inches as width x height, e.g. 4x6 or 2x3.5; a round size is its diameter both ways plus circle, e.g. 2x2 circle.
`slug`	Yes	Product slug, from the slug field of a show_products, recommend or find_similar_products result, e.g. standard-business-cards. A category slug such as business-cards prices its main product.
`mailing`	No	true prices direct mail and Every Door Direct Mail options, postage included.
`attributes`	No	Option choices: each key is an option group label and each value is a string from that group's choices in the options field of a result, e.g. {"Ink Color": "4/4", "Paper Type": "16pt Gloss Cover", "Rounded Corners": "Yes"}.
`turnaroundDays`	No	Turnaround in business days, e.g. 3.

Output Schema

Name	Required	Description
`data`	No	The live price (total and per piece) for the chosen quantity, size, options and turnaround, plus sizes, quantity tiers, turnarounds and options.
`link`	No	The page on www.4over4.com to continue on: order, upload and checkout happen there.
`summary`	Yes	The facts of the result in plain sentences.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds real operational context: pricing is live, the response arrives as 4OVER4's own configurator card with photo, and the agent must render that card rather than build its own form. That rendering directive is behavior an agent cannot infer from any structured field.

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?

Content is front-loaded: purpose and when-to-use come first, alternatives second, return/rendering third, sample phrases last. It is dense but nearly every clause earns its place; the trailing customer-phrase quotes are borderline but useful for matching user language.

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

Completeness5/5

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

For a live-pricing tool with nested attributes and an output schema, the definition covers what an agent needs: the prerequisite slug, sibling disambiguation, the fact that prices are live, and the critical post-call instruction to display the returned configurator card. Nothing material is missing.

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 description coverage is 100% and the schema already documents qty, size, attributes, mailing, turnaroundDays and slug with examples and sourcing guidance. The description only restates the required slug and the dimension names (quantity, size, paper, finish, turnaround), adding little beyond the schema, so the baseline of 3 applies.

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 opens with a specific verb+resource+scope: "Prices one 4OVER4 print product live", then enumerates the product families covered and the pricing dimensions (quantity, size, paper, finish, turnaround). It is instantly distinguishable from siblings like price_breaks and delivery_by_zip, which are named by scope role.

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

Usage Guidelines5/5

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

It states when to use it ("when someone asks what a print job costs or which options it has") and explicitly routes away to alternatives: "For a quantity ladder use price_breaks; for dates use delivery_by_zip." It also gives the prerequisite ("Requires the product slug") and sample customer phrasings that map to invocation.

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

All 4OVER4 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.

Resources

Need Help?