efood-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EFOOD_LANG | No | Default language for menu/option names (e.g. "en", "el"). | en |
| EFOOD_EMAIL | No | Your efood account email for programmatic login. | |
| EFOOD_PASSWORD | No | Your efood account password for programmatic login. Sent only to efood's login endpoint. | |
| EFOOD_SESSION_ID | No | A session id captured yourself (takes priority over login). Used when programmatic login is blocked. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_restaurantsA | Find restaurants/shops that deliver to a location on efood.gr. Provide either |
| get_restaurant_menuA | Fetch a restaurant's full menu (categories + items with prices), plus opening hours, offers and discounts. Use the restaurant |
| get_menu_item_optionsA | Fetch the customization/variation options for a single menu item (e.g. size, extras). Needed to build a valid cart line for items where |
| get_addressesA | List the delivery addresses saved on your efood account. The |
| get_payment_methodsA | List the payment methods saved on your efood account (e.g. stored cards, as opaque tokens). Use a returned payment token with place_order. This is read-only and does not expose full card numbers. Requires authentication. |
| get_order_historyA | List your previous efood orders, most recent first — each with restaurant, date, total, payment method, status, and the items ordered. Optionally filter to a single restaurant (useful for re-ordering the usual). Requires authentication. |
| get_order_statusA | Retrieve the current status of an existing order by its id. Requires authentication. |
| add_itemA | Add a menu item to the shop's server-side basket by naming its options in plain language — no raw codes or price math. Give |
| get_cartA | Read the shop's current server-side basket (the one shown in the efood app): line items with names, options, quantities, prices, and total. Each line has an |
| remove_itemA | Remove a single line from the basket by its |
| clear_cartA | Delete the shop's server-side basket entirely (removes it from the efood app). Only affects the saved basket — it does not cancel any placed order. Requires authentication. |
| place_orderA | Submit the shop's server-side basket as a REAL efood order. This charges your chosen payment method and cannot be undone from here. Safety: call with confirm:false (default) first — it validates against the delivery address and returns a summary (items, total, fees, min-order); only call confirm:true after the user has explicitly approved. Card details cannot be entered here — pay with cash on delivery or a saved payment token (see get_payment_methods). |
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 12 tools
Each tool targets a distinct resource (restaurant, menu, cart, order, account) and action, with clear boundaries. Even cart-related tools are unambiguous: add_item, remove_item, get_cart, and clear_cart perform different operations on different scales.
Every tool follows the verb_noun pattern with underscores, using consistent verbs like get, add, remove, clear, search, and place. Minor singular/plural variations (e.g., get_addresses vs get_cart) are natural and do not break the pattern.
With 12 tools, the server is well-scoped for a food delivery domain. It covers restaurant discovery, menu browsing, cart management, order placement, and order tracking without unnecessary bloat or missing core actions.
The core ordering lifecycle is fully covered: search restaurants, fetch menus, customize items, manage cart, place order, and check status. Minor gaps such as editing cart line quantities or canceling an order exist, but agents can work around them (e.g., remove and re-add items).