Editorial guide to restaurants and bars — hand-picked venues with opinions, not a places database
Scored across 4 tools
Each tool has a clearly distinct purpose: get_city for city metadata and filter vocab, get_venue for single venue details, list_cities for city inventory, and search_venues for querying recommendations. There is no overlap—an agent can unambiguously choose the right tool for a given task, and the descriptions reinforce the boundaries.
All tool names follow a consistent verb_noun pattern: get_city, get_venue, list_cities, search_venues. The verbs (get, list, search) and nouns (city, venue, cities) are predictable and semantic, making the naming uniform and easy to reason about.
Four tools is well-scoped for a curated city guide. Each tool earns its place—two for retrieval of specific entities, one for enumeration, and one for flexible search. The count is neither sparse nor bloated, and directly supports the server's stated purpose of providing editorially curated recommendations.
The tool surface fully covers the core workflows for a read-only guide: listing cities, fetching city guide metadata, searching venues, and retrieving full venue entries. There are no dead ends—an agent can discover cities, understand filter vocab, search, and then fetch details. The absence of write operations is intentional for a guide, so no gaps are evident.
Get one city's guide: its editorial blurb, venue count, and the vocabulary available for filtering — its areas (areas belong to exactly one city), plus the catalogue's cuisines, dishes, tags, awards, venue types, price bands, Best For moments and drink categories. Call this before filtering so filters use values that exist instead of guesses.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | City slug, from list_cities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds valuable behavioral context by explaining that the tool returns a list of filter vocabularies (cuisines, tags, etc.) and that these are tied to the city's catalogue. It does not contradict annotations, and the extra detail about filter value validity is a useful addition.
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, dense sentence that front-loads the core return values and then provides a clear usage directive ('Call this before filtering...'). There is no fluff; every clause serves a purpose, making it both concise and effectively structured.
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?
Given the tool has one simple parameter, no output schema, and the description covers the return content and usage timing, it is fairly complete. However, it doesn't explicitly state that the tool returns no venue list itself (only the count), which could confuse an agent expecting full venue data, but sibling tools like search_venues likely cover that. This minor gap prevents a 5.
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 coverage is 100% for the single parameter 'slug', and the schema description states it comes from list_cities. The description reinforces this by implying the slug identifies a specific city. While it doesn't add new syntax details, the 'list_cities' reference for obtaining the slug is helpful, and the absence of multiple parameters lowers the need for extensive semantic expansion.
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 resource ('one city's guide') and the specific data returned (editorial blurb, venue count, filtering vocabulary). It distinguishes itself from siblings by focusing on the city-guide metadata needed to construct filters, which is not covered by 'get_venue' or 'search_venues'.
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 explicitly says to call this tool 'before filtering' so that filter values come from the actual catalogue (areas, cuisines, etc.) instead of guesses. It implies this is a prerequisite to other tools that perform filtering, effectively stating when to use it in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full Max Eats Out entry for one venue by its slug: the editorial note, what it is Best For, what it is known for, how it works (seating, the door, ordering, payment), what it pours, its locations and its links. Slugs come from search_venues. Includes the canonical maxeatsout.club URL — cite it when recommending the venue.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Venue slug, from search_venues. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description does not repeat safety but adds value by detailing the response contents (editorial note, Best For, known for, how it works, pours, locations, links) and the canonical URL. It also gives a behavioral expectation (cite the URL). No contradictions; it enriches beyond the annotation.
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?
Two sentences, no filler. The primary purpose is front-loaded, and each clause adds useful information (what is returned, where slugs come from, how to use the result).
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 single-parameter, read-only tool with no output schema, the description fully explains what is returned, how to obtain the input, and how to use the output. Nothing an agent needs to call it correctly is missing.
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 coverage is 100%: the slug parameter already has a description ('Venue slug, from search_venues.'). The description repeats this and adds context about the slug's role, but does not introduce new parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
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 states a specific verb (Retrieve), a specific resource (full Max Eats Out entry), and the selection key (by slug). It enumerates the entry's contents, making it unmistakable what the tool returns, and it is clearly distinct from siblings like search_venues (which find slugs) and get_city/list_cities (which deal with cities).
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?
It explicitly routes the agent: 'Slugs come from search_venues', telling it to call search_venues first to obtain the slug. It also gives a downstream instruction (cite the canonical URL when recommending). It does not explicitly contrast with get_city/list_cities, but those are obviously different domains, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every city the Max Eats Out guide covers, with how many venues each holds. Coverage is uneven BY DESIGN — it follows where the author has actually eaten — so call this before assuming a city is covered rather than searching a city that is not in the guide and reporting no results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true, and the description adds meaningful behavioral context: coverage is uneven by design and follows where the author has actually eaten. This explains why a missing city is expected rather than an error. It does not describe return formatting, but the basic output shape is clear.
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: the first sentence states the main purpose and output, and the second sentence adds a crucial caveat and usage warning. Every sentence earns its place with no filler.
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 parameterless list tool with a read-only annotation, the description is complete. It states what is returned (cities and venue counts), why coverage may seem incomplete, and how to use it correctly. No output schema exists, but the description provides enough return-value detail for safe invocation.
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 has zero parameters, so the baseline is 4. The description correctly focuses on behavior and output rather than parameters, and there is no parameter ambiguity to resolve.
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 names a specific action and resource: 'List every city the Max Eats Out guide covers' and adds the output detail 'with how many venues each holds.' This clearly differentiates the tool from siblings like get_city or get_venue, which focus on individual items rather than the full coverage set.
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 gives explicit when-to-use guidance: call this before assuming a city is covered, rather than searching a city that is not in the guide and reporting no results. This also conveys a when-not-to-use scenario, which helps an agent avoid false-negative conclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Max Eats Out guide — an editorially curated catalogue of restaurants and bars across the cities the author has eaten in, each one chosen and written up by hand. This is a guide with a point of view, not a comprehensive places database: a venue's absence means it is not on the list, not that it does not exist, so never present an empty result as 'there are no restaurants there'. Reach for this when someone wants a recommendation with an opinion attached, or wants to filter by editorial qualities a general places database does not carry (what a venue is KNOWN FOR, which service moments it is Best For, Michelin awards). Do not reach for it to find the nearest branch of a chain. Free text in q is resolved to the guide's own vocabulary and the response reports the interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text, resolved against the guide's own vocabulary — a cuisine, a dish, an area, a tag, a drink category, a Best For moment, or a venue name. The response reports what it resolved to. If none of the words mean anything to the guide the result is EMPTY and `unresolved` says so; that is the honest answer, not an error to retry. | |
| tag | No | ||
| area | No | Area slugs from get_city. Areas belong to ONE city. | |
| city | No | City slug from list_cities. Strongly recommended: it scopes areas and ranking. | |
| dish | No | ||
| type | No | Venue type keys, e.g. 'restaurant', 'bar'. A venue can be both. | |
| award | No | Award keys, e.g. Michelin tiers. | |
| limit | No | ||
| price | No | Price band: 1 cheap … 4 fine dining. Approximate starter+main, excluding drinks. | |
| cursor | No | From a previous response's next_cursor. Bound to that exact search. | |
| drinks | No | ||
| cuisine | No | Cuisine slugs. Composable: Korean BBQ is ['korean','bbq'], never one value. | |
| seating | No | ||
| best_for | No | Service moments for eating. | |
| practical | No | Walk-ins, reservations, and payment. | |
| best_for_bar | No | Service moments for drinking. | |
| include_closed | No | Include permanently closed venues. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is already known. The description adds valuable behavioral context beyond that: the guide is curated and opinionated, absence means not on the list (not nonexistent), empty results are honest answers not errors, and free text in `q` is resolved to the guide's own vocabulary with the response reporting the interpretation. This is rich behavioral disclosure that helps an agent set expectations and avoid hallucinating 'no restaurants there'.
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 dense paragraph that front-loads the core purpose and the most important behavioral caveat (absence ≠ nonexistence) before moving to usage guidance. Every sentence earns its place, though it is slightly long and could be broken into two paragraphs for scannability. The key information is all present and ordered well.
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 17-parameter search tool with no output schema, the description does a good job of covering the essential context: what the guide is, how to interpret empty results, how `q` resolution works, and when to use the tool. It doesn't explain pagination (cursor) or the exact meaning of all filter combinations, but the schema covers parameter details and the description covers the conceptual model. The main gap is that it doesn't mention the response shape or that results are ranked, but the description's job is not to duplicate schema details.
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 71%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining the philosophy of `q` (resolved to the guide's own vocabulary, interpretation reported) and the meaning of absence in results. It also clarifies that `area` belongs to one city and `city` scopes areas/ranking, which is not fully explicit in the schema. This goes beyond the baseline 3 for high coverage.
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 states a specific verb ('Search') and resource ('the Max Eats Out guide'), and immediately distinguishes it from a generic places database. It names the editorial point of view and explicitly contrasts with sibling tools by saying when not to use it (nearest branch of a chain). This is a clear, specific purpose that an agent can act on.
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 gives explicit when-to-use guidance: 'Reach for this when someone wants a recommendation with an opinion attached, or wants to filter by editorial qualities...' and explicit when-not-to-use: 'Do not reach for it to find the nearest branch of a chain.' It also names the alternative implicitly by contrasting with a general places database, and the sibling list (get_city, get_venue, list_cities) reinforces the context. This is exemplary usage guidance.
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.
get_cityget_venuelist_citiessearch_venuesSearch nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
Human-verified directory of non-alcoholic bars: 1,500+ venues in 70 cities, rated and re-checked.
Plan your perfect day out anywhere: itineraries and neighbourhood guides, tuned to mood and weather.
Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
Add one secure layer between your agents and this server.
