Structured restaurant intelligence for AI platforms. 760K+ restaurants catalogued across 26 countries, 62K+ with deep 37-dimension analysis including letter grades, occasion-aware recommendations, menu insights, and neighborhood exploration. Six tools: find restaurants by name, search by location, explore area dining scenes, look up detailed profiles (3 detail tiers), ask natural language questions, and get personalized recommendations.
Scored across 6 tools
Each tool targets a distinct intent: find_restaurant (by name), search_restaurants (browse by location/filter), lookup_restaurant (by ID), recommend (final ranked answer), explore_area (aggregate stats), ask_about_restaurant (freeform Q&A). Descriptions explicitly resolve the riskiest overlap (search vs recommend, find vs search) with direct guidance on which to use when.
Five tools follow a clean verb_noun pattern (ask_about_restaurant, explore_area, find_restaurant, lookup_restaurant, search_restaurants). Only 'recommend' breaks the pattern as a bare verb, a minor deviation that stays readable and unambiguous.
Six tools is well-scoped for a restaurant intelligence server, with each tool earning its place across discovery, lookup, recommendation, area analysis, and Q&A. No redundancy or bloat.
The surface covers discovery, detail lookup, ranked recommendations, area-level stats, and per-restaurant Q&A, which handles most diner workflows. Minor gaps remain (no side-by-side comparison tool, no menu enumeration beyond Q&A, no reservation/booking), but agents can work around them.
Ask a specific question about a restaurant based on analysis of real reviews and menu data. Common questions: what to order, group suitability, dietary options, vibe/atmosphere, value assessment. Requires a restaurant_id from find_restaurant or search_restaurants. Ask one question per call. Accounts connected through Claude have a small free number of answers per day; if the result carries limit_reached, relay its message to the user as written and do not retry.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Question about the restaurant. Examples: 'What should I order?', 'Is it good for groups?', 'What are the dietary accommodations?', 'Is it worth the price?' | |
| restaurant_id | Yes | Seemor restaurant ID (UUID). Get IDs from find_restaurant or search_restaurants. |
| Name | Required | Description |
|---|---|---|
| answer | No | |
| source | No | |
| status | No | |
| message | No | |
| category | No | |
| question | No | |
| seemor_url | No | |
| restaurant_id | No | |
| restaurant_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that answers come from analysis of real reviews and menu data, that there is a daily free allowance for connected accounts, and that limit_reached must be relayed verbatim without retry. These are behavioral traits that materially affect agent behavior and are not present in annotations.
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 four sentences, tightly packed: purpose/data basis, example questions, prerequisite and question constraint, and rate-limit handling. No filler or redundancy; each sentence contributes unique guidance.
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 two-parameter tool with an output schema and annotations, the description covers the essential usage flow (obtain restaurant_id, ask one question), the data source, and the rate-limit behavior. The output schema handles return value details, so nothing an agent needs to invoke 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% and the schema already documents both parameters with examples. The description adds extra meaning by listing common question types (what to order, group suitability, dietary options) and explicitly constraining the call to one question, which clarifies the expected cardinality of the question parameter beyond the schema.
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 and resource: ask a specific question about a restaurant, and grounds it in analysis of real reviews and menu data. This clearly differentiates it from siblings like find_restaurant, search_restaurants, and recommend by focusing on post-discovery Q&A about a known restaurant.
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 provides clear use context: requires a restaurant_id from find_restaurant or search_restaurants, limits to one question per call, and gives explicit handling for the limit_reached result (relay message, do not retry). It does not explicitly name alternatives or state when not to use the tool, but the prerequisite and constraints make the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate dining statistics for a neighborhood, city, or region: cuisine breakdown, grade distribution, price range, top neighborhoods, and highlighted restaurants. Use this for area-level context ("what is the dining scene like in Shoreditch?"), NOT for finding a specific restaurant or getting a personal recommendation. For "find me a quiet Italian near Shoreditch", use the recommend tool instead. Coverage is reported honestly: coverage_level 'full' (fully analyzed rows present), 'basic' (only quick-read rows: review-analysis bands, no letter grades yet), or 'none'; analyzed_count and preliminary_count split total_restaurants, and highlights marked coverage_level 'basic' carry a preliminary_band instead of a grade. not_found means neither analyzed nor preliminary rows exist.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Whenever the conversation shows which place is meant, add its city, state or country after a comma, so a shared name needs no guess; other_places lists the others when a name is shared. |
| Name | Required | Description |
|---|---|---|
| area | No | |
| status | No | |
| message | No | |
| highlights | No | |
| place_note | No | |
| description | No | |
| other_places | No | |
| top_cuisines | No | |
| neighborhoods | No | |
| analyzed_count | No | |
| coverage_level | No | |
| price_breakdown | No | |
| preliminary_count | No | |
| total_restaurants | No | |
| grade_distribution | No | |
| analyzed_restaurants | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds rich behavioral context beyond that: how coverage_level values map to data completeness, the distinction between analyzed_count and preliminary_count, and how 'not_found' is defined. This goes well beyond the structured annotations.
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?
Although somewhat long, every sentence earns its place: core purpose, usage distinction, alternative routing, and honest coverage semantics. Information is front-loaded and logically organized, with no filler or repetition.
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 is fully complete for an area exploration tool. It covers what the tool does, how to interpret coverage status, what the output fields mean, and how to route to a sibling tool. An output schema exists for return values, and the description does not need to repeat those 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?
The input schema covers 100% of the parameter with examples and disambiguation guidance. The description reinforces that the parameter refers to a geographic area but does not add syntax, formatting, or semantics beyond what the schema already 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 starts with a specific verb and resource ('Get aggregate dining statistics') and lists concrete components (cuisine breakdown, grade distribution, price range). It explicitly distinguishes itself from sibling tools by stating it is for area-level context, not specific restaurant finding or personal recommendations.
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 clearly states when to use ('area-level context... what is the dining scene like in Shoreditch?'), when not to use ('NOT for finding a specific restaurant or getting a personal recommendation'), and names an alternative tool ('use the recommend tool instead'). This covers the full when/when-not/alternatives requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find restaurants by name. Returns matching restaurants with their Seemor IDs, which can be passed to lookup_restaurant for full details. Use the city parameter to disambiguate common names. Each result reports coverage_level: 'full' (letter grade), 'basic' (preliminary read: grade null, preliminary_band, tldr, caveat) or 'none' (no analysis yet).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Whenever the conversation shows which place is meant, include its state or country ('Vienna, Virginia'), so a shared name needs no guess. Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places). | |
| name | Yes | Restaurant name to search for (partial matches work). Example: 'Barrafina', 'Pizza Pilgrims', 'Noma'. | |
| limit | No | Maximum results to return (1-20, default 5). |
| Name | Required | Description |
|---|---|---|
| place | No | |
| status | No | |
| message | No | |
| results | No | |
| place_note | No | |
| other_places | No | |
| total_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds useful behavioral details about the return value (Seemor IDs) and the coverage_level field with its possible values and meanings, which goes beyond the schema. No contradiction with annotations.
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 three sentences with no redundant information. It front-loads the purpose and then provides parameter guidance and output explanation. Every sentence 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 has a simple purpose, and the description covers the main behavior (search by name, return IDs and coverage), parameter usage (city disambiguation), and the relationship to lookup_restaurant. Since an output schema exists, the description does not need to enumerate return fields. Missing details like pagination limits are handled by the limit parameter schema. Overall, it is complete for the agent's needs.
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 100%, so the baseline is 3. The description adds value by explaining the purpose of the city parameter for disambiguation and describing the output fields (coverage_level). It goes slightly beyond the schema without duplicating it, so a 4 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 ('find') and resource ('restaurants by name'), and clarifies that it returns Seemor IDs and coverage_level, which distinguishes it from lookup_restaurant (full details). This clearly communicates the tool's purpose and differentiates from at least one sibling.
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 provides a clear use case (finding by name, disambiguating with city) and references lookup_restaurant as a next step for full details, but it does not explicitly say when to use this tool vs search_restaurants or other siblings. The guidance is implied rather than explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a specific restaurant by its Seemor ID. Returns grade, summary, cuisine, neighborhood, and other details. Use the fields parameter to request richer data (standard or premium; fully analyzed restaurants only). coverage_level 'full' rows carry a letter grade; 'basic' rows are Seemor quick reads: review-analysis bands (grade null, preliminary_band such as 'B-range') with a one-line tldr, graded from review analysis rather than star ratings; 'none' rows have no analysis yet. Use search_restaurants or find_restaurant first to get restaurant IDs. Use this for a single place the user asks about, not for every result of recommend.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional assessments (noise, formality, authenticity, etc.), value assessment, standout strengths/weaknesses, unique selling points. | |
| restaurant_id | Yes | Seemor restaurant ID (UUID). Get IDs from search_restaurants results. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| restaurant | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent behavior, and the description adds non-obvious output semantics: coverage_level 'full' rows have letter grades, 'basic' rows use preliminary_band with grade null and are based on review analysis, and 'none' rows have no analysis. This warns agents about nulls and data quality without contradicting the annotations.
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?
Every sentence carries distinct useful information: purpose, return contents, field semantics, coverage caveats, ID acquisition, and selection guidance. The detail on coverage is dense but organized and directly relevant, 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?
With a good output schema and strong annotations, the description's added context covers prerequisite ID discovery, data-availability edge cases through coverage_level, and the appropriate scope vs siblings. Nothing needed to invoke the tool 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% and enum values are already documented, so the baseline is 3. The description adds value by tying fields/coverage levels to data availability ('fully analyzed restaurants only') and by instructing where restaurant_id comes from, which lifts it above schema-only documentation.
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: 'Look up a specific restaurant by its Seemor ID,' and enumerates the returned details. It also distinguishes itself from siblings by directing users to search_restaurants/find_restaurant first and by noting it is for a single place, not for every recommend result.
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 states when to use the tool (single restaurant by known ID), what to do first (use search_restaurants or find_restaurant to get IDs), and when not to use it ('not for every result of recommend'). It also explains when fields=standard/premium is appropriate via the 'fully analyzed restaurants only' qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a complete, ranked restaurant recommendation for a dining occasion: the final answer, not a search. Each result already carries a grade (or preliminary_band), match_reasons, caveats (a caveat beginning "Misses" names something the room does not deliver, never a good thing about it; a strong_match row never carries one), honored_constraints (plain-language labels for the stated filters this specific row confirms, e.g. "Indian", "Takeaway", "In Magnolia"), and requirements (per stated requirement, one of confirmed / contradicted / unknown, with the plain-words evidence that produced it) weighed against the request. A result may also carry place_note ("Near Williamsburg", "In Hoboken"): where that room is, present ONLY when the room is outside the place asked for — a room in the place the diner asked for carries no place_note, so never read a missing place_note as "somewhere else", and when one IS present say so rather than implying the room is in the place asked for. When result_groups is present, results is already partitioned into ORDERED, LABELED groups (exact / exact_within_wider_radius / likely_match_unconfirmed / nearby_any / relaxed_amenity) — present them to the user top to bottom, in that order, using each group's own message verbatim; never re-order the groups or the rows within a group (present rows in the order given), and never offer them as a choice. Never claim a nearby_any or relaxed_amenity row satisfies a constraint it does not carry in honored_constraints, and never call a likely_match_unconfirmed row (or any row carrying a requirement with status "unknown") a confirmed or exact match — say plainly that it likely matches but could not be confirmed from Seemor's data, and name what could not be confirmed (unknown_requirements lists it at the response level). repeat_ask: true means this is the same answer already given for the identical ask; say so rather than presenting it as new. Call it ONCE per diner ask, with the full ask (cuisine, occasion, vibe, constraints) in query and the place in location. Results are ranked and final: do not re-call with reworded variations or call lookup_restaurant on each result to double-check it; that adds latency, not a better answer. For follow-ups about one place, use lookup_restaurant or ask_about_restaurant. Accounts connected through Claude have a small free number of recommend runs per day (only runs that return results count); if the result carries limit_reached, relay its message to the user as written and do not retry. If a result carries caveats, coverage_level 'basic', or a message noting a thin pool, relay it to the user instead of searching again. Requires a location: include one in your query (e.g. "in Soho"), or provide location, or latitude/longitude, or the tool refuses with location_required instead of guessing a city.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return (1-10, default 5). | |
| query | Yes | Natural language dining request, e.g. 'quiet Italian restaurant for a date night in Covent Garden' or 'best sushi near me for a celebration'. Include the location in your query OR provide latitude/longitude. | |
| latitude | No | Latitude of search center. Alternative to location — use when you have coordinates. If both location and lat/lng are provided, location takes priority for disambiguation. | |
| location | No | City or area to bias the search toward, e.g. 'London', 'San Francisco', 'Rome'. Use this when the query doesn't include a location, or to disambiguate (e.g. 'Victoria' could be London or British Columbia — pass 'London' to clarify). Whenever the conversation shows which place the diner means, pass it with its city, state or country, so a name several places share needs no question. If omitted and the query contains a location, that location is used. | |
| longitude | No | Longitude of search center. Must be provided with latitude. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| results | No | |
| next_step | No | |
| candidates | No | |
| place_note | No | |
| repeat_ask | No | |
| other_places | No | |
| location_used | No | |
| result_groups | No | |
| pool_disclosure | No | |
| query_understood | No | |
| total_candidates | No | |
| unknown_requirements | No | |
| unverifiable_attributes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/no-destruction profile, but the description adds runtime behavior the schema cannot convey: a daily free-run cap where only runs returning results count, limit_reached relaying without retry, repeat_ask signaling a duplicate answer, ordering/labeling discipline for result_groups, and the semantics of caveats, honored_constraints, requirements, unknown_requirements and place_note. Nothing contradicts readOnlyHint=true, destructiveHint=false or idempotentHint=false.
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 core purpose is front-loaded in the first sentence, but the remainder is one sprawling block with nested parentheticals and repeated constraint-restatement rules that could be tightened. All content is relevant, yet the density and length make it harder to scan than it needs to be.
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?
Covers everything an agent needs for a complex, ranked-output tool: invocation cardinality, required location with failure mode, rate-limit recovery, handling of thin pools and low coverage_level, and how to present grouped/unconfirmed results. Output details are supplied even though an output schema exists, leaving no gap for correct use.
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%, so the baseline is 3, but the description adds operational meaning beyond the schema: query must carry the full ask plus the location, location is the disambiguating fallback when the query lacks one, and omitting all of query-location/location/lat-lng triggers a refusal rather than a guessed city. The limit parameter and lat/lng precedence are left to the schema.
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?
States a specific verb and resource with scope: 'Returns a complete, ranked restaurant recommendation for a dining occasion: the final answer, not a search.' The explicit contrast with searching distinguishes it from search_restaurants and find_restaurant without requiring the agent to open either schema.
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?
Explicit invocation rules: 'Call it ONCE per diner ask, with the full ask... in query and the place in location,' plus when-not to use it ('do not re-call with reworded variations or call lookup_restaurant on each result to double-check it') and named alternatives ('For follow-ups about one place, use lookup_restaurant or ask_about_restaurant'). Location is framed as a hard prerequisite with a named error (location_required).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for restaurants near a location. For picking where to eat or giving recommendations, use recommend; this tool is for browsing a list by distance or filters. Returns graded, ranked results with cuisine, price level, and Seemor analysis summaries. Fully analyzed restaurants (coverage_level 'full', letter grade) come first; when fewer than limit are available, quick-read restaurants are appended after them, marked coverage_level 'basic' with grade null and a preliminary_band (e.g. 'A-range') graded from review analysis, not star ratings. total_in_area = analyzed_in_area + preliminary_in_area; a message explains when quick-read rows are included.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: "grade" (default, best first) or "distance" (nearest first). | |
| limit | No | Maximum results to return. Default 10, max 10. | |
| cuisine | No | Filter by cuisine type (e.g. "Italian", "Japanese"). Case-insensitive substring match. | |
| latitude | Yes | Latitude of the search center (-90 to 90). | |
| longitude | Yes | Longitude of the search center (-180 to 180). | |
| min_grade | No | Minimum letter grade to include (e.g. "B+"). Grades: A+, A, A-, B+, B, B-, C+, C, C-, D, F. | |
| radius_km | No | Search radius in kilometers. Default 2, max 10. | |
| price_level | No | Filter by price level: "$", "$$", "$$$", or "$$$$". |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| results | No | |
| total_in_area | No | |
| analyzed_in_area | No | |
| preliminary_in_area | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral detail: result ranking (fully analyzed first, quick-read appended), coverage_level values ('full' vs 'basic'), grade null with preliminary_band, the formula total_in_area = analyzed_in_area + preliminary_in_area, and the message explaining quick-read inclusion. This goes well beyond the annotations and tells the agent exactly how results are composed.
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 front-loaded with purpose and alternative, then builds out behavioral details in a logical order. Every sentence carries distinct information—core purpose, sibling routing, return characteristics, ranking logic, and area count formula—with no redundancy or 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?
The output schema covers return values, and annotations cover safety. The description supplies everything an agent needs for correct invocation: when to use it, what it returns, how results are ordered and labeled, and when quick-read rows appear. No critical gaps remain.
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%, so the baseline is 3. The description adds value by clarifying the `limit` parameter's effect on result composition ('when fewer than `limit` are available, quick-read restaurants are appended after them'), which is not in the schema. It also references filters generically, but does not need to repeat the schema.
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+resource ('Search for restaurants near a location') and immediately differentiates this tool from the sibling 'recommend' by stating 'this tool is for browsing a list by distance or filters.' This gives an agent a clear, distinct role and prevents confusion with sibling tools.
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 says 'For picking where to eat or giving recommendations, use recommend; this tool is for browsing a list by distance or filters.' This names the alternative, states the condition for choosing this tool, and implicitly excludes single-lookup usage. The guidance is direct and actionable.
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.
recommend2 fields changedOutput schema / properties / other_placesAdded value: +{
+ "items": {
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "country": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}Output schema / properties / place_noteAdded value: +{
+ "type": "string"
+}explore_area1 field changedInput schema / properties / area / descriptionPrevious value: -"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Use a comma qualifier to pick between places that share a name; other_places lists them when a name is shared."New value: +"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Whenever the conversation shows which place is meant, add its city, state or country after a comma, so a shared name needs no guess; other_places lists the others when a name is shared."find_restaurant1 field changedInput schema / properties / city / descriptionPrevious value: -"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Add a qualifier when a name is shared ('Vienna, Virginia'). Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."New value: +"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Whenever the conversation shows which place is meant, include its state or country ('Vienna, Virginia'), so a shared name needs no guess. Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."recommend2 fields changedInput schema / properties / location / descriptionPrevious value: -"City or area to bias the search toward, e.g. 'London', 'San Francisco', 'Rome'. Use this when the query doesn't include a location, or to disambiguate (e.g. 'Victoria' could be London or British Columbia — pass 'London' to clarify). If omitted and the query contains a location, that location is used."New value: +"City or area to bias the search toward, e.g. 'London', 'San Francisco', 'Rome'. Use this when the query doesn't include a location, or to disambiguate (e.g. 'Victoria' could be London or British Columbia — pass 'London' to clarify). Whenever the conversation shows which place the diner means, pass it with its city, state or country, so a name several places share needs no question. If omitted and the query contains a location, that location is used."Output schema / properties / next_stepAdded value: +{
+ "type": "string"
+}explore_area3 fields changedInput schema / properties / area / descriptionPrevious value: -"Neighborhood, city, or region name. Supports 'Shoreditch', 'Shoreditch, London', 'Central London', 'Rome', 'Chelsea, NYC'. Use comma to disambiguate neighborhoods that exist in multiple cities."New value: +"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Use a comma qualifier to pick between places that share a name; other_places lists them when a name is shared."Output schema / properties / other_placesAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / place_noteAdded value: +{
+ "type": "string"
+}find_restaurant4 fields changedInput schema / properties / city / descriptionPrevious value: -"City to narrow the search. Example: 'London', 'New York', 'Rome'. Recommended when the name is common."New value: +"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Add a qualifier when a name is shared ('Vienna, Virginia'). Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."Output schema / properties / other_placesAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / placeAdded value: +{
+ "type": "object"
+}Output schema / properties / place_noteAdded value: +{
+ "type": "string"
+}recommend1 field changedOutput schema / properties / results / items / properties / place_noteAdded value: +{
+ "type": "string"
+}recommend8 fields changedOutput schema / properties / candidatesAdded value: +{
+ "items": {
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lng": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}Output schema / properties / repeat_askAdded value: +{
+ "type": [
+ "boolean",
+ "null"
+ ]
+}Output schema / properties / result_groupsAdded value: +{
+ "items": {
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "entries": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "label": {
+ "enum": [
+ "exact",
+ "exact_within_wider_radius",
+ "likely_match_unconfirmed",
+ "nearby_any",
+ "relaxed_amenity",
+ "below_grade_floor"
+ ],
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "relaxation_steps": {
+ "items": {
+ "properties": {
+ "applied": {
+ "type": "string"
+ },
+ "field": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "original": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / grade_caveatAdded value: +{
+ "type": "string"
+}Output schema / properties / results / items / properties / honored_constraintsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / requirementsAdded value: +{
+ "items": {
+ "properties": {
+ "evidence": {
+ "type": "string"
+ },
+ "firmness": {
+ "enum": [
+ "identity",
+ "timing",
+ "amenity",
+ "preference"
+ ],
+ "type": "string"
+ },
+ "phrase": {
+ "type": "string"
+ },
+ "requirement": {
+ "type": "string"
+ },
+ "source": {
+ "enum": [
+ "stated",
+ "inferred"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "confirmed",
+ "contradicted",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / status / enumPrevious value: -[
- "ok",
- "error",
- "no_coverage",
- "location_required",
- "timeout",
- "cannot_verify"
-]New value: +[
+ "ok",
+ "error",
+ "no_coverage",
+ "location_required",
+ "timeout",
+ "cannot_verify",
+ "geo_conflict"
+]Output schema / properties / unknown_requirementsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}recommend3 fields changedOutput schema / properties / pool_disclosureAdded value: +{
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "enum": [
+ "thin_pool",
+ "cuisine_relaxed"
+ ],
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / status / enumPrevious value: -[
- "ok",
- "error",
- "no_coverage",
- "location_required",
- "timeout"
-]New value: +[
+ "ok",
+ "error",
+ "no_coverage",
+ "location_required",
+ "timeout",
+ "cannot_verify"
+]Output schema / properties / unverifiable_attributesAdded value: +{
+ "items": {
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "source_phrase": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": [
+ "array",
+ "null"
+ ]
+}explore_area1 field changedOutput schema / properties / highlights / items / properties / coverage_level / enumPrevious value: -[
- "full",
- "basic"
-]New value: +[
+ "full",
+ "basic",
+ "none"
+]find_restaurant1 field changedOutput schema / properties / results / items / properties / coverage_level / enumPrevious value: -[
- "full",
- "basic"
-]New value: +[
+ "full",
+ "basic",
+ "none"
+]lookup_restaurant8 fields changedOutput schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / restaurant / properties / addressAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / restaurant / properties / analysis_dateAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / restaurant / properties / caveatsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / restaurant / properties / cityAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / restaurant / properties / coverage_levelAdded value: +{
+ "enum": [
+ "full",
+ "basic",
+ "none"
+ ],
+ "type": "string"
+}Output schema / properties / restaurant / properties / preliminary_bandAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / restaurant / properties / seemor_urlAdded value: +{
+ "type": "string"
+}recommend1 field changedOutput schema / properties / results / items / properties / coverage_level / enumPrevious value: -[
- "full",
- "basic"
-]New value: +[
+ "full",
+ "basic",
+ "none"
+]search_restaurants1 field changedOutput schema / properties / results / items / properties / coverage_level / enumPrevious value: -[
- "full",
- "basic"
-]New value: +[
+ "full",
+ "basic",
+ "none"
+]explore_area6 fields changedOutput schema / properties / analyzed_countAdded value: +{
+ "type": "number"
+}Output schema / properties / coverage_levelAdded value: +{
+ "enum": [
+ "full",
+ "basic",
+ "none"
+ ],
+ "type": "string"
+}Output schema / properties / description / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / highlights / items / propertiesAdded value: +{
+ "address": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "coverage_level": {
+ "enum": [
+ "full",
+ "basic"
+ ],
+ "type": "string"
+ },
+ "cuisine_tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "distance_km": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "grade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "preliminary_band": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price_level": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "seemor_id": {
+ "type": "string"
+ },
+ "tldr": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+}Output schema / properties / preliminary_countAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / status / enumAdded value: +[
+ "ok",
+ "error",
+ "not_found"
+]find_restaurant10 fields changedOutput schema / properties / results / items / properties / address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / caveatsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / city / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / coverage_level / enumAdded value: +[
+ "full",
+ "basic"
+]Output schema / properties / results / items / properties / distance_kmAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / grade / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / neighborhood / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / preliminary_bandAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / price_levelAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / tldrAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}lookup_restaurant5 fields changedOutput schema / properties / restaurant / properties / grade / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / restaurant / properties / grade_label / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / restaurant / properties / neighborhood / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / restaurant / properties / price_level / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / restaurant / properties / tldr / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]recommend4 fields changedOutput schema / properties / results / items / properties / coverage_levelAdded value: +{
+ "enum": [
+ "full",
+ "basic"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / grade / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / preliminary_bandAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / status / enumPrevious value: -[
- "ok",
- "error",
- "no_coverage",
- "location_required"
-]New value: +[
+ "ok",
+ "error",
+ "no_coverage",
+ "location_required",
+ "timeout"
+]search_restaurants12 fields changedOutput schema / properties / analyzed_in_areaAdded value: +{
+ "type": "number"
+}Output schema / properties / preliminary_in_areaAdded value: +{
+ "type": "number"
+}Output schema / properties / results / items / properties / address / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / caveatsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / city / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / coverage_level / enumAdded value: +[
+ "full",
+ "basic"
+]Output schema / properties / results / items / properties / distance_kmAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / grade / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / neighborhood / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / results / items / properties / preliminary_bandAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / price_levelAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / tldrAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}recommend1 field changedOutput schema / properties / results / items / properties / caveatsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}ask_about_restaurant5 fields changedOutput schema / properties / categoryAdded value: +{
+ "type": "string"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / restaurant_idAdded value: +{
+ "type": "string"
+}Output schema / properties / seemor_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / sourceAdded value: +{
+ "type": "string"
+}explore_area4 fields changedOutput schema / properties / descriptionAdded value: +{
+ "type": "string"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / neighborhoodsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / price_breakdownAdded value: +{
+ "type": "object"
+}find_restaurant2 fields changedOutput schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / total_matchesAdded value: +{
+ "type": "number"
+}recommend7 fields changedOutput schema / properties / location_usedAdded value: +{
+ "type": "string"
+}Output schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / query_understoodAdded value: +{
+ "type": "string"
+}Output schema / properties / recommendationsRemoved value: -{
- "items": {
- "properties": {
- "grade": {
- "type": "string"
- },
- "match_reasons": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "name": {
- "type": "string"
- },
- "relevance": {
- "type": "string"
- },
- "seemor_id": {
- "type": "string"
- }
- },
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / resultsAdded value: +{
+ "items": {
+ "properties": {
+ "distance_km": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "grade": {
+ "type": "string"
+ },
+ "match_reasons": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "relevance": {
+ "type": "string"
+ },
+ "seemor_id": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / status / enumAdded value: +[
+ "ok",
+ "error",
+ "no_coverage",
+ "location_required"
+]Output schema / properties / total_candidatesAdded value: +{
+ "type": "number"
+}search_restaurants3 fields changedOutput schema / properties / messageAdded value: +{
+ "type": "string"
+}Output schema / properties / totalRemoved value: -{
- "type": "number"
-}Output schema / properties / total_in_areaAdded value: +{
+ "type": "number"
+}lookup_restaurant1 field changedInput schema / properties / fields / descriptionPrevious value: -"Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional scores (noise, formality, authenticity, etc.), value assessment, strengths/weaknesses."New value: +"Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional assessments (noise, formality, authenticity, etc.), value assessment, standout strengths/weaknesses, unique selling points."ask_about_restaurant1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "answer": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ },
+ "restaurant_name": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}explore_area1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "analyzed_restaurants": {
+ "type": "number"
+ },
+ "area": {
+ "type": "string"
+ },
+ "grade_distribution": {
+ "type": "object"
+ },
+ "highlights": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "top_cuisines": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_restaurants": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}find_restaurant1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "items": {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "city": {
+ "type": "string"
+ },
+ "coverage_level": {
+ "type": "string"
+ },
+ "cuisine_tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "seemor_id": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}lookup_restaurant1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "restaurant": {
+ "properties": {
+ "cuisine_tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "grade_label": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "price_level": {
+ "type": "string"
+ },
+ "seemor_id": {
+ "type": "string"
+ },
+ "tldr": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}recommend1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "recommendations": {
+ "items": {
+ "properties": {
+ "grade": {
+ "type": "string"
+ },
+ "match_reasons": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "relevance": {
+ "type": "string"
+ },
+ "seemor_id": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}search_restaurants1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "results": {
+ "items": {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "city": {
+ "type": "string"
+ },
+ "coverage_level": {
+ "type": "string"
+ },
+ "cuisine_tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "seemor_id": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}ask_about_restaurantexplore_areafind_restaurantlookup_restaurantrecommendsearch_restaurants
Add one secure layer between your agents and this server.