Skip to main content
Glama
Sign In
Uber Eats MCP Server

Uber Eats MCP Server

by matiasconcha11
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

uber_eats_menu_item_detail

Retrieve a single menu item's details, including its customization options, by providing the store, section, subsection, and item UUIDs identified from the restaurant menu.

Instructions

Load one menu item with customization options (API). UUIDs come from uber_eats_restaurant_menu
item entries (section_uuid, subsection_uuid, uuid).

Args:
    store_uuid: Restaurant store UUID
    section_uuid: Section UUID from the menu item
    subsection_uuid: Subsection UUID from the menu item
    menu_item_uuid: Item UUID (catalog item)

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": {
      "store_uuid": "<store_uuid>",
      "section_uuid": "<section_uuid>",
      "subsection_uuid": "<subsection_uuid>",
      "menu_item_uuid": "<menu_item_uuid>"
    },
    "name": "uber_eats_menu_item_detail"
  }
}

Input Schema

NameRequiredDescriptionDefault
store_uuidYes
section_uuidYes
menu_item_uuidYes
subsection_uuidYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It conveys this is a read-only fetch ('Load one menu item'), which is implied. However, it doesn't clarify what customization options are included, whether options data differs from uber_eats_get_item_options, or any pagination/response behavior. The '(API)' suffix is unclear as to what it communicates behaviorally.

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 compact with a clear Args listing that adds param semantics efficiently. The '(API)' suffix and opening sentence are slightly redundant, but overall the text is tight and properly structured with front-loaded purpose.

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

Completeness3/5

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

There is an output schema present, so return-value explanation is not required. The 4 required params are all explained via the Args block and origin note, which is helpful. However, no sibling differentiation against uber_eats_get_item_options and no timing guidance leaves some gaps for a tool fetching customization options.

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 description coverage is 0%, so the description must compensate. It explains the origin/purpose of each UUID parameter in the Args block (store_uuid=restaurant store, section/subsection/item UUIDs from menu entries), adding meaning beyond the plain 'Uuid' titles in the schema. This is useful guidance for sourcing correct values.

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 states 'Load one menu item with customization options (API)' with a specific verb+resource, which clearly conveys the purpose. It doesn't explicitly distinguish from sibling uber_eats_get_item_options and uber_eats_restaurant_menu, but the phrase 'with customization options' hints at differentiation from a plain menu fetch.

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 description notes that 'UUIDs come from uber_eats_restaurant_menu item entries' which implies a dependency/ordering for when to call this tool. However, it doesn't explicitly distinguish from the sibling uber_eats_get_item_options, which sounds potentially related, and doesn't clarify when to prefer one over the other.

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