boogh-mcp
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 |
|---|---|
| geoD | Resolve place text to coords |
| food_citiesC | List covered cities |
| food_areaD | Marketing area for point |
| food_vendorsD | Nearby restaurants |
| food_vendorD | Vendor details |
| food_menuD | Vendor menu |
| food_reviewsD | Vendor reviews |
| food_placeD | Address search |
| food_reverseD | Reverse geocode |
| food_profileC | Food profile (needs login) |
| food_pendingC | Pending food orders (needs login) |
| food_detailD | Order detail (needs login) |
| food_rulesD | Basket rules for vendor (needs login) |
| food_basket_createD | Create basket (dry-run) |
| food_basket_updateC | Update basket (dry-run) |
| food_basket_deleteC | Delete basket (dry-run) |
| food_order_newD | PLACE ORDER (dry-run) |
| food_review_submitC | Post order review (dry-run) |
| food_login_sendC | Send food OTP (sends a real SMS) |
| food_login_verifyD | Verify food OTP |
| food_login_refreshC | Refresh food token |
| ride_priceC | Fare quote between two points |
| ride_requestD | REQUEST A REAL RIDE (dry-run) |
| ride_cancelC | Cancel a live ride (dry-run) |
| ride_reasonsD | Cancellation reasons |
| ride_statusD | Raw active-ride status |
| ride_ratingD | Rating state |
| ride_debtsD | Outstanding debts |
| ride_walletsD | Payment wallets |
| ride_balanceD | Wallet balance |
| ride_trackD | Active ride snapshot |
| ride_historyD | Past rides |
| ride_headsupD | Cancellation heads-up |
| ride_profileD | Passenger profile |
| ride_profile_showD | Show profile |
| ride_profile_setD | Edit profile (dry-run) |
| ride_placeD | Saved places |
| ride_place_listC | List saved places |
| ride_place_addC | Save a place (dry-run) |
| ride_login_sendC | Send ride OTP (sends a real SMS/call) |
| ride_login_verifyC | Verify ride OTP |
| ride_login_importC | Import tokens from browser |
| ride_login_refreshD | Refresh ride token |
| ride_login_guidedC | Browser-guided login |
| ride_voucher_applyD | Apply voucher (dry-run) |
| ride_debt_payC | PAY DEBT (dry-run) |
| ride_options_quoteD | Ride-options quote (dry-run) |
| ride_options_setD | Edit ride options (dry-run) |
| ride_flexiD | Flexi quote (dry-run) |
| ride_cloneC | Re-request cancelled ride (dry-run) |
| ride_blockD | Block driver (dry-run) |
| ride_boardedC | Confirm boarding (dry-run) |
| ride_carpool_acceptC | Accept carpool offer (dry-run) |
| ride_carpool_rejectC | Reject carpool offer (dry-run) |
| ride_carpool_dismissC | Dismiss carpool offer (dry-run) |
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 55 tools
Domain prefixes (food_ vs ride_) help separate the two services, but several tools have overlapping purposes: geo vs food_place/food_reverse for geocoding, ride_status vs ride_track for active ride state, and ride_price vs ride_options_quote vs ride_flexi for quotes. Descriptions are terse and do not fully clarify the boundaries.
Most tools use snake_case with a domain prefix (food_* or ride_*), but the verb/noun pattern is mixed: some tools are noun-only (ride_status, food_menu) while others are verb_noun (ride_cancel, food_basket_create). Additionally, one tool (geo) lacks a domain prefix, breaking the pattern.
With 55 tools, the set is extremely large and exceeds the 50+ threshold that indicates an extreme mismatch for an MCP server. Even accounting for two domains (ride and food), the volume is overwhelming and likely to burden an agent's selection process.
The surface covers most core workflows for both ride-hailing (login, profile, places, quotes, request, cancel, track, history, payments, carpool) and food ordering (login, profile, vendors, menus, baskets, orders, reviews). Minor gaps exist, such as no food order cancellation or past order history tool, but these are workable.