Skip to main content
Glama
sepehr071

snapp-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search dishes

food_search
Read-onlyIdempotent

Search dishes by name near a delivery point, showing prices, discounts, and restaurants for finding nearby meals or discounted menu items.

Instructions

Search dishes by name near a delivery point, with price, discount and restaurant.

Use for "find X near me" or "discounted X". relevance is one fast index call; cheapest / biggest_discount drop side items and confirm prices on live menus. For the cheapest X across many menus use food_find_cheapest.

Input Schema

NameRequiredDescriptionDefault
latYesDelivery point latitude.
longYesDelivery point longitude.
sortNoOrder of the results.relevance
limitNoMax dishes.
queryYesDish word, e.g. 'پیتزا'.
discounted_onlyNoOnly dishes with a discount.
include_proteinNoAlso search protein stores (butchers, eggs), hidden by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.2.0
    • removedInput schema / properties / discounted_only / title
      Removed value: -"Discounted Only"
    • changedInput schema / properties / include_protein / description
      Previous value: -"Also search protein stores (butchers, poultry, eggs), which are hidden by default."New value: +"Also search protein stores (butchers, eggs), hidden by default."
    • removedInput schema / properties / include_protein / title
      Removed value: -"Include Protein"
    • changedInput schema / properties / lat / description
      Previous value: -"Latitude of the delivery point (Iran: ~25 to ~40)."New value: +"Delivery point latitude."
    • removedInput schema / properties / lat / title
      Removed value: -"Lat"
    • changedInput schema / properties / limit / default
      Previous value: -20New value: +10
    • changedInput schema / properties / limit / description
      Previous value: -"Max dishes to return."New value: +"Max dishes."
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • changedInput schema / properties / long / description
      Previous value: -"Longitude of the delivery point (Iran: ~44 to ~63)."New value: +"Delivery point longitude."
    • removedInput schema / properties / long / title
      Removed value: -"Long"
    • changedInput schema / properties / query / description
      Previous value: -"Dish or food word, Persian works best, e.g. 'پیتزا', 'کباب'."New value: +"Dish word, e.g. 'پیتزا'."
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • removedInput schema / properties / sort / title
      Removed value: -"Sort"
    • removedInput schema / title
      Removed value: -"food_searchArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "food_searchDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuine behavioral context beyond that: 'relevance is one fast index call' discloses relative latency, and cheapest/biggest_discount are flagged as dropping side items and confirming prices on live menus, which warns about result-quality tradeoffs. It stops short of describing result shape 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 tight sentences, front-loaded with the core action, then usage triggers, then per-sort behavior and the sibling handoff. No filler or restated field names.

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 no output schema the description still tells the agent what a result contains (price, discount, restaurant) and how sorting changes result composition. Minor gaps remain around result volume/pagination and the hidden protein-store behavior, but nothing essential to a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 earns extra by explaining what the sort enum values actually do to results rather than restating them. It does not, however, touch limit, discounted_only or include_protein beyond what the schema already says.

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 and resource ('Search dishes by name') plus the scoping constraint ('near a delivery point, with price, discount and restaurant'). It also explicitly names the sibling it is not (food_find_cheapest), so an agent can separate it from the other food_* tools without opening a schema.

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?

Gives concrete trigger phrasings ('find X near me', 'discounted X') and an explicit exclusion rule: use food_find_cheapest for the cheapest X across many menus. It also explains which sort mode suits which intent, which is real when-to-use guidance.

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

Deploy Server

Other Tools