Skip to main content
Glama

dominos_coupons

Read-only

Fetch coupon and deal records available at one Domino's U.S. store_id, including prices, valid service methods, alternate promo codes, and tiered volume discounts. Use dominos_store for store details or dominos_menu to browse menu items.

Input Schema

NameRequiredDescriptionDefault
store_idYesRequired. Domino's store id, from /dominos/store-locator.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and live-fetch behavior are covered. The description adds one genuinely new behavioral fact — the data is U.S.-only and scoped to a single store — but the enumerated record contents largely overlap with what the existing output schema would convey, and pagination/rate-limit behavior is unstated.

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

Conciseness5/5

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

Two sentences, front-loaded with the action and scope, followed by routing to alternatives. No filler; every clause carries information.

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?

With annotations, a 100%-covered single-parameter schema, and an output schema, the description supplies what an agent needs to select and invoke the tool. The only gap is that it doesn't mention the prerequisite of resolving store_id via dominos_store_locator or any result-size limits.

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% (store_id documented as required, sourced from /dominos/store-locator). The description only reinforces that exactly one store's coupons are returned ('one ... store_id') and adds the U.S. qualifier, which is marginal beyond what the schema already provides — the baseline 3 for high-coverage schemas.

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?

Specific verb (Fetch) plus resource (coupon and deal records) with explicit scope (one Domino's U.S. store_id). It even enumerates the record contents (prices, service methods, promo codes, volume discounts), and names the sibling tools it is not, so an agent can distinguish it from dominos_menu/dominos_store without opening schemas.

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?

Routes the agent away from two concrete siblings: 'Use dominos_store for store details or dominos_menu to browse menu items.' This implies coupons/deals are the use case, but it never states when NOT to call it or that a valid store_id must first be obtained from dominos_store_locator.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.