Cold plunge, sauna and contrast-therapy studios across US metros, each fact dated.
Scored across 5 tools
Each tool targets a clearly distinct purpose: detailed city aggregates, dataset freshness metadata, individual venue lookup, city listing, and filtered venue search. There is no meaningful overlap or risk of confusing one tool for another.
All five tool names follow the same snake_case verb_noun pattern: get_, list_, and search_. This makes the tool surface predictable and easy for an agent to navigate.
Five tools is well-scoped for a read-only venue discovery and analytics server. Each tool earns its place and collectively they cover both raw venue lookup and aggregate city-level insights.
The surface covers venue search, venue detail retrieval, city enumeration, city-level statistics, and data freshness checks. For a read-only directory and analytics domain, this is a complete and coherent set with no obvious dead ends.
Aggregate figures for one covered city: venue count, modality and access breakdowns, contrast-capable count, and median published prices and plunge temperature. Every median carries its denominator (n) — absent fields are excluded, never treated as zero.
| Name | Required | Description | Default |
|---|---|---|---|
| citySlug | Yes | City slug, e.g. "dallas-tx". Use list_cities to discover. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses important return semantics: medians include denominators, and absent fields are excluded rather than zeroed. This reduces misinterpretation risk, though it doesn't cover invalid-city behavior or response shape.
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 with no filler: the first states purpose and contents, the second clarifies denominator and zero-handling semantics. Information is front-loaded and 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 single-parameter read-only aggregation tool with no output schema, the description is complete: it lists all returned metric groups, explains median denominators, and handles the ambiguous zero case. Nothing required to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains citySlug with an example and points to list_cities. The description adds 'covered city' context but doesn't need to document parameter semantics further; 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?
The description uses a specific verb ('Aggregate') and names the resource ('figures for one covered city') with a concrete list of outputs. This clearly distinguishes it from sibling tools like get_venue (single venue) and search_venues (search), even though it doesn't name them explicitly.
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 opening phrase 'Aggregate figures for one covered city' clearly indicates the tool is for city-level statistics rather than venue-level retrieval or discovery. It doesn't explicitly say when not to use it or name alternatives, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When the dataset was generated and how recently venues were checked: oldest and newest lastVerified dates, counts by age bucket, and the newest check date per city.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It specifies what kind of data the agent receives: oldest and newest lastVerified dates, counts by age bucket, and the newest check date per city. It does not state side-effect behavior or limitations, but for a parameterless 'get' tool, the output contents are the main behavior and they are well specified.
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?
One sentence with a colon introducing a clean list of output components. It front-loads the underlying question and contains no filler, redundant phrasing, or restatement of the title beyond the essential resource.
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 no-parameter, no-output-schema tool, the description covers everything an agent needs: the topic (dataset generation time and venue-check recency) and the exact slices it returns (ranges, bucketed counts, per-city newest check). The absence of an output schema makes this specificity especially valuable.
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 has zero properties, so schema description coverage is trivially 100%. There are no parameters for the description to explain, and it correctly spends its words on output semantics. The baseline of 4 for a parameterless tool 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 identifies the resource—dataset freshness—and enumerates the returned information: lastVerified ranges, age-bucket counts, and per-city newest check date. It lacks an explicit verb like 'returns' or 'retrieves' and does not directly reference sibling tools, but its content distinguishes it from get_city_stats, get_venue, list_cities, and search_venues.
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 'When the dataset was generated and how recently venues were checked' sets a clear use case: an agent needing freshness metadata will know to select this tool. However, it does not explicitly say when not to use it or name alternatives, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record for one venue by its stable id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Venue id, e.g. "alive-and-well-dallas-tx". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It communicates that the operation is a read ('fetch') and that the response contains the full record, which gives useful behavioral context. However, it does not address what happens for an unknown id, error cases, or any other side effects.
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 sentence that is direct, front-loaded with the action and target, and contains no filler. 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 simple one-parameter get-by-id tool, the description is nearly complete: it identifies the input, the lookup key, and the type of output ('full record'). Lacking an output schema, a bit more detail about the record shape would help, but the low complexity keeps this from being a significant 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 schema already documents the single parameter with 100% coverage and an example value. The description adds no additional semantic detail beyond what the schema provides, so the baseline of 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?
The description states a specific verb ('fetch'), a specific resource ('full record for one venue'), and a clear lookup mechanism ('stable id'). This distinguishes it from siblings like list_cities and search_venues, which clearly serve different purposes.
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 clearly implies the tool is to be used when you already have a venue's stable id and need the full record. It does not explicitly mention alternatives or exclusions, but the 'by its stable id' phrasing provides enough context to avoid confusion with search/list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cities with live venues, with counts and available modalities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the output content (cities, counts, modalities), which is useful, but it does not explain what 'live' means, whether the response is limited, or any freshness/availability behavior. Still, for a simple listing tool, this is a reasonable but not rich disclosure.
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 short sentence with no filler. It front-loads the main subject and packs the key output aspects (counts, modalities) compactly.
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 and no annotations, the description is the only source of information. It gives a high-level view of the result, but leaves terms like 'live venues' and 'modalities' undefined and does not clarify the distinction from the similarly named sibling get_city_stats.
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 parameter documentation is unnecessary. The baseline of 4 applies because there is no parameter ambiguity to resolve.
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 identifies a specific resource ('cities with live venues') and the information returned ('counts and available modalities'). It is distinguishable from siblings like get_venue or search_venues, though it does not explicitly call out the difference from get_city_stats.
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 this tool is for getting an overview of covered cities, but it does not state when to prefer list_cities over get_city_stats or search_venues, nor does it mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search cold plunge / sauna venues. All filters are optional and AND-combined. Absent fields in results mean "not published", never zero.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 10, cap 25. | |
| query | No | Substring match on venue name (case-insensitive). | |
| access | No | private_suite = your own room; communal = shared areas; mixed matches either request. Venues that do not publish their access model are excluded whenever this filter is used — absence of the fact is not a match. | |
| citySlug | No | City slug, e.g. "dallas-tx". Use list_cities to discover. | |
| modality | No | Venue must offer this modality. | |
| maxDropInUsd | No | Only venues with a PUBLISHED drop-in price at or below this. Excludes venues with no published price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It adds valuable non-obvious semantics: all filters are optional and AND-combined, and absent fields mean 'not published', never zero. This goes beyond what the schema alone conveys and prevents misinterpretation of result 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?
The description is two sentences and every clause adds information. The first sentence states the core purpose, and the second conveys critical interaction and result semantics without unnecessary elaboration.
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 simple and the schema covers each parameter and enum, but there is no output schema and the description does not specify what a search result contains, such as venue IDs, names, or location fields. It also does not mention ordering or pagination beyond the limit parameter, leaving some gaps for an agent deciding how to use 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?
The input schema already documents all six parameters with 100% coverage, so the baseline is 3. However, the description adds cross-parameter semantics not present in the schema: filters are optional and AND-combined. This meaningfully affects how an agent should combine multiple query 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 opens with a clear verb and resource: 'Search cold plunge / sauna venues.' The mention of optional, AND-combined filters and the absent-fields semantics helps distinguish this search tool from sibling tools like get_venue or list_cities, which have different purposes.
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 this tool is for finding venues by optional filters, but it never explicitly contrasts it with alternatives like get_venue or list_cities. The guidance is inferential rather than stated, so an agent gets a general sense of when to use it but no explicit exclusions.
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.
get_city_statsget_data_freshnessget_venuelist_citiessearch_venuesScores US metros on corporate investment catalysts and repricing signals for real estate investors.
Query 4,300+ ranked metros across sixteen dimensions: profiles, search, and head-to-head comparisons
Human-verified directory of non-alcoholic bars: 1,500+ venues in 70 cities, rated and re-checked.
US local-services data: find locals by trade and city, browse open jobs, see which markets answer
Add one secure layer between your agents and this server.
