Uber Eats MCP Server

Overview Schema Source Related Servers Discussions Admin

uber_eats_list_profiles

List Uber account profiles such as Personal, Business, and Family, and identify which profile is currently active for ordering.

Instructions

List Uber account profiles (Personal, Business, Family, etc.) and which is selected.
Use uber_eats_switch_profile to change the active profile before ordering.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "uber_eats_list_profiles"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 3, 2026

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden of behavioral disclosure. It hints at being read-only via 'List' and 'which is selected,' which is helpful, but it does not describe the output shape, whether profiles require authentication, or any auth-related prerequisites.

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?

Two sentences, zero filler. The first states the purpose and scope; the second gives actionable cross-reference to the switch tool. Every sentence earns its place.

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 simple zero-parameter listing tool, the description is reasonably complete: it states what it lists, what selection info is returned, and points to the next-step tool. It could be slightly richer on output format given the presence of an output schema, but the output schema mitigates that.

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?

The tool has zero parameters, so the description carries no parameter-documentation burden. Any instruction on what the listing entails is sufficient for a no-arg tool; the description adequately conveys the semantic scope (profiles + selection state).

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 uses a specific verb+resource ('List Uber account profiles... and which is selected'), clearly distinguishing this read-only listing tool from related siblings like uber_eats_switch_profile and uber_eats_saved_addresses. It names the profile types (Personal, Business, Family) to ground the concept.

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 implies usage context (before ordering, to identify the active profile) but does not explicitly state when-not-to-use or provide alternative selection guidance beyond a single mention of the switch tool. The reference to uber_eats_switch_profile gives a direction but lacks explicit criteria.

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

Deploy Server