Skip to main content
Glama
Sign In

pricing

by com.tabzoola
OverviewDiscussionsAdmin

Quote a custom tab set price

quote_price
Read-onlyIdempotent

Use this when the user wants a price for custom-printed tab dividers and knows the tabs per set and number of sets: returns exact per-set and total USD with setup included, plus an orderUrl that opens Tabzoola's configurator with this build pre-selected for a human to complete. Same engine as the website. Minimum 25 sets, 1-150 tabs per set. Do not use for reverse-printed tabs, PMS ink or custom sheet sizes (quote only), and never to charge anyone: it is read-only.

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": {
      "product": "<product>",
      "tabsPerSet": "<tabsPerSet>",
      "sets": "<sets>"
    },
    "name": "quote_price"
  }
}

Input Schema

NameRequiredDescriptionDefault
setsYesQuantity of sets (minimum order 25)
optionsNoOptional map of optionKey -> choiceId (see get_pricing_capabilities). Omitted options use defaults.
productYesProduct line (paper is the only product)
tabsPerSetYesTabs in each set
colorChangesNoOptional and ignored for price: tab colors mix freely at no extra charge

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / colorChanges / description
      Previous value: -"Optional and ignored for price: tab colors mix freely at no extra charge on paper and poly"New value: +"Optional and ignored for price: tab colors mix freely at no extra charge"
    • changedInput schema / properties / product / description
      Previous value: -"Product line"New value: +"Product line (paper is the only product)"
    • changedInput schema / properties / product / enum
      Previous value: -[
-  "paper",
-  "poly"
-]New value: +[
+  "paper"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / colorChanges / description
      Previous value: -"Poly only: distinct tab colors minus one"New value: +"Optional and ignored for price: tab colors mix freely at no extra charge on paper and poly"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint/idempotentHint, the description discloses the return payload (exact per-set and total USD, setup included), the orderUrl handoff to a human configurator, and that pricing runs on the same engine as the website. It also reinforces the read-only boundary with "never to charge anyone," which is behavior an agent must not infer from annotations alone.

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?

Two dense sentences, front-loaded with the trigger and followed by returns and exclusions; nearly every clause earns its place. The first sentence is long and packs several ideas (returns, orderUrl, engine), which slightly hurts scanability.

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?

With no output schema, the description takes responsibility for describing return values (per-set, total USD, setup included, orderUrl) and the human-completion flow. Business constraints, exclusions, and the not-for-charging boundary are all present, so an agent can call it safely without further context.

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%, so the schema already carries parameter meanings (including that colorChanges is ignored for price and that options map to get_pricing_capabilities). The description restates the 25-set minimum and 1-150 tabs range already encoded as schema bounds, adding little parameter-level meaning beyond the schema baseline.

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+resource (quote a price for custom-printed tab dividers) and the exact inputs that qualify (tabs per set, number of sets). Clearly separable from siblings like draft_order (which actually places orders) and get_pricing_capabilities (which lists options).

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?

"Use this when the user wants a price ... and knows the tabs per set and number of sets" gives a positive trigger; "Do not use for reverse-printed tabs, PMS ink or custom sheet sizes (quote only)" and "never to charge anyone" give explicit exclusions, and the alternative (open orderUrl for a human to complete) is named.

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

All pricing 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