No user-submitted related servers found.
Scored across 13 tools
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.
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.
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.
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.