Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

glovo_stores

List ranked stores for a Glovo city category, optionally filtered by cuisine or type, and return ratings, delivery estimates, fees, promotions, and open status.

Instructions

List a Glovo category's ranked stores. Returns the first page of up to 50 stores from a city's category, in Glovo's own ranking, optionally narrowed to one cuisine or type filter. total_entries reports how many stores match in the city; only the first page is reachable without logging in (Glovo's server-rendered list ignores paging parameters), so use filter_id to reach other subsets. A category_id the city does not list, or a filter_id the category does not offer, returns a 404; a real category with no matching stores returns an empty list. The ranking and each store's distance are relative to the city's default point and can change between calls. Each store carries its id and address_id, which the store, menu and products endpoints take, plus its rating label, delivery estimate, delivery fee, promotions and open status.

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": {
      "country": "<country>",
      "city": "<city>",
      "category_id": "<category_id>"
    },
    "name": "glovo_stores"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityYesCity slug (madrid) or city code (mad), from /glovo/cities.
limitNoMax stores returned from the page. Defaults to 50, maximum 50.
countryYesTwo-letter country code, from /glovo/cities.
languageNoOptional two-letter response language; defaults to en. A city's supported languages are in /glovo/city's supported_languages.
filter_idNoOptional cuisine or type filter id, from /glovo/stores/filters for the same country, city and category_id.
category_idYesStore category id, from /glovo/categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the auth/paging ceiling (only the first page is reachable without logging in), the error contract (404 vs empty list), and the non-determinism of results (ranking and distance are relative to the city's default point and can change between calls). That is exactly the kind of quirk an agent cannot infer from schema alone.

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?

Front-loaded with the purpose, then behavior, then return contents — a sensible order with no filler sentences. It is dense (five sentences of packed clauses), which is close to the limit but each clause carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by enumerating what each store carries (id, address_id, rating label, delivery estimate, fee, promotions, open status). Combined with the error and paging semantics, an agent has everything needed to call and interpret results correctly.

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 baseline is 3, but the description adds real meaning: it explains why filter_id exists (to reach subsets when paging is ignored), that category_id must be one the city lists, and that limit operates within a 50-cap page. Only country/language get no added context, hence not a 5.

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 ("List a Glovo category's ranked stores") and immediately bounds scope to a city's category, first page, up to 50 entries. It also points to the downstream endpoints ("the store, menu and products endpoints take" the returned ids), which distinguishes it from the single-store siblings without ambiguity.

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 operational guidance: paging parameters are ignored server-side, so filter_id is the way to reach other subsets. It also explains outcome semantics (404 for an unlisted category or unavailable filter, empty list for no matches). It stops short of stating when to prefer a search-style sibling over browsing a category, so no explicit exclusions.

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