dominos_store_locator

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that only US stores are returned, enumerates the specific status fields returned, and adds a valuable behavioral detail: the response's query field echoes how Domino's resolver interpreted the input, including location granularity. This goes beyond a simple 'find stores' statement, though it does not explicitly state read-only behavior or error cases.

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?

The description is front-loaded with the core action and resource, then provides return-field detail and input constraints in an orderly way. It is longer than a one-liner, but every sentence contributes either scope, output expectations, or parameter usage. The structure is efficient without being bloated.

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?

Given no output schema and no annotations, the description does a good job of explaining both inputs and expected outputs: store id, address with coordinates, phone, status, service-method availability, wait windows, and the resolver query echo. It is complete enough for an agent to call the tool correctly, though it does not cover malformed-input or no-results behavior.

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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the field names: it clarifies that postal_code alone is a valid input, that city and state must be used together, and that address is an optional street line that 'improves precision when combined with city/state.' This is useful semantic guidance that the schema does not fully convey.

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?

The description opens with a specific verb and resource: 'Find Domino's stores near an address, city/state, or ZIP code.' It further narrows scope to 'Domino's US stores that can serve a location,' which separates it from generic sibling store locators and the dominos_store detail tool. The return-field list makes the tool's job unmistakable.

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 description gives clear usage context by specifying input prerequisites: 'At least one of postal_code, or both city and state, is required' and that address is optional and improves precision. It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5, but the context is unambiguous.

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