uber-mcp

Reserve a future ride

uber_reserve_ride

Destructive

Previews and confirms an Uber Reserve ride by first returning fare, route, timing, and terms for approval, then submitting only the approved proposal after fresh checks.

Instructions

Native Uber Reserve. First call: pickup, dropoff, option, exact ISO pickup_at with offset, IANA timezone, optional payment. Returns a preview only. Show the full date/time/zone, route, fare, payment and terms and wait for approval. Second call: ONLY confirm=; submits that stored proposal after fresh checks. If the price rose, nothing is submitted; review the returned fresh preview and obtain approval again. Never retry an unknown outcome. Uber holding a reservation does not guarantee a driver. No flight tracking, recurring rides, specialty products or automatic replacement bookings.

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_reserve_ride"
  }
}

Input Schema

Name	Required	Description	Default
`option`	No
`pickup`	No
`confirm`	No
`dropoff`	No
`payment`	No
`timezone`	No
`pickup_at`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.1Oct 27, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond annotations, the description discloses critical behavior: the first call is preview-only, the second call submits the stored proposal after fresh checks, and a price increase prevents submission. It also warns never to retry an unknown outcome and notes that a held reservation does not guarantee a driver, which is valuable context for a destructive, non-idempotent operation.

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?

The definition is front-loaded with the first-call/second-call flow and remains dense but purposeful throughout. Given the destructive two-step nature of the tool, the length is justified and no sentence is clearly filler.

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 an output schema available and rich annotations, the description covers the critical workflow, approval, price-change, retry, and limitation details an agent needs. It is slightly incomplete about prerequisites and how to obtain valid option/place inputs, but it is substantially complete for safe invocation.

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 carry parameter meaning, and it does name every parameter and clarify key semantics such as exact ISO pickup_at with offset, IANA timezone, optional payment, and the special confirm token usage. It still leaves gaps around the expected format or source of option, pickup, and dropoff 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 a specific verb and resource: reserving a future Uber ride, and clarifies that it is the native Uber Reserve flow. It does not explicitly distinguish itself from close siblings such as uber_request_ride or uber_reservation, so an agent must infer the difference from the name and context.

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?

It gives explicit two-call usage: first submit pickup/dropoff/option/time details to get a preview, then submit only confirm=<token> after approval. It also gives important when-not constraints such as no flight tracking, recurring rides, specialty products, or automatic replacement bookings, though it does not name sibling tools as alternatives.

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

Deploy Server