@striderlabs/mcp-lyft
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Check current connection and session status — shows login state, saved route, and session info. |
| loginA | Authenticate with Lyft using email/phone and password. Saves session cookies for future requests. |
| logoutA | Clear saved session, cookies, and route data. |
| set_pickupB | Set the pickup location for your ride. |
| set_destinationB | Set the destination for your ride. |
| get_fare_estimateA | Get fare estimates for the current pickup and destination. Both locations must be set first. |
| get_ride_optionsA | Get available Lyft ride types (Lyft, Lyft XL, Lux, Lux Black, etc.) for the current route. |
| request_rideA | Request a Lyft ride. Returns a confirmation preview by default — set confirm=true to actually book the ride. |
| get_ride_statusB | Get the status of your current or most recent Lyft ride. |
| cancel_rideA | Cancel a pending or active Lyft ride. |
| get_ride_historyB | Get recent Lyft ride history. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools have clearly distinct purposes, but 'status' and 'get_ride_status' could be confused at first glance. Descriptions clarify that 'status' is about session/login state, while 'get_ride_status' is about a specific ride, so the ambiguity is minimal.
Tool names mix standalone verbs (login, logout, status) with verb_noun patterns (set_pickup, get_fare_estimate, request_ride). The inconsistency is noticeable but still readable, with clear conventions for core operations.
With 11 tools, the server is well-scoped for a Lyft ride-hailing workflow, covering authentication, trip setup, fare estimation, booking, status, cancellation, and history. Each tool serves a clear purpose without unnecessary bloat.
The core ride lifecycle is well covered: login, set pickup/destination, estimate/options, request, status, cancel, and history. Minor gaps include no explicit ride-type selection in request_ride (only via get_ride_options) and lack of payment management, but these are workable.