Help a group pick where to eat or travel: critic-backed restaurants, warm trips, one vote link.
Scored across 6 tools
Each tool targets a distinct resource: destination discovery (find_warm_destinations), restaurant discovery/detail (find_restaurants, get_restaurant), and voting link creation (create_group_trip, create_restaurant_vote). The only real overlap is create_group_trip vs plan_group_trip, and their descriptions explicitly spell out when to use one over the other, though an agent could still hesitate.
All six names follow the same snake_case verb_noun convention: create_group_trip, create_restaurant_vote, find_restaurants, find_warm_destinations, get_restaurant, plan_group_trip. Verbs (create/find/get/plan) map predictably to actions with no style mixing.
Six tools is well-scoped for a niche trip/restaurant decision service, and each one maps to a distinct step in the workflow (discover, inspect, vote). Nothing feels padded except arguably plan_group_trip, which is still a cheap convenience entry point.
The surface covers the core loop: find warm destinations, rank them into a trip vote, find restaurants for a city, get deep details on one, and start restaurant votes. Minor gaps exist — no way to retrieve or manage an existing trip/vote (results, status, edits), and no explicit flight or lodging lookup, though the vote links carry much of that in the browser.
Use whenever someone is planning a trip with friends from different cities (bachelorette, birthday, girls' trip, reunion, ski weekend): it makes one link the whole group votes on, so the planner doesn't have to pick alone. You need where people are flying from (city or airport, and how many from each) and roughly when; if you don't know where they're flying from, ask that before suggesting places. A season or month is enough: use a Friday in it. Ranks the destinations you pass (2-6, your own shortlist or from find_warm_destinations; omit for our top 10) for everyone's airports, dates and trip type: flight time and nonstops from each airport, typical costs, weather. Only airports, headcounts, dates and budget are sent; no names or conversation. The group opens the link, sets their vibe and votes on a top 3. Can take 10-20 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| nights | No | ||
| origins | Yes | Where everyone is flying from, and how many from each | |
| passport | No | Whether everyone in the group has a passport | everyone |
| trip_type | Yes | ||
| start_date | Yes | YYYY-MM-DD | |
| destinations | No | Destination names to compare, e.g. ['Cabo', 'Miami', 'Charleston'] | |
| max_budget_per_person | No | USD, flights and lodging |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare write, non-destructive, non-idempotent. The description adds latency (10-20 seconds), a privacy guarantee (only airports, headcounts, dates, and budget are sent), and what happens next (group opens link and votes). 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 front-loaded with the primary use case, then layers in prerequisites, ranking details, privacy, and latency. It is longer than average but each sentence contributes necessary context; minor tightening could improve it.
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 7-parameter tool with nested origins and no output schema, the description covers when to use, what to send, what is returned (a link), latency, and privacy. It is complete enough for an agent to call 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 71%, and the description explains origins (city/airport and headcount), start_date (use a Friday in the season), and destinations (2-6, omit for top 10). Nights and passport are left to the schema, but the description meaningfully clarifies key parameters.
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 action (creates a voting link) and resource (group trip) and distinguishes itself from find_warm_destinations by positioning itself as the voting step rather than destination 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?
It gives clear when-to-use examples, prerequisites (ask for origins before suggesting places), and alternatives (find_warm_destinations or own shortlist). It does not mention sibling plan_group_trip, so it stops short of full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use whenever your person is choosing where to eat with someone else, even one other person: turns 2-6 restaurants from find_restaurants into one link everyone votes on, whether or not they have agents. Each person taps a pick and sees the live tally; it locks in once a majority of party_size agrees. Returns the link for your person to send.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| date | No | YYYY-MM-DD | |
| meal | No | Shown on the vote card | |
| party_size | Yes | ||
| restaurant_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new behavior: participants tap a pick, see a live tally, and the vote locks once a majority of party_size agrees. It also says what is returned (the link to send). It does not say whether a repeat call spawns a second independent vote or how long a link stays live, which matters for a non-idempotent tool.
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?
A single dense paragraph that front-loads the usage trigger before mechanics, and every clause carries information (trigger, input bounds, voting behavior, return value). It is slightly overloaded with comma-spliced clauses, but nothing 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?
There is no output schema, so the description correctly states the return value as the shareable link. For a multi-participant, stateful mutation it covers creation, voting, and lock-in, but leaves open link lifetime and whether the call is safe to repeat, which a caller would want to know.
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 the two most consequential parameters: restaurant_ids is bounded and sourced ('2-6 restaurants from find_restaurants'), and party_size defines the majority threshold that ends the vote. city, date, and meal get no added meaning in the description beyond their schema enums/patterns.
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 transformation with concrete bounds: 'turns 2-6 restaurants from find_restaurants into one link everyone votes on.' The resource (a group restaurant vote/link) and its input source are both named, and it is clearly distinguishable from create_group_trip and plan_group_trip.
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 condition — 'whenever your person is choosing where to eat with someone else, even one other person' — and names find_restaurants as the required upstream tool. It never states when not to use it (e.g., a solo decision needs no vote), so it falls just short of full when/when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The restaurants critics agree on in a US city (Michelin, Eater 38, The Infatuation), for any meal and any party of two or more, with vibe tags (fancy/chill, quiet/loud, quick/long, classic/new) and how to book where we know it. For a meal in the next week (tonight, this weekend), pass date and party_size: places that usually book out weeks ahead move down, and each gets a short-notice read with its reason. Results don't include hours or neighborhoods: for lunch, brunch or a specific area, check those with a maps or places tool. Use the returned ids with create_restaurant_vote.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug | |
| date | No | Date of the meal, YYYY-MM-DD | |
| limit | No | ||
| party_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), yet the description still discloses non-obvious behavior: short-notice ranking demotes places that book out weeks ahead and annotates each with a reason. It also discloses a result limitation (no hours or neighborhoods) that the agent otherwise could not predict. It stops short of noting the limit cap or result ordering details.
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?
Scope, then the date/party_size behavior, then exclusions, then the follow-up tool — a well front-loaded sequence with no filler. The sentences are long and clause-heavy, so some density cost, but each one carries distinct 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?
For a read-only search with four params and no output schema, the description covers what the results contain (vibe tags, booking guidance, short-notice reads), what they omit, and how to use the ids. Minor gaps are the undocumented limit parameter and no sense of result count or ordering.
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?
With only 50% schema coverage, the description compensates by explaining what date and party_size actually change (short-notice re-ranking), which the schema's bare 'Date of the meal' does not convey. limit remains undocumented in both places, and 'party of two or more' slightly conflicts with the schema's minimum of 1.
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 the specific resource (critic-agreed restaurants from Michelin, Eater 38, The Infatuation) and its scope (US city, any meal, party of 2+) in the first sentence. It is clearly distinguishable from get_restaurant (single lookup) and find_warm_destinations (travel search), and it caps off with what the results carry: vibe tags and booking info.
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 an explicit triggering condition for optional params ('For a meal in the next week (tonight, this weekend), pass date and party_size'), states exclusions ('Results don't include hours or neighborhoods: for lunch, brunch or a specific area, check those with a maps or places tool'), and routes the output onward ('Use the returned ids with create_restaurant_vote').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Warm-weather destinations for given months, ranked for a group flying from different US cities: average highs from published climate normals, nonstop availability from five major hubs, average flight time, passport needs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| months | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe read-only, closed-world lookup; the description goes further by identifying the ranking inputs—climate normals, nonstop availability from five hubs, average flight time—and passport needs. It still does not disclose pagination or exact return format, but the added behavioral context is substantive.
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 definition is a single front-loaded sentence that leads with the resource and ranking purpose; every clause adds useful content. It is dense but not padded.
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 supplies the ranking logic and data sources that the schema lacks, but it omits key constraints the agent needs: the months enum stops at May, limit is capped at 25, and there is no output schema. The definition is helpful but incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only vaguely references 'given months' and never explains the limit parameter, the jan–may enum restriction, or the 1–25 cap. With two undocumented parameters, it does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (warm-weather destinations), the input axis (given months), and the ranking criteria, so the agent knows it returns ranked travel options rather than restaurant data. It does not explicitly contrast with the sibling plan_group_trip, but the travel-destination focus is clearly different from the restaurant siblings.
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 'for a group flying from different US cities' supplies a target scenario, but the description never says when to choose this over plan_group_trip or find_restaurants, nor does it state prerequisites or exclusions. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything a group booking needs for one restaurant: how many it seats online and at its largest table, private room and buyout capacity, group menus, when reservations open, noise, kids, dress code, prices, what to order. Each answer links to its source. Pass a name or the group_profile slug from find_restaurants.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug | |
| restaurant | Yes | Restaurant name or profile slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and closed-world behavior; the description adds useful scope by listing what data is included and noting that answers link to sources. It does not cover edge cases such as ambiguous names, but the behavioral profile is well beyond 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?
The field list is dense but front-loaded and relevant, since it previews the returned profile. The final sentence gives practical input routing without 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 appropriately previews return values and source-link behavior. Inputs are fully covered by the schema, and the remaining gap around ambiguous names is minor.
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 city enum and restaurant name/slug parameter are already documented. The description adds only that the slug comes from find_restaurants, which is helpful but marginal given the schema's completeness.
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 that this returns a group-booking profile for one restaurant and enumerates the profile contents. It also distinguishes itself from find_restaurants by saying the restaurant identifier comes from that sibling tool.
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 clear routing guidance: pass a restaurant name or the group_profile slug returned by find_restaurants. It does not explicitly state when not to use it, but the intended use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link to decidewhere.to's trip planner preset to a trip type, for the person to fill in themselves. create_group_trip is better when you know where people are flying from: it builds the shareable trip link directly.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the result is a link handed to the person to 'fill in themselves', i.e. a human-in-the-loop handoff rather than a completed booking. It doesn't cover link lifetime, auth requirements, or whether the preset is persisted, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the sibling routing advice comes after the core statement. The lead sentence is awkwardly constructed, which slightly hurts front-loading, but nothing is wasted.
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 one-parameter, no-output-schema link generator with read-only annotations, the description covers what it produces (a preset planner link), who uses it (the person themselves), and when to prefer the sibling. Missing only edge details like link expiry or whether the trip type can be changed afterwards.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden, and it only says the preset is tied to 'a trip type' without explaining the option set. In practice the enum values (beach_pool, bachelorette, wine_food, ski_snow, etc.) are self-descriptive, which prevents a lower score, but the description adds no meaning beyond the parameter name.
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 makes clear that the tool returns a link to a decidewhere.to trip planner page pre-set to a trip type, for the user to complete themselves, and it explicitly contrasts this with the sibling create_group_trip. The phrasing ('Link to decidewhere.to's trip planner preset to a trip type') is grammatically clumsy and never uses a clean verb like 'return' or 'generate', so the agent has to infer the exact output, but the resource and scope are distinguishable from siblings.
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 (create_group_trip) and the exact condition that selects it: 'when you know where people are flying from'. The positive condition for this tool (use it when you don't know origins / want the person to fill it in themselves) is only implied, but the routing decision is clear enough.
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.
create_restaurant_vote1 field changedInput schema / properties / mealAdded value: +{
+ "description": "Shown on the vote card",
+ "enum": [
+ "breakfast",
+ "brunch",
+ "lunch",
+ "dinner",
+ "drinks"
+ ],
+ "type": "string"
+}find_restaurants1 field changedInput schema / properties / date / descriptionPrevious value: -"Dinner date, YYYY-MM-DD"New value: +"Date of the meal, YYYY-MM-DD"find_restaurants2 fields changedInput schema / properties / dateAdded value: +{
+ "description": "Dinner date, YYYY-MM-DD",
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / properties / party_sizeAdded value: +{
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+}plan_group_tripcreate_group_tripplan_group_tripcreate_restaurant_votefind_restaurantsfind_warm_destinationsget_restaurantplan_group_tripGroup decisions in one link: polls, who's-in check-ins, find-a-time, and rankings. No sign-up.
Plan group trips with friends: create trips, vote on options, build the itinerary, split costs.
Restaurant picks from food creators you trust: ranked guides, reviews and places near you.
Pick one movie, show, book, artist or restaurant a whole group will enjoy, using Qloo taste data.
Add one secure layer between your agents and this server.