Is it in stock nearby? Store-level stock and prices at grocery stores and malls, with check times.
Scored across 3 tools
The three tools target distinct shapes of query: coverage/metro lookup (list_locations), example questions Aisles answers about a metro (list_answers), and specific product availability near a place (search_products). The boundary between list_answers and search_products is the only soft spot, since both are 'question answering' surfaces, but the descriptions explicitly route product questions away from list_answers.
All three follow a consistent verb_noun snake_case pattern (list_answers, list_locations, search_products). The only weakness is that 'list_answers' is semantically vague as a name — it returns example questions rather than answers — but the convention itself is uniform.
Three tools is on the small side but fits a narrow, read-only inventory-lookup domain where little else is needed. Each tool earns its place with a clear responsibility and none look redundant.
The read-only query surface is coherent but thin: there is no store-level lookup, no chain or category listing, and no direct price-comparison operation beyond what list_answers happens to expose. Agents can work around most of this via the three tools, but common follow-ups (e.g. details for a specific store or chain) are dead ends.
Use this for broad questions about one covered metro rather than one product: what stores are at a mall, where to find a kind of product at a mall or nearby, which stores carry a brand, what is on sale, the cheapest product per category, stores with curbside pickup or delivery, and chain price comparisons. Returns the questions Aisles answers from its daily checks, each with its page URL. For a specific product, use search_products instead.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Covered metro slug: chicago, new-york, los-angeles, houston, phoenix, philadelphia, san-antonio, san-diego, dallas, fort-worth, charlotte, columbus, indianapolis, seattle, south-bend, orlando, atlanta, boston, fort-lauderdale, baltimore, detroit, danbury, tampa, oakland, denver, las-vegas, akron, riverside, trenton, pittsburgh, st-louis, norfolk, milwaukee, little-rock, tucson, west-palm-beach, miami, aurora, louisville, minneapolis, memphis, omaha, cincinnati, lancaster, myrtle-beach, austin, cypress, fredericksburg, rogers, modesto, daytona-beach, jacksonville, savannah, michigan-city, kansas-city, albuquerque, albany, buffalo, middletown, rochester, niles, tulsa, scranton, charleston, nashville, allen, el-paso, mcallen, puyallup, birmingham, mobile, fort-smith, camarillo, bakersfield, fairfield, escondido, fresno, salinas, sacramento, victorville, colorado-springs, grand-junction, pueblo, wilmington, hartford, fort-myers, destin, jensen-beach, ocala, panama-city, pensacola, sarasota, tallahassee, commerce, columbus-ga, augusta, coralville, davenport, sioux-city, boise, champaign, normal, rockford, springfield, evansville, fort-wayne, kokomo, lafayette, ashland, wichita, bowling-green, lexington, elizabethtown, paducah, alexandria, baton-rouge, worcester, hyannis, hagerstown, salisbury, flint, portage, duluth, columbia, st-cloud, springfield-mo, jackson, tupelo, missoula, asheville, greensboro, raleigh, fargo, wilmington-nc, manchester, rockaway, gallup, reno, syracuse, dayton, sandusky, st-clairsville, toledo, oklahoma-city, erie, allentown, columbia-sc, greenville, florence, sioux-falls, clarksville, knoxville, chattanooga, abilene, beaumont, college-station, corpus-christi, killeen, longview, laredo, lubbock, midland, san-angelo, san-marcos, texas-city, victoria, waco, richmond, lynchburg, roanoke, kennewick, portland, union-gap, green-bay, johnson-creek, madison, bridgeport, mount-hope, vienna, huntsville, florence-al, dothan, chico, yuba-city, palm-desert, palmdale, fort-collins, macon, gainesville-ga, eugene, grand-rapids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that by explaining the data source (daily checks) and that each result carries a page URL, which substitutes for the absent output schema. It does not mention result volume, ordering, or whether a metro with no coverage returns empty, so it stops short of fully rich.
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?
Usage routing is front-loaded, and the tail sentence redirects to the sibling. The middle enumeration of question types is long, but each item plausibly helps an agent pattern-match a user query, so it largely earns its space rather than padding.
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?
For a one-parameter read-only list tool with full schema coverage and strong annotations, this covers what to call it with, what comes back (questions plus URLs), and when not to use it. Absent an output schema, only minor details like empty-result behavior are missing.
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% and the single location parameter already enumerates every metro slug, so the description cannot add much mechanically. It does reinforce the constraint that exactly one covered metro is in scope ('one covered metro'), which is a small but real clarification; the baseline of 3 applies.
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 gives a specific verb+resource ('Returns the questions Aisles answers from its daily checks') scoped to one metro, and explicitly contrasts scope with the sibling search_products. An agent can distinguish list_answers from search_products without opening either schema.
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?
It states when to use it ('broad questions about one covered metro rather than one product'), enumerates concrete question categories that qualify (stores at a mall, brand availability, sale items, curbside pickup, chain price comparisons), and names the exclusion plus the alternative: 'For a specific product, use search_products instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to check whether Aisles covers a place, chain or mall before answering, or when the user asks where Aisles works. Lists the 191 metro areas with published listings, with their slugs, the chains Aisles lists in each and the specific shopping malls whose stores are covered (with each mall's town). A metro being covered does not mean every store in it is.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional: words a metro, its state, a chain or a mall must contain, e.g. "TX", "Kroger", "Roosevelt Field". Leave it out for every covered metro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and idempotency are covered. The description adds genuine value by disclosing the scope of the result (191 metros with published listings) and the coverage caveat that a metro listing does not guarantee every store in it. It says nothing about result size, pagination or ordering, which an agent would need for a potentially long list.
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?
Usage comes first, then the returned content, then the caveat, so the structure is front-loaded and logical. The middle sentence is dense and somewhat run-on when enumerating slugs, chains and malls, but every clause carries real information.
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?
With no output schema, the description carries the burden of describing the return shape and does so (metros, slugs, chains, malls with towns). Annotations cover the safety profile, the only parameter is fully documented in the schema, and the coverage caveat addresses the main misreading risk. Nothing essential for correct invocation is missing.
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% and the single filter parameter is documented in the schema with concrete examples ("TX", "Kroger", "Roosevelt Field"). The description adds no additional meaning about how filtering interacts with metro/chain/mall matches, so the schema does all the work and the baseline of 3 applies.
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 names a specific verb ("Lists") and concrete resources (191 metro areas with slugs, the chains per metro, and covered malls with their towns). That level of specificity lets an agent distinguish it immediately from list_answers and search_products, which deal with answers and products rather than coverage geography.
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?
It gives explicit triggering conditions: check coverage of a place, chain or mall before answering, or when the user asks where Aisles works. It adds a useful caveat that metro coverage does not imply every store is covered. It does not name when not to use it or point to a sibling alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks where to find a specific product near a place, who has it, or whether it is in stock near a city or ZIP code ("where can I find Nike Dunks near South Bend?", "who has 2% milk near 46204?", "is the adidas Samba in stock near me in size 8?"), including indirect needs with a deadline ("I need Dunks in size 9 before Saturday"). Covers only the stores Aisles lists in 191 metro areas: Kroger-family grocery stores (in 12 of them), the stores inside 9 specific Simon malls and JD Sports, Finish Line, Bricks & Minifigs, Alamo Shoes, Alice's Garden, Just Roughin' It stores, not every chain or store. Grocery stores are checked only for milk, eggs, bread, coffee, baby formula, diapers, pain relief, cold and flu, toothpaste, paper towels, batteries, dog food; for other groceries Aisles has no listing. Returns the closest store listings: whether each store reported the item in stock, the retailer-reported price (possibly an online or regional price; a range across sizes/colors when no size is given), pickup/delivery options and when Aisles last checked. Not for online-only shopping or shipping orders, restaurants and food delivery, places outside the covered metro areas, chains or stores Aisles does not list, reserving or holding items, and promises that an item will still be there later. A listing is the retailer's last report, not a guarantee for a later day or a deadline. Add size, fulfillment, max_price or availability only when the user asked for them; if a fulfillment, price or availability filter leaves nothing, the reply lists what there is without it. A size is never dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | The clothing or shoe size the user stated, exactly as said, e.g. "8", "10.5", "M", "32". Only when the user gave one; a package amount is not a size. | |
| limit | No | Number of listings to return (default 8). | |
| query | Yes | Product words only: brand, product name or kind, e.g. "similac formula", "2% milk gallon", "dozen eggs", "nike air force 1", "levi's 501 jeans", "ugg". A brand alone is fine when that is all the user named. Package quantities and amounts ("gallon", "12 pack", "32 oz") stay here. Leave out the place and the clothing or shoe size. | |
| location | No | The place the user named: a covered metro slug or name (chicago, new-york, los-angeles, houston, phoenix, philadelphia, san-antonio, san-diego, dallas, fort-worth, charlotte, columbus, indianapolis, seattle, south-bend, orlando, atlanta, boston, fort-lauderdale, baltimore, detroit, danbury, tampa, oakland, denver, las-vegas, akron, riverside, trenton, pittsburgh, st-louis, norfolk, milwaukee, little-rock, tucson, west-palm-beach, miami, aurora, louisville, minneapolis, memphis, omaha, cincinnati, lancaster, myrtle-beach, austin, cypress, fredericksburg, rogers, modesto, daytona-beach, jacksonville, savannah, michigan-city, kansas-city, albuquerque, albany, buffalo, middletown, rochester, niles, tulsa, scranton, charleston, nashville, allen, el-paso, mcallen, puyallup, birmingham, mobile, fort-smith, camarillo, bakersfield, fairfield, escondido, fresno, salinas, sacramento, victorville, colorado-springs, grand-junction, pueblo, wilmington, hartford, fort-myers, destin, jensen-beach, ocala, panama-city, pensacola, sarasota, tallahassee, commerce, columbus-ga, augusta, coralville, davenport, sioux-city, boise, champaign, normal, rockford, springfield, evansville, fort-wayne, kokomo, lafayette, ashland, wichita, bowling-green, lexington, elizabethtown, paducah, alexandria, baton-rouge, worcester, hyannis, hagerstown, salisbury, flint, portage, duluth, columbia, st-cloud, springfield-mo, jackson, tupelo, missoula, asheville, greensboro, raleigh, fargo, wilmington-nc, manchester, rockaway, gallup, reno, syracuse, dayton, sandusky, st-clairsville, toledo, oklahoma-city, erie, allentown, columbia-sc, greenville, florence, sioux-falls, clarksville, knoxville, chattanooga, abilene, beaumont, college-station, corpus-christi, killeen, longview, laredo, lubbock, midland, san-angelo, san-marcos, texas-city, victoria, waco, richmond, lynchburg, roanoke, kennewick, portland, union-gap, green-bay, johnson-creek, madison, bridgeport, mount-hope, vienna, huntsville, florence-al, dothan, chico, yuba-city, palm-desert, palmdale, fort-collins, macon, gainesville-ga, eugene, grand-rapids) or a 5-digit ZIP code in those areas. Town and mall names are not resolved: for a town or mall inside a metro, use the metro (Del Amo Fashion Center or Torrance: los-angeles; King of Prussia or King of Prussia: philadelphia; Mall of Georgia or Buford: atlanta; Roosevelt Field or Garden City: new-york; Sawgrass Mills or Sunrise: fort-lauderdale; South Shore Plaza or Braintree: boston; The Galleria or Houston: houston; University Park Mall or Mishawaka: south-bend; Woodfield Mall or Schaumburg: chicago) or the town's ZIP. Leave it out when the user named no place: their approximate location is used if the app supplies it, and otherwise the reply asks for a city or ZIP. | |
| max_price | No | Maximum price in US dollars. | |
| fulfillment | No | Only stores offering all of these. | |
| size_system | No | Only when the user said whose size it is: US_MENS, US_WOMENS, US_YOUTH, US_UNISEX, EU or UK. Never infer it from the number alone ("size 8" has no system). | |
| availability | No | Default "available": in stock or low stock. | |
| radius_miles | No | Search radius in miles. Leave it out for a city to cover every store Aisles lists there, including malls outside the center; a ZIP defaults to 10 miles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds substantial context beyond that: coverage limits, which grocery categories are checked, what the return listings contain, price caveats, inventory freshness, and the fact that a listing is not a later-day guarantee.
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 use case and then scope, exclusions, and fallback behavior, so it is easy to scan for the key decision. It is very dense and somewhat sprawling because of the retailer list, grocery-category list, and multiple example phrases, though most of that detail is scope-critical.
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?
For a nine-parameter search tool with no output schema, the description covers what it returns, coverage limits, data freshness, exclusions, and empty-filter fallback behavior. An agent has enough information to decide when to call it and how to populate the optional filters.
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 description coverage is already 100%, so the schema documents each field. The description still adds important invocation meaning: only include size, fulfillment, max_price, or availability when the user asked; empty filters should be dropped; size is never dropped; and town or mall names must be mapped to a metro or ZIP.
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 opening sentence gives a specific verb, resource, and scope: finding a product in stock near a place, who has it, and stock near a city or ZIP. The boundaries around covered stores and excluded use cases make it clearly distinct from a general product or location search.
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?
It gives explicit when-to-use examples plus a detailed when-not list covering online-only shopping, restaurants, uncovered areas, unlisted chains, reserving items, and future availability promises. However, it does not name the sibling tools (for example, list_locations) as alternatives for resolving locations, so alternative-tool routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_answerslist_locationssearch_productsCanadian retail prices and store stock: Canadian Tire, Home Depot CA, Best Buy CA, LCBO, SAQ, more.
Where to buy a whole grocery list today: local prices, per-unit and cross-store comparison.
Product catalogues, prices and stock from online stores and supermarkets.
Price history, store prices near a ZIP and in-store clearance at major US retailers.
Add one secure layer between your agents and this server.