Provides tools for searching restaurants and dishes on Glovo, including prices, ratings, delivery estimates, free delivery flags, and full venue menus.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sushimaster Find a pizza under 50 PLN with free delivery in Warsaw."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP tool for AI agents (Claude Code, Claude Desktop, Codex) that finds deals in food delivery apps. Ask your agent "find a pizza under 50 PLN with free delivery" and it will search Wolt and Glovo, compare prices, ratings, delivery estimates and promotions, and return a ready recommendation with a link.
Related MCP server: OrderFood MCP
MCP tool | Description |
| List available food delivery apps |
| Resolve an address / |
| Find restaurants (rating 0–10, ETA, free-delivery flags, promotions) |
| Find dishes with prices in cents; filter by price, rating, free delivery |
| Fetch a full restaurant menu (discounted items included) |
No login, no API keys — data comes from the public Wolt and Glovo endpoints.
Prices are normalized to cents (int), ratings to a 0–10 scale.
Every result is tagged with fetched_at and a per-provider report
(responded?, latency, warnings) so the agent can attribute the data honestly.
Results are cached (TTL) with single-flight protection.
Python 3.10+
uv (for installation and running)
cd sushimaster
uv sync --extra dev # create .venv and install dependencies (+ dev tools)This installs two console commands into .venv/bin/:
Command | Purpose |
| CLI for quick testing (resolve / venues / items / menu) |
| MCP server (stdio transport) |
To call them as plain sushimaster … / sushimaster-mcp, either activate the
virtualenv (source .venv/bin/activate) or add .venv/bin to your PATH.
Alternatively, use uv run sushimaster … from the project directory.
sushimaster resolve "Warszawa, Marszałkowska 98"
sushimaster venues "pizza" "52.2297,21.0122" --apps wolt,glovo --free-delivery
sushimaster items "pizza margherita" "Warszawa" --max-price 5000 --min-rating 8
sushimaster menu glovo "dodo-pizza-waw" "52.2297,21.0122"sushimaster-mcpClaude Code configuration (claude mcp add):
claude mcp add sushimaster -- /path/to/sushimaster/.venv/bin/sushimaster-mcpOr in ~/.claude.json:
{
"mcpServers": {
"sushimaster": {
"command": "/path/to/sushimaster/.venv/bin/sushimaster-mcp",
"args": []
}
}
}Once connected, try: "Find a pizza under 50 PLN with free delivery in Warsaw."
This section is written for AI agents (Claude Code, Codex, Claude Desktop) that need to install and use Sushimaster. Follow the steps in order.
Python 3.10+ — check with python3 --version
uv — check with uv --version
git — check with git --version
git clone <repository-url> sushimaster
cd sushimaster
uv sync --extra dev # creates .venv/ and installs the packageThis produces two executables in .venv/bin/: sushimaster (CLI) and
sushimaster-mcp (MCP server). Remember the absolute path to
sushimaster-mcp — you will need it in step 2. Get it with:
echo "$(pwd)/.venv/bin/sushimaster-mcp"Pick the section matching your agent.
Claude Code (project-scoped, recommended):
claude mcp add sushimaster -- /absolute/path/to/sushimaster/.venv/bin/sushimaster-mcpThen restart Claude Code and verify with /mcp — the sushimaster server
should be listed as connected with 5 tools.
Claude Code (alternative — .mcp.json in the project root, committed to
the repo):
{
"mcpServers": {
"sushimaster": {
"command": "/absolute/path/to/sushimaster/.venv/bin/sushimaster-mcp",
"args": []
}
}
}Codex:
codex mcp add sushimaster -- /absolute/path/to/sushimaster/.venv/bin/sushimaster-mcpClaude Desktop — add the same mcpServers entry to
claude_desktop_config.json (Claude → Settings → Developer → Edit config),
then restart Claude Desktop.
Do not use
uv runorpython -mas thecommand— the installed script is self-contained and avoids spawning an extra process.
From the shell:
/absolute/path/to/sushimaster/.venv/bin/sushimaster resolve "Warszawa"Expected: JSON with lat, lon, label and country_code: "PL".
From the agent, ask: "list your available tools" or call list_providers.
Expected: [{"name": "wolt", "display_name": "Wolt"}, {"name": "glovo", "display_name": "Glovo"}].
Then run an end-to-end query:
"Find a pizza margherita under 40 PLN in Warsaw and list the results with prices."
Tool | Purpose | Key parameters |
| Available apps | — |
| Address / |
|
| Restaurants |
|
| Dishes |
|
| Restaurant menu |
|
Conventions the agent should follow when answering users:
Prices are in cents — divide by 100 for PLN (e.g. 3699 → 36.99 zł).
Ratings are 0–10.
Always mention the source app (Wolt/Glovo) and the delivery flag
(free_delivery) for each recommendation.
venue_id from search results can be passed straight to get_venue_menu.
Read the warnings array — it may explain partial data (e.g. Wolt menu
previews) or failed providers.
cd sushimaster
uv run pytest # offline tests on frozen API fixtures
uv run pytest -m live # optional: live tests against real APIsSymptom | Fix |
| Run |
MCP server listed as failed | Restart the agent; verify the absolute path has no symlinks/quotes |
|
|
Tools return empty |
|
No results for a city | The app may not cover that city (Glovo is limited to larger cities in Poland) — try |
Variable | Default | Description |
|
| Result cache TTL in seconds |
| empty (all) | Active providers, comma-separated, e.g. |
|
| Minimum interval between API requests (seconds) |
|
| HTTP request timeout (seconds) |
src/sushimaster/
├── server.py # MCP server (FastMCP) + tool definitions
├── service.py # orchestration: caching, filtering, dedup, reports
├── geo.py # address → coordinates (multi-provider resolution)
├── models.py # shared, normalized schema (Venue, MenuItem, …)
├── cache.py # TTL cache with single-flight
└── providers/
├── base.py # BaseProvider — the contract for new providers
├── wolt.py # Wolt adapter
└── glovo.py # Glovo adapterCreate src/sushimaster/providers/<name>.py subclassing BaseProvider.
Set name / display_name and implement the three abstract methods:
search_venues(query, location, *, limit) -> list[Venue]
search_items(query, location, *, limit) -> list[MenuItem]
get_venue_menu(venue_id, location) -> MenuFetchResult
Optionally implement geocode() and check_availability().
Register the class with the @register decorator and add the module import
in providers/__init__.py (importing the module runs the decorator).
Done — caching, filtering, dedup and the MCP tools pick it up automatically.
Every provider gets, for free: HTTP with retry/backoff and error mapping
(429 → RateLimitError), an enforced minimum interval between requests,
price parsing (_to_cents handles "36,99 zł", 3699, 36.99) and rating
normalization (_normalize_rating maps "98%" → 9.8).
The full contract is documented in the providers/base.py docstring.
Full Wolt menus require a web session; the adapter returns dish previews from the restaurant list and always reports this as a warning. Glovo provides complete menus.
Wolt delivery fees are calculated dynamically at the basket level — the
adapter exposes approximation flags (delivery_price_highlight, Wolt+).
Glovo returns the real fee and the isFreeDeliveryFee flag directly.
Personal promotions (discount codes, Wolt+/Prime prices) require an authenticated session and are not visible to this tool.
Glovo coverage in Poland is limited to larger cities.
The tool only reads public data (venues, menus, prices) from provider APIs.
It performs no authentication and stores no user data on disk.
The in-memory result cache holds only public search results and expires automatically (TTL).
No telemetry, no tracking, no third-party services — geocoding is done through the providers' own endpoints.
uv run pytest # offline tests on frozen API responses (fixtures)
uv run pytest -m live # live tests against the real APIs (1s request interval)Offline tests use fixtures from tests/fixtures/ — real API responses captured
during development, so parser regressions are caught without the network.
To regenerate fixtures, capture fresh API responses and replace the files.
Note: in environments with
PYTHONPATHset (e.g. ROS), run pytest withPYTHONPATH=to avoid loading unrelated plugins.
Sushimaster is an unofficial project. It is not affiliated with, endorsed by, or sponsored by Wolt or Glovo. The provider endpoints are public but undocumented and may change or require authentication at any time; use the tool at your own risk and respect each platform's terms of service and rate limits (the built-in request pacing is there to help with that).
Returns the list of available food delivery apps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Returns', which signals a read-only operation with no side effects, but it does not disclose whether authentication is needed, ordering, or other behavioral aspects. The simplicity of the tool makes this acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is intentionally simple with no parameters and an output schema present. The description fully covers the tool's purpose, and additional behavioral details are unnecessary given the output schema handles return value specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not relevant. Per the rubric, a baseline of 4 is appropriate for 0-parameter tools. The description does not need to explain any input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and identifies the resource as 'list of available food delivery apps'. This clearly distinguishes it from sibling tools like search_venues and get_venue_menu, which focus on searching or menus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool returns available food delivery apps, but it does not explicitly state when to use it or mention alternatives. Since the tool has zero parameters, the context is clear enough to infer use before searching for venues or items, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves an address (e.g. 'Warszawa, Marszałkowska 98') or 'lat,lon' to coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that input is resolved to coordinates, but omits potential failure modes, output format details, whether network calls are involved, or any limitations. This is minimal disclosure beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and provides examples without any extraneous wording. It is concise and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema present, the description covers the essential purpose and input flexibility. It lacks explicit usage guidelines and behavioral details, but these are secondary given the tool's simplicity and the presence of an output schema. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema simply defines 'address' as a string with no description. The tool description adds substantial meaning by clearly stating the parameter can be either a human-readable address or a 'lat,lon' pair, with a concrete example. This fully compensates for the schema's lack of parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb 'Resolves' with a clear resource ('an address ... or 'lat,lon'') and the outcome ('to coordinates'). Concrete examples ('Warszawa, Marszałkowska 98') and the explicit 'lat,lon' format make the purpose unmistakable and distinguish it from sibling tools that list providers, search venues, search items, or get venue menus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario by showing acceptable input formats, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. For example, it does not say whether to use this before search_venues or if you already have coordinates to use elsewhere. This is adequate but lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for dishes matching the query (e.g. 'pizza margherita').
Parameters: query - text query address - an address or "lat,lon" (or provide latitude+longitude) max_price_cents - maximum price in cents (e.g. 5000 = 50 PLN) min_rating - minimum restaurant rating (0-10) free_delivery - True = restaurants with free delivery only sort - "price" | "price_desc" | "rating" apps - list of apps limit - maximum number of results
| Name | Required | Description | Default |
|---|---|---|---|
| apps | No | ||
| sort | No | price | |
| limit | No | ||
| query | Yes | ||
| address | No | ||
| latitude | No | ||
| longitude | No | ||
| min_rating | No | ||
| free_delivery | No | ||
| max_price_cents | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. It does not state whether the operation is read-only, whether authentication is needed, or what happens if no results match. It only explains parameters, not the tool's general behavior or return conventions. This is a significant gap for a tool that likely performs external queries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of one precise sentence followed by a clear, well-formatted parameter list. Every line adds value by explaining a parameter, with no redundant fluff. It is both concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 10 parameters and an output schema, the description covers the input semantics reasonably well but lacks broader contextual details such as typical use cases, filtering behavior, pagination, or any caveats about location-based searches. It is adequate for a straightforward search tool but does not fully orient an agent on how to interpret results or handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description is the only source of parameter meaning. It adds useful details: examples for max_price_cents (5000 = 50 PLN), a scale for min_rating (0-10), explanation of free_delivery (True = restaurants with free delivery only), and the list of sort options. It also mentions latitude/longitude as an alternative to an address. However, it does not elaborate on the 'apps' parameter beyond saying 'list of apps,' and latitude/longitude are not listed as distinct named parameters, though they are referenced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Searches for dishes matching the query.' This clearly distinguishes it from sibling tools like search_venues (which searches venues) and get_venue_menu (which retrieves a menu). The example 'pizza margherita' further reinforces the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching dishes, which gives clear context for when to use it, but it does not explicitly state when not to use it or mention alternatives. No exclusions or comparisons to siblings are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for restaurants matching the query (e.g. 'pizza').
Parameters: query - text query (e.g. "pizza", "sushi") address - an address or "lat,lon" (or provide latitude+longitude) apps - list of apps, e.g. ["wolt", "glovo"]; defaults to all free_delivery - True = free delivery only min_rating - minimum rating (0-10) limit - maximum number of results (per provider when querying)
| Name | Required | Description | Default |
|---|---|---|---|
| apps | No | ||
| limit | No | ||
| query | Yes | ||
| address | No | ||
| latitude | No | ||
| longitude | No | ||
| min_rating | No | ||
| free_delivery | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses some traits (apps defaults to all, limit is 'per provider'), but lacks information on permissions, pagination, rate limits, error handling, or how conflicting address and latitude/longitude inputs are resolved. This is insufficient for a search tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. The parameter list is structured clearly with one line per parameter, each accompanied by a practical example. No redundant content or unnecessary detail is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the search semantics and most parameters, and the output schema handles return values. However, it lacks usage guidelines and omits explicit mention of the latitude/longitude parameters. For a tool with this complexity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for query, address (including 'lat,lon' format), apps, free_delivery, min_rating, and limit with examples. However, latitude and longitude are only implied through 'or provide latitude+longitude' and are not explicitly named, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Searches for restaurants matching the query' with a concrete example ('pizza'). This distinguishes it from sibling tools like search_items (items) and get_venue_menu (menus), making the resource and verb specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. There is no mention of using search_items for item-level searches or list_providers for provider discovery. The parameter explanations imply usage but do not state exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_venue_menulist_providersresolve_locationsearch_itemssearch_venuesScored across 5 tools
Each tool serves a distinct purpose: listing providers, resolving locations, searching restaurants, searching dishes, and fetching menus. There is no overlap in functionality, and the parameters are tailored to each operation.
All tool names follow a consistent verb_noun pattern: list_providers, resolve_location, search_venues, search_items, get_venue_menu. The verbs are specific and the nouns clearly indicate the resource.
With 5 tools, the server is well-scoped for food delivery discovery. Each tool covers a necessary step in the workflow without redundancy or bloat.
The tool surface covers the full discovery lifecycle: identify available apps, resolve a location, search for venues or items, and retrieve a venue menu. No obvious missing operations exist for the stated purpose.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
Furgonetka MCP Server is an extension for LLMs (such as Claude) that integrates AI assistants with Poland's most popular courier brokerage platform. The server enables models to interact directly with services from various couriers (including InPost, DPD, DHL, UPS, and Poczta Polska) through a single, unified interface. With this integration, your AI stops just "writing about logistics" and starts actually managing it.
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
An MCP server that exposes functionalities to use Zomato's services.
