Atithi Driver Booking MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ATITHI_DB_PATH | No | Absolute path to the SQLite database file | ./atithi_dummy_dataset.db |
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 |
|---|---|
| register_driverB | Register a new driver and their vehicle in the Atithi system. |
| verify_driverB | Admin: Approve or reject a pending driver registration. |
| update_driver_detailsA | Update a driver's personal or vehicle details. Only provide fields you want to change. |
| update_driver_availabilityA | Replace a driver's entire weekly schedule. All existing entries are replaced. |
| update_driver_locationB | Update a driver's current real-time location. |
| add_preferred_driverA | Add a Verified driver to a hotel's preferred driver list. Caller must be a Hotel Manager for that hotel. |
| remove_preferred_driverA | Remove a driver from a hotel's preferred driver list. Caller must be a Hotel Manager for that hotel. |
| estimate_fareA | Calculate distance and estimated fare in INR for a ride based on pickup, drop-off, passenger count, and vehicle type. Present this fare to the guest for confirmation before calling create_booking(). |
| create_bookingA | Create a new guest ride booking with passenger count and estimated fare. Returns booking_id. Then call get_next_driver() to begin driver search. |
| get_next_driverA | Get the next best available driver for a booking. Searches Preferred Pool first, then Global Pool, matching passenger seating capacity. Returns driver & full vehicle contact info. |
| update_driver_responseA | Record a driver's response to a booking call. Updates driver score. Returns next_action: RIDE_STARTED or GET_NEXT_DRIVER. |
| timeout_driver_attemptA | Record a 30-second timeout or dropped voice call for a driver. Automatically logs 'No Response' and returns next_action: GET_NEXT_DRIVER. |
| complete_bookingA | Mark a booking as completed when the guest reaches the destination. Frees the driver and awards +10 score. |
| cancel_bookingA | Cancel a booking. If cancelled by Driver, applies a -20 score penalty. If no driver was found, set cancelled_by to 'No Driver Available'. |
| get_driver_detailsA | Get full profile, vehicle info, and performance score for a driver. |
| get_booking_statusB | Get the current status and full details of a booking, including assigned driver info. |
| list_available_driversB | List all currently available Verified drivers. Optionally filter by current location. |
| get_hotel_preferred_driversA | Get all preferred drivers for a hotel, sorted by driver score. |
| get_driver_attempt_logA | Get the full call attempt history for a booking, ordered by attempt number. |
| get_locationsA | Get all available pickup/drop locations. Optionally filter by location type. |
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 20 tools
Each tool targets a distinct resource and action, such as driver registration/verification/updates, booking lifecycle, and queries. The workflow tools (get_next_driver, update_driver_response, timeout_driver_attempt) are clearly sequenced and separated.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., verify_driver, create_booking, get_booking_status. There are no mixed conventions or vague verbs.
With 20 tools, the server is slightly above the typical 3-15 range, but each tool is necessary for the driver booking domain, covering driver management, booking workflow, and queries. The count is well-scoped for its purpose.
The tool set covers the full lifecycle: driver registration/verification/updates, booking creation, driver assignment, response handling, completion/cancellation, and a rich set of queries. No major gaps that would block core workflows.