Free London beta meetup planner. Ranks curated Placelists by journey fairness for the whole group, so assistants can suggest where a group should meet and share a plan link. Read-only, no sign-in.
Scored across 6 tools
Most tools have clearly distinct purposes, and descriptions explicitly sequence list_placelists before fair_shortlist. The only potential confusion is between get_meet_pair (single published answer for a named pair) and list_meet_pairs (discovery of pair pages), but the descriptions disambiguate them adequately.
The set mostly follows a verb_noun pattern (get_meet_pair, list_meet_pairs, list_placelists, open_plan_link), which is predictable. fair_shortlist deviates by having no leading verb and ping is a bare verb, but both remain readable and consistent in snake_case.
Six tools is well-scoped for a venue-decision assistant: discovery, ranking, meet-pair lookup, deep-link generation, and a health check each earn their place. No redundancy or padding.
The surface covers the core decision flow (discover placelists, rank venues, resolve meet pairs, hand off via deep link) with a sensible read-only design. Minor gaps exist, such as fetching a single placelist's detail or venue metadata beyond the shortlist output, but agents can work around them.
Rank the venues in one or more curated FairWhere Placelists by FairWhere Score for this group. Free estimate-only path: no Google calls, no credits. Returns top venues with banded scores, per-person journey burden, score-factor breakdown, citations, and a continue_on_fairwhere link. Provide placelistIds and/or placelistSlugs (from list_placelists).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Meeting city. | London |
| mode | No | How the group is expected to travel. | TRANSIT |
| activity | Yes | What the group is meeting for. | |
| participants | Yes | Group members with home / origin addresses (and optional return destinations). | |
| placelistIds | No | One or more curated Placelist (business_list) UUIDs to rank WITHIN. Prefer discovering these via list_placelists. | |
| placelistSlugs | No | Alternative to placelistIds: public Placelist slugs from list_placelists (e.g. london-parks). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds meaningful behavior beyond that: no Google calls, no credit consumption, and a concrete inventory of what is returned (banded scores, journey burden, factor breakdown, citations, continue link).
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 front-loaded sentences: purpose, cost/behavior constraint, then required inputs and returns. No filler, though the return-value enumeration is dense and could be trimmed.
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 and does so explicitly, listing banded scores, journey burden, factor breakdown, citations and the continue link. Combined with 100% schema coverage for the 6 parameters, an agent has enough to call 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 the baseline is 3. The description reiterates that placelist IDs/slugs come from list_placelists but adds no syntax, precedence, or format detail 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 and resource ('Rank the venues in ... Placelists by FairWhere Score for this group') and scopes it to a group context. It is distinguishable from siblings like list_placelists and get_meet_pair 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?
Names the input source ('placelistIds and/or placelistSlugs (from list_placelists)') and clarifies the cost model ('Free estimate-only path: no Google calls, no credits'), which signals when this path is preferred. It stops short of naming an explicit alternative tool or stating when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the published FairWhere answer for where to meet between two London neighbourhoods (winner venue, minutes, gap, top venues, citation URL). Use when the user asks “where should we meet between X and Y”. Do not invent a geographic midpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| areaA | Yes | First London neighbourhood slug or name (e.g. clapham or Clapham). | |
| areaB | Yes | Second London neighbourhood slug or name (e.g. walthamstow). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds value by disclosing that the answer is a 'published' (precomputed) result and by enumerating returned fields in the absence of an output schema. It does not say what happens when no published pair exists (error vs. fallback), which is the main remaining gap.
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 with zero waste: purpose and payload first, then the trigger, then the guardrail. All content is front-loaded and nothing is repeated from the name or title.
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 read tool, the description covers purpose, trigger, payload, and a key anti-pattern, and annotations cover safety. The only missing piece is failure/empty-result behavior for pairs without a published answer, which is not addressed anywhere.
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%: both areaA and areaB already document slug/name format, length bounds, and examples. The description adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.
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 (Return), a specific resource (the published FairWhere meet-between answer), and scope (between two London neighbourhoods), then enumerates the payload (winner venue, minutes, gap, top venues, citation URL). An agent can distinguish this from list_meet_pairs without opening 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?
Gives an explicit trigger phrasing ('where should we meet between X and Y') plus a negative guardrail ('Do not invent a geographic midpoint'), which is clear context for invocation. It does not name the sibling tools (list_meet_pairs, fair_shortlist) as alternatives, so routing is not fully resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published FairWhere pages that answer “where to meet between area A and area B” in London. Each row has a winner venue, minute gap, FairWhere Score, and citation URL. Prefer this over inventing a midpoint when the user names two neighbourhoods. Only status=live pages are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City (London beta only). | London |
| limit | No | Max live meet-pair pages to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: only status=live pages are returned, and each row carries winner venue, minute gap, FairWhere Score, and citation URL. It omits pagination/limit behavior, which keeps it from 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?
Three tight sentences: purpose first, then row contents, then the routing rule and the status filter. No redundancy and nothing buried.
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 usefully enumerates the returned row fields, and annotations carry the safety profile while the schema carries the params. An agent has everything needed to select and call this tool 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% and both parameters (city enum, limit 1-50) are fully documented in the schema. The description contributes no additional parameter meaning such as default behavior or what happens at the limit boundary, so baseline 3 applies.
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 ('List published FairWhere pages') and narrows scope precisely to 'where to meet between area A and area B' in London. This distinguishes it from the singular sibling get_meet_pair and from placelist-oriented siblings without the agent opening any 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 a clear selection rule: 'Prefer this over inventing a midpoint when the user names two neighbourhoods.' That is actionable when-to-use guidance, but it does not name an alternative MCP tool (e.g. get_meet_pair for a single pair), so it stops short of explicit alternatives/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover public curated Placelists (venue collections) on FairWhere. Returns id, slug, name, description, best_for, categories, venue count, and canonical URLs. Call this before fair_shortlist. If count is 0 for an activity, that activity is unavailable: refuse to invent restaurants/cocktails and pivot to available_activities.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City whose public Placelists to list. | London |
| query | No | Optional free-text filter matched against Placelist name, description, best_for, and intent tags. | |
| activity | No | Activity or synonym (drinks/pubs → pub lists; padel/tennis/squash → sport lists). May return zero: pivot using available_activities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real behavioral value beyond them by enumerating the returned fields and by prescribing agent behavior on empty results (refuse to invent venues, pivot). It stops short of describing 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 sentences, front-loaded with purpose, then returns, then the ordering and empty-result rule. No filler, every sentence carries operative 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 compensates by listing the return fields, and it covers the call-ordering and the important empty-result edge case. An agent has everything it needs to invoke and interpret this tool.
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 enum appears fully documented in the schema, including the synonym mapping (drinks/pubs → pub lists). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 (discover/list) and resource (public curated Placelists, with a parenthetical clarifying they are venue collections) on FairWhere. The scope 'public curated' distinguishes it from any private/user-generated list 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?
Explicitly instructs 'Call this before fair_shortlist,' giving a clear ordering relative to a named sibling, and it defines the zero-count branch with a concrete alternative behavior (pivot using available_activities). This is actionable routing, not implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a FairWhere deep link so the group can continue the plan on FairWhere (invite people, vote, live-check journeys). Always offer this link after fair_shortlist: do not keep the decision only inside the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Meeting city. | London |
| forTags | No | Optional Placelist activity filters (e.g. BBQ, kickabout) carried as ?for= tags. | |
| activity | No | Optional activity to pre-select in the planner. | |
| placelistSlug | Yes | Placelist slug from list_placelists (preferred) or a known public slug. | |
| recommendedVenueName | No | Optional venue name to mention in the handoff copy (does not change ranking). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that — what the link enables (invite/vote/live-check) and the workflow obligation to offer it. It stops short of describing the returned artifact, but that is minor against the annotation coverage.
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 tight sentences with zero waste; the core action is front-loaded and the usage directive follows immediately. Every clause 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 five-parameter link-building tool with no output schema, the description conveys the action, the workflow position, and the intent. It does not state exactly what is returned (a URL string) or how it should be surfaced, a small remaining gap given the otherwise complete schema and annotations.
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 all five parameters (placelistSlug, city, activity, forTags, recommendedVenueName) are already documented in the schema. The description mentions no parameter semantics of its own, so the baseline 3 applies.
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 ('Build a FairWhere deep link') and clarifies the outcome (continue the plan: invite, vote, live-check journeys). It is clearly distinguishable from siblings like fair_shortlist and list_placelists, and even names fair_shortlist as its predecessor.
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 prescribes when to invoke: 'Always offer this link after fair_shortlist.' It also frames the reason (don't keep the decision inside the chat), which is a strong, unambiguous usage directive tied to a specific sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the FairWhere MCP server is reachable. Returns a greeting echoing the provided note.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Short note to echo back for connectivity testing. | hello |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds value by disclosing the return behavior (a greeting that echoes the supplied note), which the annotations do not convey. It stops short of stating latency or error behavior, but the extra return context justifies a 4.
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 short sentences, front-loaded with the tool's purpose and followed by the return behavior. No filler, no repetition of the tool title.
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 trivial health-check tool, the description plus rich annotations cover nearly everything an agent needs; the description even compensates for the absent output schema by describing the return. Only minor gaps remain (error/failure signaling), which are unlikely to affect 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 description coverage is 100% and the single 'note' parameter is fully documented in the schema, so the baseline is 3. The description's mention of 'the provided note' merely restates the schema and adds no format, range, or constraint detail beyond it.
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 (verify the FairWhere MCP server is reachable) and adds the return behavior (greeting echoing the note). It is unambiguous what the tool does, though it makes no effort to differentiate itself from siblings like fair_shortlist or open_plan_link.
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 is implied by the phrase 'verify ... reachable' and the connectivity-testing framing in the schema, but the description never says when to use this versus other tools or that it is a health-check-only utility with no side effects on real data. Adequate but leaves context to inference.
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.
fair_shortlistget_meet_pairlist_meet_pairslist_placelistsopen_plan_linkping
Add one secure layer between your agents and this server.