UberSync MCP Server
# UberSync MCP Server
## Demo links
Open the local UberSync ride-booking UI here:
<http://localhost:3001/ride-home>
Open the live UberSync ride-booking UI here:
<https://long-kids-call.loca.lt/ride-home>
UberSync is an Uber-style MCP experience for choosing pickup and destination,
comparing ride options, selecting solo or shared rides with ShareMatch AI,
tracking a moving driver with live ETA updates, and completing the ride with
payment and receipt details.
## Product overview
UberSync brings a complete ride-booking workflow to an interactive MCP
application. It connects a polished frontend experience with NitroStack server
tools for locations, pricing, ride lifecycle management, driver tracking, and
trip receipts.
## Key features
- Pickup and destination selection with Chennai demo locations
- Route, fare, ride-option, and travel-time estimates
- Solo rides and ShareMatch AI shared-ride fare splitting
- Driver assignment with vehicle details and dynamic ETA
- Simulated real-time driver movement and trip progress
- Start trip, cancel ride, complete ride, payment, and receipt flows
- Trip history, saved places, safety information, and support tools
## Technology stack
- NitroStack MCP for server tools, resources, prompts, and widgets
- TypeScript for the MCP server
- React and Next.js for the widget application
- Tailwind CSS for the frontend styling
## Demo workflow
1. Open the local UberSync MCP application.
2. Select a pickup location and destination.
3. Review the route, duration, fare, and ride options.
4. Choose a solo ride or use ShareMatch AI.
5. Confirm the ride and view the assigned driver.
6. Track the driver, start the trip, and follow its progress.
7. Complete the ride and view payment and receipt details.
## MCP capabilities
The server exposes tools for location search, ride estimates, ride selection,
booking, driver information, ride status, driver location, trip completion,
cancellation, trip history, receipts, saved places, payments, safety, and
support. Resources and prompts provide pricing information, service-area data,
safety guidance, help instructions, and guided ride workflows.
Widget source and the widget manifest are available under `src/widgets`.
## Demo-mode disclaimer
The default demo mode uses safe, deterministic simulated locations, drivers,
ride movement, payment methods, and receipts. It does not book a real Uber ride
or charge a real payment method. The optional live API adapter requires valid
authorization and should be tested only with the appropriate sandbox settings.
## Buildathon positioning
> I built UberSync MCP using NitroStack.
## Credits
Built as an Uber-inspired MCP proof of concept for the NitroStack Buildathon.
## Quick start
```bash
npm install
npm run dev
```
For the presentation, run `npm run demo` and keep `DEMO_MODE=true`.
This gives a deterministic, shared UberSync ride state with no external credentials.
To use the official API instead, set `DEMO_MODE=false` and
`UBER_ACCESS_TOKEN`. The official Uber API uses OAuth 2.0 rather than a normal API key. Request
the scopes needed by the tools you use: `request` for booking and live ride
status, `history` for trip history, `request_receipt` for receipts, and
`places` for Home/Work saved places. Use `UBER_API_ENV=sandbox` while testing;
the production request endpoint may create a real ride and charge the rider.
This optional integration adapter has not been verified here with authorized
Uber credentials.
## Production build
```bash
npm run build
npm run start:prod
```
The NitroStack CLI defaults to STDIO in development. Set `NODE_ENV=production`
or `MCP_TRANSPORT_TYPE=http` when an HTTP transport is needed.
## NitroStudio
The installed NitroStack CLI v1.0.15 does not start Studio or serve a Studio
page. `npm run dev` starts the TypeScript watcher and the widget dev server on
`http://localhost:3001`; it reports STDIO because the standalone NitroStudio
client launches/connects to the MCP project subprocess.
Open the standalone NitroStudio app (download page:
<https://nitrostack.ai/studio>), select this project folder, and click
**Connect**. Studio uses local project access for STDIO and loads the widget
iframe from port 3001. There is no CLI tunnel or bridge in this CLI version.
The hosted download page itself cannot execute this local project.
The widget app can also be built on its own:
```bash
npm --prefix src/widgets run build
```
For an HTTP MCP client, use:
```bash
MCP_TRANSPORT_TYPE=http HOST=127.0.0.1 PORT=31337 DEMO_MODE=true npm run start:prod
```
The endpoint is `http://127.0.0.1:31337/mcp`.
In live mode, the Uber Rider API does not expose arbitrary nearby-driver lists,
standalone driver profiles, or payment-method CRUD. Demo mode supplies safe
fictional drivers and Cash/Demo Wallet payment choices for presentation only.
Input locations include coordinates; the base app does not require a paid
geocoder or map API key.
## Links
- Uber Riders API: <https://developer.uber.com/docs/riders/references/api>
- Uber authentication and scopes: <https://developer.uber.com/docs/riders/guides/authentication/introduction>
- Docs: <https://docs.nitrostack.ai>
- NitroStack CLI: <https://docs.nitrostack.ai/cli/overview>
- NitroStack tools: <https://docs.nitrostack.ai/sdk/typescript/tools>
- NitroStack source: <https://github.com/nitrocloudofficial/nitrostack>
TDQS
Scored across 39 tools
Multiple tools are near-synonyms: get_trip_receipt, get_ride_receipt, and get_fare_breakdown overlap heavily; get_saved_places overlaps with list_saved_places; book_ride overlaps with request_ride; and get_ride_status overlaps with get_ride_details, get_driver_location, and track_driver. An agent cannot reliably distinguish these tools without reading full descriptions, and several differ only in demo-vs-real mode.
Tool names generally follow a verb_noun snake_case pattern such as get_*, list_*, cancel_*, request_*, and save_*. There are minor deviations like emergency_help and safety_details, and the heavy reuse of get_* makes names less informative, but the overall naming convention is predictable.
At 39 tools, the surface is well beyond the 25-tool threshold and feels bloated for the actual domain. Most of the extra count comes from overlapping operations, not from genuinely distinct capabilities; the set could likely be reduced to 15-20 coherent tools.
The core ride lifecycle is well covered: search, estimate, select, book, track, update destination, cancel, complete, and receipt. Minor gaps exist, such as stub demo actions for emergency help, contacting drivers, and adding payment methods, plus no explicit rating or tipping flow, but agents can generally accomplish the main workflows.