Find what's open, read menus and ratings, and get the right booking route for places in 119 travel destinations. Read-only, no key needed.
Scored across 9 tools
Most tools have clearly distinct purposes (menu, reviews, details, booking link, concierge Q&A), and descriptions explicitly delimit boundaries. There is some overlap among search_places, open_places, and directory_feed, all of which return place lists, but the descriptions clearly separate ranking search, real-time open filtering, and bulk paged sync.
All names use a consistent snake_case style and readable, natural phrasing. There is a minor convention drift: get_/list_/search_ verbs coexist with noun-phrase names like place_details, booking_link, open_places, and directory_feed, so it is not a strict verb_noun pattern throughout.
Nine tools is well-scoped for a travel directory and booking-routing server. Each tool maps to a distinct capability (discovery, detail, menu, reviews, real-time open state, bulk sync, coverage check, booking routing, NL concierge) with no apparent filler.
The surface covers the full read-only lifecycle: coverage lookup, ranked search, real-time open state, bulk directory sync, per-place detail, menus, rating summaries, and booking routing. Booking is intentionally a deeplink rather than a reservation, which is consistently explained, so no obvious dead ends remain.
A booking page for one place with the party size, date and time ALREADY FILLED IN. This does NOT make a reservation and Num does not hold a table — the traveller completes it on the venue's own platform (OpenTable, Resy, Tock, SevenRooms, Square and others). The response always carries booked: false and mode: "deeplink". You MUST NOT render this as a confirmation, and you MUST NOT tell a traveller a table is held. If the venue has no booking platform the response says so and returns the phone number instead — offer that rather than implying it cannot be visited.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD. | |
| time | No | HH:MM, 24-hour, local to the venue. | |
| party | No | Number of covers, 1–20. | |
| place_id | Yes | From search_places or open_places. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safe read profile; the description goes much further by disclosing the response contract (`booked: false`, `mode: "deeplink"`), the handoff to third-party platforms, and explicit prohibitions against rendering it as a confirmation or claiming a table is held. This is exactly the behavioral disclosure annotations cannot carry.
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?
Front-loaded with the core contract, then consequences, then fallback handling, in five tight sentences with no filler. Emphasis (ALREADY FILLED IN, DOES NOT, MUST NOT) is functional rather than decorative.
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 no output schema, the description fully compensates by specifying the returned fields, the non-reservation semantics, and the phone-number fallback path. Everything an agent needs to call and correctly represent the result is present.
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 one genuinely new fact — that party, date and time are already filled into the link — but gives no syntax or omission behavior beyond what the schema already documents.
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+resource (a booking page / deep link for one place) and immediately clarifies what it is NOT (a reservation, a held table). The agent can tell this apart from search_places or place_details without opening a 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?
Gives clear context for use (booking a specific place with party/date/time pre-filled) plus a branch when the venue has no platform (offer the returned phone number instead). It does not name a sibling alternative such as concierge_answer, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Num the way a traveller would — "where should we eat tonight near Kata?", "which beach for sunset?" — and get a short concierge answer grounded in Num's verified directory, plus the places it names as structured data so you can render your own cards. This is the whole product in one tool. It answers about the place asked and NEVER substitutes a different city. If Num has no coverage there it says so rather than guessing. It does not book, charge, or take personal details — send none. You MUST display the returned attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Neighbourhood or hotel area, if known. | |
| language | No | BCP-47 tag for the reply, e.g. "th", "ru". Defaults to the language of the question. | |
| question | Yes | The traveller's question, in their own words. Any language. | |
| destination | No | Where they are, if you know it. Improves grounding. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral context: it never substitutes a different city, it admits lack of coverage rather than guessing, it takes no personal data, and it mandates displaying the returned attribution. That is substantive disclosure beyond what the structured fields provide.
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?
Front-loads the core behavior and example questions, then layers constraints (no city substitution, no personal data, attribution). Slightly diluted by promotional phrasing ('This is the whole product in one tool'), which is the only sentence not earning 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?
With no output schema, the description carries the return-value burden well: it explains the short concierge answer, the structured places, and the attribution field, and it warns that the tool may refuse when coverage is absent. An agent has everything needed to call and handle it correctly.
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 question, near, destination, and language are already documented in the schema. The description does not add syntax or format detail beyond noting the traveller's own words and multilingual input, so the 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?
States a specific verb+resource (ask a travel question, get a concierge answer grounded in Num's directory) and clarifies the return shape (answer plus named places as structured data). It is clearly distinguishable from siblings like search_places and place_details, which fetch data rather than answer questions.
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?
Gives explicit when-not guidance — does not book, charge, or take personal details ('send none') — and sets the scope to the destination asked, never substituting another city. It stops short of routing the agent between this and sibling tools (e.g. use search_places for raw listings), so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk, paged sync of every place Num lists in one destination — free (included in the no-fee free tier; one call returns up to 200 places), for keeping your own copy of the directory current instead of searching it call by call. Ordered by place_id; pass the returned next_cursor back as cursor until it is null. Each item has the search_places fields plus cuisine, lat, lng and booking_platform. Places Num has positive evidence have closed are excluded; trading: null means not yet checked, NOT closed. Contains no menus, reviews or photos — call get_menu, get_reviews or place_details for those. You MUST display the returned attribution wherever the data is shown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Places per page: 1–200 with an X-Partner-Key (default 100); without a key, at most 50. | |
| cursor | No | The `next_cursor` from the previous page. Omit for the first page. | |
| destination | Yes | Destination slug from list_destinations, e.g. "los-angeles". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the read-only/idempotent annotations: discloses pricing/free-tier, a 200-place page ceiling, ordering by place_id, cursor termination semantics, the per-item field payload, the closure-exclusion rule, the trading:null meaning, the absence of menus/reviews/photos, and a mandatory attribution display requirement. This is rich operational context the annotations cannot carry.
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?
Front-loaded with the operation and its scope, and nearly every clause carries distinct information. The parenthetical about the free tier is mildly redundant, and the single dense paragraph could be split, but there is little true 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 no output schema, the description carries the return-shape burden and does so — per-item fields, cursor field, attribution obligation, and the trading:null edge case. An agent has everything needed to page correctly and interpret results.
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 already documents limit ranges and the cursor/destination meanings, so baseline is 3. The description adds the pagination loop contract — feed the returned next_cursor back as cursor until it is null — which the schema does not state, though it says nothing extra about limit or the destination slug lookup.
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+resource+scope: bulk, paged sync of every place in one destination, as opposed to call-by-call searching. An agent can distinguish it from search_places and list_destinations purely from this sentence.
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?
Explicitly frames the use case ('keeping your own copy of the directory current instead of searching it call by call') and routes the agent elsewhere for adjacent needs: get_menu, get_reviews, place_details. Both when-to-use and when-to-use-something-else are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A rating SUMMARY for one place, free (included in the no-fee free tier) — no review text and no reviewer identities, ever. Returns external (the public rating and review count the listing carries, with source, the site it was read from) and num_verified: the average, count and 1–5 star distribution of ratings from verified guests — people who booked through Num and checked in at the venue by scanning its own code. Guests the venue comped or worked with are excluded, and Num publishes no verified average until a place has 5 such ratings (below that every number is null and note says why). Keep the two numbers separate; do not average them together. You MUST display the returned attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| place_id | Yes | From search_places, place_details or directory_feed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses return shape (`external` with `source`, `num_verified` with average/count/distribution), the exclusion of comped or partnered guests, the 5-rating publication threshold with nulls and a `note` explaining why, and a mandatory `attribution` display requirement. That is substantial behavioral context annotations alone would not convey.
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 critical fact — a summary only, with no review text or identities — is front-loaded, and the detail that follows is largely load-bearing (threshold, null behavior, attribution mandate). The parenthetical free-tier note is slightly redundant but minor.
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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly — both returned objects, their fields, edge cases, and the display obligation. Nothing an agent needs to call and correctly present results 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?
There is a single parameter with 100% schema description coverage ('From search_places, place_details or directory_feed'), so the schema already carries the semantics. The description adds no further meaning about place_id, making the baseline 3 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 names a specific verb+resource ('A rating SUMMARY for one place') and draws a sharp boundary by stating it returns no review text and no reviewer identities. It implicitly differentiates itself from richer siblings like place_details, but never names an alternative tool, so sibling differentiation is left to inference.
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?
Usage context is implied: it is free/included in the no-fee tier, which hints it should be preferred when only aggregate ratings are needed. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative (e.g. place_details) to route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which destinations Num covers, with the number of verified places in each. Call this FIRST when you do not know whether a city is supported — it is cheaper than a failed search and stops you promising a traveller coverage that does not exist. Coverage is honest: a destination appears here only when it has a real, maintained directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-open-world), so the bar is lower, but the description still adds real context: coverage is honest and a destination appears only with a real, maintained directory. It goes beyond structured fields by disclosing the completeness guarantee of the result set, though it says nothing about result size or pagination.
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?
Three short sentences, each doing distinct work: what it returns, when to call it, and why the data is trustworthy. The most actionable instruction ('Call this FIRST') is front-loaded ahead of the justification.
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 trivial to invoke (no params, no output schema), and the description compensates for the missing output schema by describing what comes back: destinations plus verified-place counts. No agent-relevant gap remains.
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?
Zero parameters, so the schema imposes no semantic burden and the description has nothing to disambiguate. Baseline 4 applies; there is no parameter detail the description fails to supply.
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 (list which destinations Num covers) and adds scope detail: the count of verified places in each. It is clearly distinguishable from siblings like search_places, which it explicitly positions against as the cheaper alternative.
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?
Gives an explicit trigger — 'Call this FIRST when you do not know whether a city is supported' — and names the alternative behavior it replaces ('cheaper than a failed search'), which tells the agent when not to bother going straight to search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Places that are OPEN RIGHT NOW in a destination, computed in the destination's own timezone. Businesses whose own website is a dead domain or a 404 are excluded entirely — they have closed down. IMPORTANT: only venues whose opening hours Num has verified can appear here, so a short list means thin hours coverage, NOT an empty city. Never tell a traveller "nothing is open" on the strength of this tool; say that these are the ones Num can confirm are open. Use search_places for the full directory.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | Neighbourhood, e.g. "Silver Lake". | |
| limit | No | Max results, 1–50. Default 20. | |
| category | No | Exact category, e.g. "Restaurant". Omit for all. | |
| destination | Yes | Destination slug, e.g. "los-angeles". | |
| bookable_only | No | Only venues Num can hand off a booking page for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world operation, so the description is free to add the genuinely non-obvious behavior: timezone-local computation, hard exclusion of venues with dead-domain or 404 websites, and the fact that results are limited to hours Num has verified. The remaining gap is that with no output schema, the return shape is never described.
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 key constraint (open right now, destination timezone) is front-loaded and each subsequent sentence carries real information – the dead-domain filter, the coverage caveat, and the sibling pointer. It runs slightly long with emphatic capitalisation, but no sentence is 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 read-only, single-required-parameter lookup this covers the mechanics, prerequisites (verified hours), exclusion rules and the correct interpretation of a short list. Nothing an agent needs to call it correctly or report its results honestly 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 description coverage is 100% for all five parameters, including near, limit, category, destination slug format and bookable_only, so the structured field already does the work. The prose adds no parameter-level detail such as slug format or semantics of bookable_only beyond what the schema states, which is the expected baseline 3.
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 – places that are open right now in a destination – and immediately scopes it by timezone computation. It clearly contrasts itself with the full-directory sibling search_places, so an agent can distinguish the two without opening a 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?
It names the alternative ('Use search_places for the full directory') and specifies when-not to use the result as a definitive answer ('never tell a traveller nothing is open'). This covers both routing and an important misuse case that no other field supplies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything Num holds on one place, by place_id from search_places: contact details, hours, rating, review count, area, category, cuisine, the venue's own short description (about), coordinates, open_now computed in the destination's timezone (true / false / null — null means Num has not verified the hours, NOT that it is closed), the booking platform and — only where a verified owner chose it — the venue's own booking page, a recently-read published price line where Num holds one, and up to 8 approved member photos plus the listing photo, each with its own attribution you MUST show alongside it. Use before showing a detail page or handing a traveller a phone number. Returns only what is verified — absent fields are absent because Num does not know them, never because they were omitted for brevity. Do not fill gaps from memory; an invented phone number is worse than a missing one.
| Name | Required | Description | Default |
|---|---|---|---|
| place_id | Yes | From search_places. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations with non-obvious semantics: null open_now means unverified hours, not closed; only verified data is returned and absences are ignorance, not omission; the attribution field MUST be displayed with photos. It also warns against filling gaps from memory, which is real behavioral guidance an agent would otherwise get wrong.
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?
Front-loaded with the resource and scope, and the critical caveats (null semantics, attribution, no invention) are kept. The central sentence is a very long comma-chained enumeration of return fields, which is dense to scan even though each item is informative.
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?
No output schema exists, so the description carries the full burden of describing the return payload, and it does so thoroughly — listing every field family and the one field (attribution) with a mandatory display obligation. An agent has everything needed to call and interpret the result.
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 description already says the id comes 'From search_places,' so the description's mention of place_id origin duplicates structured data. With only one parameter there is little left to clarify beyond that baseline.
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 — retrieve everything held on one place, keyed by place_id. The enumeration of returned facets (contact details, hours, rating, reviews, photos, booking) makes it unmistakable against siblings like get_reviews, get_menu, or search_places.
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?
Explicitly routes usage: 'Use before showing a detail page or handing a traveller a phone number,' and anchors the key's provenance to search_places. It stops short of naming when to prefer siblings (get_reviews, get_menu) for narrow needs, so it is clear context without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find real, currently-operating places in a destination — restaurants, bars, beaches, spas, viewpoints, temples. Ranked by quality (rating weighted by how many reviews stand behind it). When near is a "lat,lng" coordinate pair, results are limited to about 5 km of that point, ranked by a blend of quality and distance — so a 4.8★ institution two streets away beats an unrated snack bar next door — and each carries distance_m. When near is a neighbourhood name it filters by area and NO distance is returned. Returns name, category, area, rating, review count, phone, address and opening hours where known. NEVER invents a place: if Num does not hold it, it is not returned. You MUST display the returned attribution string wherever you show these results.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | A "lat,lng" pair (e.g. "7.8208,98.2976") for distance-ranked results, or a neighbourhood name to filter by area, e.g. "Kata Beach". | |
| limit | No | Max results, 1–20. Default 8. | |
| query | No | Free text, e.g. "thai seafood", "rooftop". | |
| category | No | restaurant | bar | beach | spa | viewpoint | temple | waterfall | cafe (any case). Omit for all. | |
| destination | Yes | Destination slug or city name, e.g. "phuket", "bangkok". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes well beyond them: ~5 km radius cap, quality/distance blend ranking, the conditional presence of `distance_m`, the no-fabrication guarantee, and a hard requirement to display the `attribution` string. These are behavioral traits the agent cannot derive from structured fields.
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?
Purpose is front-loaded in the first clause, followed by ranking, parameter modes, return fields, and constraints in a logical order. It is denser than strictly necessary (the 4.8★ snack-bar aside), but nearly every sentence carries actionable information.
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 no output schema, the description takes on the burden of describing the return payload (name, category, area, rating, review count, phone, address, hours, conditional distance_m) and adds the mandatory attribution display. An agent has everything it needs to call and present results correctly.
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 real meaning: the ~5 km limiting radius for coordinate input, the blend of quality and distance, and the fact that no distance is returned for neighbourhood input. It doesn't expand on query/category/limit syntax, but those are fully covered in 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 ('Find real, currently-operating places in a destination') and enumerates the categories covered, so the agent knows exactly what domain this search spans. It is cleanly separable from detail-oriented siblings like place_details or get_reviews because it describes discovery/ranking rather than lookup.
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?
Explains the two operating modes of `near` (coordinate for distance-ranked, neighbourhood name for area-only filtering) and what ranking to expect in each, which is effectively usage guidance. It does not name a sibling as an alternative or state when not to use this tool, so it stops short of a 5.
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.
booking_linkconcierge_answerdirectory_feedget_menuget_reviewslist_destinationsopen_placesplace_detailssearch_places
Add one secure layer between your agents and this server.