Real places for your agent. Search 2.5M+ travel places; submit a business for human review.
Scored across 6 tools
Each tool targets a clearly distinct resource and action: searching places, fetching place details, listing destinations, listing submissions, submitting a business, and submitting a promo. There is no meaningful overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern with the shared num_ prefix: get_place, list_destinations, list_submissions, search_places, submit_business, submit_promo. This is a uniform and predictable naming scheme.
Six tools is well-scoped for a travel directory server covering discovery, details, and submissions. Each tool earns its place and the count is neither bloated nor thin.
The core read workflow is covered by list_destinations, search_places, and get_place, while the write workflow is covered by submit_business and submit_promo, with list_submissions closing the loop on review status. Minor gaps exist, such as no dedicated single-submission retrieval or explicit delete/update tools, but resending with the same reference provides update semantics.
Full record for one place, by the place_id that num_search_places returned, including HOW TO BOOK IT on the venue's own terms. booking.method is one of: request (the venue takes requests through NUM and confirms each one itself), venue_system (send the traveller to booking.url, prefilled when you pass party_size, date and time), phone (the number is for the traveller to call), not_through_num, closed, unknown. Follow booking.guidance exactly. If open_status.closed is true, NUM holds evidence the place has gone: do not send anyone there. accolades carry their source; menu is the owner's own list and prices. Each call counts against the daily read quota.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional: YYYY-MM-DD, to prefill the venue's booking page. | |
| time | No | Optional: HH:MM 24-hour, local to the venue. | |
| place_id | Yes | The place_id returned by num_search_places. | |
| party_size | No | Optional: people in the party, to prefill the venue's booking page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: each call counts against the daily read quota, booking.method meanings and how to act on them, the closed-status caution, and that accolades carry source and menu is owner-provided. 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 moderately long but every sentence carries functional weight. It front-loads the core purpose and then unpacks booking details and precautions in a logical order. Slightly dense but not verbose; 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 no output schema, the description compensates by explaining the return structure's key aspects: booking.method values, open_status.closed, accolades, and menu. It also flags the quota. It doesn't enumerate every field, but for a get-by-id tool it's sufficient for an agent to understand expectations and side effects.
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 parameters are already documented. The description adds meaning by explaining that party_size, date, and time are used to prefill the venue's booking page, and that place_id comes from num_search_places. This bridges the parameters to the booking workflow, adding value 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 clearly states the tool returns the full record for one place by place_id from num_search_places, and explicitly includes how to book it. The verb+resource (get place details) is specific, and it differentiates itself from siblings like num_search_places (search) and num_submit_* (submissions). It even details booking.method values, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the workflow (use after num_search_places) and provides strong usage guidance: how to interpret booking.method, when to send travellers (and when not to, e.g., if open_status.closed is true), and to follow booking.guidance exactly. It doesn't explicitly name alternative tools or state when not to use this one, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every destination NUM covers, with its country. Use a destination's name or slug as num_search_places city. Free, unmetered, and needs no key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about being free, unmetered, and keyless, and specifies the scope ('every destination NUM covers'). It does not mention return format or pagination, but those are less critical given 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?
Two sentences, no fluff, with the core purpose front-loaded and the usage hint following immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-free read-only list, the description is fully sufficient. It explains what is returned (destinations with countries), how to use the results, and any access constraints (free, unmetered, no key). Nothing essential 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?
The tool has zero parameters, so schema coverage is 100% automatically. The description adds no parameter-specific detail, but none is needed. Per the baseline for 0 params, 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 clearly states the tool's purpose: listing every destination NUM covers with its country. It distinguishes itself from siblings like num_search_places by focusing on the complete list rather than a filtered search.
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?
Provides explicit guidance on how to use the results: 'Use a destination's name or slug as num_search_places city.' It also notes that the tool is free, unmetered, and requires no key, which helps agents decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the businesses and promotions this account has submitted, with the reviewer's decision on each. Free and unmetered.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description carries a lighter burden. It adds 'Free and unmetered,' a useful cost/rate-limit behavior, and indicates the output includes reviewer decisions. It does not discuss pagination or status filtering, but annotations cover the safety profile.
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 compact sentences with no filler. The main purpose is front-loaded, and the cost/reliability note is a single short second sentence that adds value without bloating the description.
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 list tool with no required parameters and safety annotations, the description provides sufficient context: it tells the agent what the result will contain and that it is free/unmetered. It omits response shape details, but the absence of an output schema and the simple nature of the operation keep this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain `limit`, `offset`, or `status`. The 'reviewer's decision' phrase hints at what `status` may filter on, but there is no explicit mention of the enum values or pagination semantics, so the description fails to compensate for the missing schema descriptions.
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 ('Lists') and a clear resource ('the businesses and promotions this account has submitted') with a concrete outcome ('with the reviewer's decision on each'). This scope distinguishes it from sibling tools like num_search_places, num_get_place, and the submit tools without needing to open their schemas.
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 phrase 'this account has submitted' clearly signals this is for retrieving one's own submissions, giving the agent a clear context in which to select it. It does not explicitly name alternatives or exclusions, but the sibling set and the resource scope make the appropriate use-case obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NUM's travel directory: more than 2.5 million places — restaurants, bars, hotels, spas, tours and shops, deepest in Thailand and the UK. Say where to look: city (one of NUM's destinations — see num_list_destinations) or country; then narrow with q, area and category. Places NUM knows have closed are never returned. Returns name, category, address, phone, website, coordinates and whether the owner has claimed the listing; call num_get_place for how to book one. Each call counts against the daily read quota.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text matched against the place name. | |
| area | No | A neighbourhood inside the destination, e.g. 'Kata' or 'Soho'. | |
| city | No | A NUM destination, e.g. 'Phuket', 'Edinburgh', 'Bangkok', 'London'. Required unless country is given. | |
| limit | No | Max results, default 20, cap 50. | |
| country | No | ISO-2 code or name, e.g. 'TH' or 'Thailand'. Searches every NUM destination in that country. | |
| category | No | e.g. 'Restaurant', 'Bar', 'Hotel', 'Spa', 'Tour'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those: closed places are never returned, each call counts against the daily read quota, and it enumerates the exact fields returned, compensating for the lack of an output schema.
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 dense but well organized: scope, how to search, a filtering caveat, return contents, next-step routing, and quota impact are each covered in compact sentences. No words are wasted and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description is remarkably complete: it covers data scope, required location inputs, narrowing parameters, closed-place behavior, return fields, the follow-up tool, and quota impact. The limit parameter is fully documented in the schema, so its absence from the description is not a gap.
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 already provides 100% coverage for all six parameters with clear descriptions. The main text reinforces the relationship between city and country and describes q/area/category as narrowing filters, but it does not add substantial parameter semantics beyond what the schema already states, so the baseline of 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 clearly states the tool searches NUM's travel directory of places, names the categories included, and differentiates it from siblings by pointing to num_get_place for booking and num_list_destinations for valid city choices. The verb 'search' plus the explicit resource leaves no ambiguity about what this tool does.
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 gives a concrete usage recipe: specify a city or country first, then narrow with q, area, and category. It also routes the agent to relevant siblings, though it does not explicitly state when to avoid this tool in favor of submission-oriented siblings, which are clearly different actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a business to NUM for review. Free and unmetered. A person at 5arz reviews every submission before any traveller sees it, so the result is status 'pending_review', never an immediate listing. 'relationship' records whether the submitter owns the business, was engaged by the owner, or is a third party; reviewers verify it. Contact details must be ones the business has published — submissions with guessed or derived contact details are rejected. Re-sending the same external_ref updates the pending submission instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| name | Yes | Trading name as it appears on the door. | |
| No | Only if the business has published it. Do not derive it from the domain name. | ||
| hours | No | ||
| phone | No | ||
| address | No | ||
| country | Yes | ||
| website | No | ||
| vertical | No | restaurant, cafe, bar, hotel, spa, boat, tour, shop, transport, clinic, gym, attraction, other… | |
| languages | No | ||
| description | No | ||
| price_range | No | ||
| callback_url | No | NUM POSTs the review decision here. | |
| external_ref | No | Your own reference for this business. Re-sending it edits the pending submission instead of creating a duplicate. | |
| relationship | Yes | 'owner' if you run it, 'authorized_agent' if the owner engaged you, 'third_party' if you neither own nor represent it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description justifies this by stating it creates a pending review, not an immediate listing, and warns about rejection for derived contacts. It also discloses the human review step and idempotency behavior, providing rich context beyond annotations. 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 concise and front-loaded, with the core purpose and immediate outcome stated first. It includes multiple key behavioral notes in a compact form without redundancy. Every sentence adds value, and it avoids extraneous detail.
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's complexity (15 params, human review, idempotency) and lack of output schema, the description provides sufficient context: the review process, the 'pending_review' status, the relationship verification, the contact requirement, and the idempotent update behavior. This is enough for an agent to call correctly and set expectations.
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 only 40%, but the description compensates for several critical parameters: 'relationship' is explained (owner/agent/third party), 'external_ref' is explained (idempotency), and contact details (email, phone) are covered by the 'published' requirement. However, many other params (city, name, vertical, etc.) rely on the schema's brief descriptions, so the description adds value but isn't exhaustive.
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 action (submit a business), the resource (NUM), and the key behavior (goes to human review, never immediate). It also distinguishes itself from sibling tools by mentioning its asynchronous nature and idempotency via external_ref, unlike get/list/search which are read-only and submit_promo which is for promotions.
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 states when to use this tool (submit a business for review) and provides important exclusions: submissions with guessed contact details are rejected, contact must be published. It also clarifies idempotent behavior with external_ref, which guides proper usage. It implicitly differentiates from read-only siblings and the promo tool, though not explicitly naming them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a promotion, special, event or ad to a business previously submitted by the same account. Free and unmetered. A person reviews it before it is shown to anyone. Re-sending the same promo_ref updates the pending promotion instead of creating a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| terms | No | ||
| title | Yes | The single line a traveller reads. | |
| detail | No | ||
| ends_at | No | ||
| promo_ref | No | Your own reference for this promotion, for idempotent edits. | |
| starts_at | No | 2026-08-01 or 2026-08-01T18:00:00Z. | |
| discount_pct | No | ||
| external_ref | No | Alternative to submission_id: the reference you used for the business. | |
| submission_id | No | From num_submit_business. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it is free and unmetered, a human reviews it before publication, and re-sending the same promo_ref updates the pending promotion rather than creating a duplicate. These are real behavioral traits not expressed by the annotations, and the conditional idempotency via promo_ref does not directly contradict 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 description is compact and front-loaded: the first sentence states the core operation, the second adds cost/cost context, and the third explains the review and idempotent update behavior. 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?
For a mutation-oriented tool with no output schema, the description covers the key prerequisites, review latency, and update semantics. Remaining gaps are mostly about return values and less central parameters, but the invocation path is clear enough for an agent to use 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 coverage is 50%, and the description helps clarify the meaning of kind, the business linkage, and the promo_ref update behavior. However, it adds nothing about terms, detail, discount_pct, starts_at, or ends_at, so it does not fully compensate for the parameters left undocumented 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?
The description clearly states a specific action: attach a promotion, special, event, or ad to a previously submitted business. This distinguishes it from the sibling num_submit_business, which must be called first to create the business.
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 a clear precondition: the business must already have been submitted by the same account. It does not name alternative tools or explicitly say when not to use it, but the context of attaching to an existing submission is enough for an agent to route correctly.
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.
num_get_place3 fields changedInput schema / properties / dateAdded value: +{
+ "description": "Optional: YYYY-MM-DD, to prefill the venue's booking page.",
+ "type": "string"
+}Input schema / properties / party_sizeAdded value: +{
+ "description": "Optional: people in the party, to prefill the venue's booking page.",
+ "maximum": 40,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / timeAdded value: +{
+ "description": "Optional: HH:MM 24-hour, local to the venue.",
+ "type": "string"
+}num_list_destinationsnum_search_places3 fields changedInput schema / properties / areaAdded value: +{
+ "description": "A neighbourhood inside the destination, e.g. 'Kata' or 'Soho'.",
+ "type": "string"
+}Input schema / properties / city / descriptionPrevious value: -"City or destination, e.g. 'Phuket', 'Edinburgh', 'Bangkok', 'London'."New value: +"A NUM destination, e.g. 'Phuket', 'Edinburgh', 'Bangkok', 'London'. Required unless country is given."Input schema / properties / country / descriptionPrevious value: -"ISO-2 country code, e.g. 'TH' or 'GB'."New value: +"ISO-2 code or name, e.g. 'TH' or 'Thailand'. Searches every NUM destination in that country."num_get_placenum_list_submissionsnum_search_placesnum_submit_businessnum_submit_promoTravel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Search 367k+ verified businesses; earn cashback when an agent routes a real purchase.
Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Add one secure layer between your agents and this server.
