Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LOG_LEVELNoLogging level. Default INFO.
UBER_MAX_FARENoThe most one ride may cost, a currency code and an amount (`USD 80`, `EUR 45.50`); booking is off without it. Must be set together with UBER_MAX_FARE_24H.
UBER_LOGIN_URLNoThe login service on a private network, a name and port such as `http://uber-mcp-login:8080` (for `uber-mcp admin login`). Requires UBER_LOGIN_TOKEN.
UBER_STATE_DIRNoThe session, budget, pause, booking ledger and audit log. Defaults to a per-user folder (see Privacy); `/state` in the image.
MCP_BEARER_TOKENNoOne or more tokens (comma-separated, at least 16 characters each), so one can be rotated while the other still works. Required for `serve` (streamable HTTP) mode.
UBER_LOGIN_TOKENNoThe login service's bearer, 32 or more characters; required with UBER_LOGIN_URL.
UBER_SESSION_KEYNo32 random bytes, base64: the session is stored sealed (AES-GCM) as `session.bin`; recommended on servers.
UBER_DAILY_BUDGETNoUber requests per day (resets 00:00 UTC). Default 1500.
UBER_MAX_FARE_24HNoThe most all rides booked through this server in any 24 hours may cost, same currency; booking is off without it. Must be set together with UBER_MAX_FARE.
UBER_LOGIN_VIEW_URLNoWhere the person opens the login service's view page. Default `http://localhost:8766`.
UBER_KEEPALIVE_SECONDSNoHow often an idle session is refreshed by reading both of Uber's sites (60 to 86400). Default 14400.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
uber_placesA

The rider's saved places (no query: Home and any the rider named, with their labels), or Uber's place search (query; around near, else around Uber's guess of the rider's position). Each place has an id (a Google place id) to pass as a pickup or drop-off, a name and address, and for airports the terminals per airline.

uber_ride_optionsA

Every ride option Uber offers for this trip right now: name, tier, seats, live price (fixed upfront price, or a range for a metered taxi), pickup ETA and arrival time, with the pickup and drop-off as Uber matched them (check them; free-text matches list alternatives). For a future pickup supply pickup_at AND timezone: returns native Reserve prices and terms, never current fares. Read-only; use uber_request_ride for now, uber_reserve_ride for future pickup.

uber_request_rideA

Request a real Uber ride, in two calls. Without confirm: a preview with the current price, the places, the payment method and a confirm_token; nothing is booked. With confirm (after the person's explicit yes to that preview, same arguments): books it, unless the price rose (a fresh preview comes back instead) or a cap would be passed. Sends a car and charges the payment method.

uber_reserve_rideA

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.

uber_reservationA

Read a reservation by reservation_id (from booking or uber_trips.upcoming). Returns Uber's status, pickup time/zone, driver assignment and trip ID. Missing data is not proof of cancellation.

uber_cancel_reservationA

Cancel a specific future reservation. Without confirm: preview the reservation and current cancellation fee. After approval: same id and confirm token. Changed terms require a new preview; cancellation remains available while booking is frozen. Never retry an unknown outcome without checking Uber.

uber_ride_statusA

Read a fresh snapshot of the current ride. trip.pickup_arrival gives the car's state, eta_minutes and estimated_at when approaching pickup; arrived means the car is already there. Once OnTrip, trip.destination_arrival gives eta_seconds and estimated_at for destination arrival. checked_at is when the server read the estimate; times use ISO 8601 UTC and estimates can change. Missing estimates are unavailable, never zero. Also driver, car/plate, PIN, fare and stops. state alone when no ride exists. Use this same read-only tool for 'when will my car arrive?' and 'when will we reach the destination?'.

uber_cancel_rideA

Cancel the current ride, in two calls. Without confirm: the ride and Uber's cancellation notice (any fee) with a confirm_token; nothing is cancelled. With confirm (after the person's yes): cancels it.

uber_tripsA

Upcoming (first page) and past trips, newest first. Page back with next_cursor. include_details adds each past ride's category, receipt vehicle, route and offset-bearing times in details; costs one extra paced read per past ride. Missing trips have details_error; other errors stop the call. Times on cancelled/upcoming rides may be requested or scheduled times, never proof of travel.

uber_tripA

One trip: status, fare, ride category (product), receipt vehicle description/year when supplied, driver, pickup/drop-off/stops, distance and duration. times has ISO 8601 begin_at/dropoff_at in the requested zone (default UTC); started_at/ended_at retain Uber's original text. Cancelled/upcoming begin times may be requested/scheduled, never proof of pickup. A receipt vehicle description can just repeat the category; never infer a make, model or plate that Uber did not supply.

uber_accountA

The signed-in rider: first name, rating, completed trips, Uber One, payment methods (id, name, type, which one the app uses), Uber Cash, any money owed, and this server's booking caps.

uber_connectA

The authenticated My connections link. Give the person the url and nothing else. The account owner starts their own Uber sign-in from that page; asking for this link starts, replaces and cancels nothing. Use it when a tool says not_signed_in or session_expired, or when the person asks to connect Uber.

uber_statusA

Sign-in state (signed_in, generation, when proven, cookie expiry), today's request budget, any pause after Uber pushed back, booking caps and spend, last_error (the newest failure no later success has cleared) and sign_in_links (whether uber_connect can make a sign-in link). check=true adds the cached canary.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 13 tools

Disambiguation4/5

The set is split cleanly along real axes: now vs. future vs. read-only pricing (uber_request_ride / uber_reserve_ride / uber_ride_options), cancel now vs. cancel future (uber_cancel_ride / uber_cancel_reservation), list vs. single trip vs. reservation (uber_trips / uber_trip / uber_reservation), and auth vs. profile vs. server health (uber_connect / uber_account / uber_status). A couple of near-homographs remain — uber_reservation vs. uber_reserve_ride, and uber_status vs. uber_ride_status — where an agent could plausibly reach for the wrong tool before reading the description. Descriptions do explicitly cross-reference and redirect, which rescues most of that overlap.

Naming Consistency4/5

All tools share a uniform uber_ prefix and snake_case, and there is an implicit and mostly respected convention: verb-led names for mutations (request_ride, reserve_ride, cancel_ride, cancel_reservation, connect) and bare nouns for reads (account, places, trips, trip, status, reservation). The deviations are the noun forms uber_ride_options and uber_ride_status, which mix the noun convention with an extra qualifier, and the confusingly similar reserve_ride/reservation pair.

Tool Count5/5

Thirteen tools for a rideshare domain of this breadth is well-scoped, with each tool owning a distinct action or resource. Nothing looks padded: even the auth and diagnostic tools (uber_connect, uber_status) earn their place because every booking tool can fail with not_signed_in or a cap.

Completeness4/5

The core lifecycle is covered end to end: discover places, compare products and fares, book now or schedule, poll live trip state, cancel either kind, and review history. The main gaps are post-ride actions — no rating, tipping, receipt/expense retrieval, lost-item or support flows — and no way to modify an existing reservation other than cancel and rebook. These are workarounds rather than dead ends, since cancel+reserve covers the modification case.

Maintenance

ActivityNo data
ResponsivenessOutdated data