JENNi Shop Local

Find a shop by name

find_stores

Read-onlyIdempotent

Read-only directory for explicit shop-name questions, near a US ZIP code or served market. Returns shop identifiers, addresses and storefront URLs. A listing proves no product stock, price, delivery or checkout eligibility.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	No	5-digit US ZIP code: searches the shops within 15 miles of it first, then the national list.
`name`	Yes	Shop name or part of it, e.g. "Cheeky Monkey".
`limit`	No	Shops to return (default 10).
`market`	No	Market key, e.g. san-antonio-tx. Used when no zip is given.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`stores`	Yes
`partial`	Yes	True when not every listed shop could be compared.
`location`	No
`next_step`	No	Present when no shop matched.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

changedInput schema / properties / zip / description

Previous value: -"5-digit US ZIP code: searches the shops within 15 miles of it first, then the national list. Pass it for any shop outside San Antonio."New value: +"5-digit US ZIP code: searches the shops within 15 miles of it first, then the national list."

Changed1 schema field changedOct 21, 2026

changedOutput schema / properties / stores / items / properties / alias_store_ids / description

Previous value: -"Other store ids JENNi folded into this same physical shop. Display only; refer to the shop by store_id."New value: +"Other store ids JENNi folded into this same physical shop. Display only."

Changed1 schema field changedOct 20, 2026

changedOutput schema / properties / stores / items / properties / alias_store_ids / description

Previous value: -"Other store rows of this same physical shop, for display; search_catalog with the store_id covers them (PAS expands it)."New value: +"Other store ids JENNi folded into this same physical shop. Display only; refer to the shop by store_id."

Changed1 schema field changedOct 20, 2026

addedOutput schema / properties / stores / items / properties / alias_store_ids

Added value: +{
+  "description": "Other store rows of this same physical shop, for display; search_catalog with the store_id covers them (PAS expands it).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 19, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's real value is the boundary warning: 'A listing proves no product stock, price, delivery or checkout eligibility.' That is exactly the kind of non-obvious constraint an agent needs and is not in the structured fields. It stops short of describing result ordering or pagination.

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?

Three dense sentences with the scope and return summary front-loaded and the important caveat last. No filler or redundancy.

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 an output schema present, return fields need only a brief mention, which the description provides. Combined with annotations covering safety, the definition gives an agent enough to call it correctly; only minor gaps remain around result ordering and fuzzy-match behavior.

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 coverage is 100%, so each parameter is fully documented in the schema itself; the description only restates the ZIP/market fallback logic. Baseline 3 applies since the schema does the heavy lifting and the description adds no format or syntax detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only directory' for shop-name lookups) and scopes the search to a ZIP or market. It implicitly distinguishes itself from catalog/product siblings by framing itself as an 'explicit shop-name' lookup, though it never names a sibling directly.

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?

The phrase 'for explicit shop-name questions' gives a clear condition for when this tool is appropriate, and the ZIP-vs-market scoping hints at how to invoke it. It does not explicitly route to an alternative (e.g. search_catalog) when the agent lacks a name.

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

All JENNi Shop Local 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?