Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

glovo_store_search

Search a single Glovo store's products by keyword to retrieve matching items, prices, stock, and options for that location.

Instructions

Search one Glovo store's products by keyword. Returns the products of one store that match a keyword (for example burger), with the same fields as /glovo/store/products: name, description, price, currency, display price, image URL, stock flag and option groups. total_products reports how many matched in the store; limit caps the returned list (default 50, maximum 500). A keyword that matches nothing returns an empty list, not an error. When address_id is omitted the store's own default location is looked up first, which costs one extra upstream call.

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>",
      "store_id": "<store_id>",
      "query": "<query>"
    },
    "name": "glovo_store_search"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City slug (madrid) or city code (mad), from /glovo/cities.
`limit`	No	Max products returned. Defaults to 50, maximum 500.
`query`	Yes	Keyword to search this store's own products by.
`country`	Yes	Two-letter country code, from /glovo/cities.
`language`	No	Optional two-letter response language; defaults to en. A city's supported languages are in /glovo/city's supported_languages.
`store_id`	Yes	Store id, from /glovo/stores' id field.
`address_id`	No	Optional store location id, from /glovo/stores' address_id field.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations to fall back on, the description carries the full load and does so well: it enumerates the returned fields (name, description, price, currency, display price, image URL, stock flag, option groups), explains total_products versus limit, states that a non-matching keyword yields an empty list rather than an error, and discloses the extra upstream lookup when address_id is omitted. Those are exactly the behavioral traits an agent needs and would otherwise have to discover empirically.

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?

Five tight sentences, front-loaded with purpose and return shape before the limit semantics and the address_id cost caveat. No filler and no restatement of the tool name; each sentence 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?

For a seven-parameter read tool with no output schema, the description compensates by describing the response payload in detail and covering edge cases (empty results, limit defaults/max, address_id overhead). An agent has enough to call it correctly and interpret the response without further documentation.

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; the description adds genuine value on top by explaining that limit caps the returned list while total_products reports the full match count, and by flagging the performance cost of leaving address_id unset. It stops short of clarifying country/city/language interplay, but the substantive parameters are covered.

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?

The description opens with a specific verb and resource, 'Search one Glovo store's products by keyword', and narrows the scope to a single store, which implicitly separates it from whole-store listing tools like glovo_store_products. It never names the sibling it replaces, so an agent must infer the boundary from the scope wording rather than being told directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The definition gives useful behavioral context (empty results are not errors, omitting address_id costs an extra upstream call) but offers no explicit when-to-use/when-not-to-use guidance or named alternatives. It says what the tool does in conditions, not when an agent should pick it over glovo_store_products or a cross-store search.

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

Deploy Server