Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

deliveroo_restaurant_menu

Fetch a Deliveroo partner's full priced catalog grouped into categories using its slug and market. Get item names, descriptions, prices, availability, and customization options.

Instructions

Get one Deliveroo restaurant, grocery, or shopping partner's priced catalog. Returns one partner's full menu or catalog grouped into categories -- restaurant menus, grocery aisles, and shopping-store catalogs all use this same endpoint (see /deliveroo/search's collection parameter). Every item carries a name, description, product-meta text when the upstream provides it (calorie counts on restaurant items, per-unit pricing like "380g · £15.79/kg" on grocery/shopping items), price, availability, and its resolved customization options (e.g. "Choose your meal", "Add ingredients?") with each option's own price and required/multi-select bounds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
unameYesRestaurant slug, from a search response's uname field
marketNoDeliveroo national market the uname was found in (default uk)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / market / enum
      Added value: +[
+  "uk",
+  "ie",
+  "fr",
+  "it",
+  "be",
+  "ae",
+  "kw"
+]
  2. Addedv1.16.2

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses item fields (name, description, price, availability, customization options) and notes that some fields are conditional ('when the upstream provides it'). However, it does not mention pagination, response size, rate limits, or whether the operation is read-only (implied but not explicit). This is a moderate level of transparency for a data-fetching tool.

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?

The description is dense but well-structured: the first sentence states the purpose, the second explains grouping and item fields. Each sentence adds useful information without redundancy. It is slightly long but appropriate given the tool's complexity and the lack of an 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?

With no output schema, the description must describe the return structure. It does detail item fields and grouping into categories, and references the collection parameter for context. However, it does not specify the exact top-level response layout (e.g., is it a list of categories? does it include partner metadata?) or pagination behavior. This is a reasonably complete description for a menu/catalog tool, but leaves some structure details ambiguous.

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%: both parameters (uname and market) have descriptive definitions in the schema, with uname explained as 'Restaurant slug, from a search response's uname field' and market as 'Deliveroo national market the uname was found in (default uk)'. The description adds little beyond this—it does not elaborate on parameter formats or constraints. Since the schema already does the heavy lifting, a baseline of 3 is 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?

The description opens with a clear, specific action ('Get one Deliveroo restaurant, grocery, or shopping partner's priced catalog') and distinguishes itself from search tools by referencing /deliveroo/search's collection parameter and covering all three partner types. It also implies differentiation from sibling menu tools like ubereats_store_menu by explicitly covering restaurant, grocery, and shopping catalogs.

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?

The description provides clear usage context by referencing /deliveroo/search's collection parameter, indicating this tool is used after a search to fetch a specific partner's catalog. It also states that all three catalog types use the same endpoint. However, it does not explicitly mention when not to use it or alternative endpoints (e.g., deliveroo_restaurant for basic partner info), so it lacks 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