Skip to main content
Glama

Crawlora MCP

swiggy_search

Read-only

Swiggy (India) restaurant search near a location, optionally filtered by a keyword or browsed within a curated collection (see swiggy_collections): id, name, cuisines, cost for two, rating, delivery time, and open/closed status. A keyword search can pick either result tab (tab=dish returns matching dishes with prices per restaurant, tab=restaurant a wider restaurant-name/cuisine match), sort by relevance/rating/delivery time, and filter by veg, min_rating, and offers.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "latitude": "<latitude>",
      "longitude": "<longitude>"
    },
    "name": "swiggy_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
tabNoWhich of Swiggy's own two keyword-search result tabs to read: dish (default -- restaurants that serve a matching dish, each with the matching dishes) or restaurant (restaurants whose own name/cuisine matches, a wider set). Only valid together with query.
vegNoOnly return vegetarian results: veg dishes on tab=dish, pure-veg restaurants on tab=restaurant. Only valid together with query.
sortNoOptional sort order. With collection_id: relevance (default), delivery_time, rating, cost_low_to_high, cost_high_to_low. With query: relevance (default), delivery_time, rating only. Not valid on a plain nearby browse.
queryNoOptional keyword to search restaurants and dishes by, at least 2 characters. Omit for a plain location browse of nearby restaurants. Mutually exclusive with collection_id.
offersNoOnly return restaurants currently running an offer. Only valid together with query.
offsetNoOpaque pagination cursor from a prior response's next_offset. Not meaningful when query is set (Swiggy's own keyword-search endpoint does not paginate the same way).
latitudeYesSearch center latitude (required).
longitudeYesSearch center longitude (required).
min_ratingNoOnly return restaurants rated at or above this score (0-5). Only valid together with query.
collection_idNoOptional curated collection id from /swiggy/collections's id field. When set, browses restaurants within that collection instead of the plain nearby listing. Mutually exclusive with query.

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.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral detail beyond that: the two result tabs differ (tab=dish returns dishes with prices, tab=restaurant returns a wider name/cuisine match), sort options vary by mode, and certain filters only apply with query.

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

Conciseness4/5

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

Two dense sentences that front-load the tool's identity and mode selection before filter details. Every clause carries information, though the field enumeration is slightly redundant given the output schema.

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?

For a multi-mode search tool with a rich schema and an output schema, the description covers modes, filters, and result-tab behavior adequately. Return values are enumerated despite the output schema handling them, and cross-tool routing remains the only real gap.

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 the schema already documents every parameter and its constraints. The description reinforces the tab and sort semantics but adds little the schema does not already state, making the baseline 3 appropriate.

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 (search), resource (Swiggy India restaurants), scope (near a location), and the three modes (plain browse, keyword query, collection browse). It also lists the returned fields, so an agent can tell it apart from swiggy_restaurant and swiggy_restaurant_menu 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: omit query for a plain nearby browse, use collection_id to browse a curated collection (pointing to swiggy_collections for ids), and use query for keyword search. It does not explicitly say when to prefer swiggy_restaurant or swiggy_restaurant_menu over this tool, so routing against those siblings is left to inference.

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.

Resources