This server lets you search and explore cold plunge, sauna, and contrast-therapy venue data across US metros.
search_venues: find venues by name query, city, modality (cold plunge, sauna, steam, cryotherapy, etc.), access type, and maximum published drop-in price; filters combine and only match published facts.
get_venue: retrieve the full record for a specific venue, including per-fact source URLs and capture details.
list_cities: see all covered cities with venue counts and available modalities.
get_city_stats: get aggregate stats for a city, including venue counts, modality/access breakdowns, contrast-therapy availability, and median published prices/temperatures with denominators.
get_data_freshness: check when the dataset was generated and how recently venues were verified.
Model Context Protocol server for findsaunaplunge.com: cold plunge, sauna and contrast-therapy venues across US metros. get_data_freshness reports the current venue count and the dates the records were last checked. Every published temperature and price is read from the venue's own pages and carries its source URL, capture date and verbatim quote. Absent fields mean the venue does not publish that detail — never zero.
Endpoint: https://findsaunaplunge.com/mcp — Streamable HTTP, stateless, no auth, open CORS. GET serves human documentation; POST is JSON-RPC.
Registry: com.findsaunaplunge/findsaunaplunge (domain-verified).
Data: same records as the CC BY 4.0 feed /api/v1/venues.json; archived monthly at github.com/findsaunaplunge/data, DOI 10.5281/zenodo.22132913.
Tool | Arguments | Returns |
|
| Compact venue records; filters AND-combine. |
|
| The full feed record, including per-fact |
| — | Covered cities with venue counts and available modalities. |
|
| Counts, published price and temperature ranges, contrast-capable venues. |
| — | When the feed was built and the newest/oldest |
Related MCP server: Eventflare MCP
# Claude Code
claude mcp add --transport http findsaunaplunge https://findsaunaplunge.com/mcp
# Any client, by hand
curl -s -X POST https://findsaunaplunge.com/mcp -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_venues","arguments":{"citySlug":"austin-tx","modality":"cold_plunge","limit":3}}}'The handler needs nothing but the public feed, so it runs anywhere with Node 24+:
npm start # JSON-RPC over stdio, one message per line (= node src/serve.ts --stdio)
npm run http # Streamable HTTP on :8080 — POST /mcp (= node src/serve.ts)
docker build -t findsaunaplunge-mcp . && docker run -i findsaunaplunge-mcp # stdio
npm test # smoke test: stdio + HTTP against the live feedBoth modes read https://findsaunaplunge.com/api/v1/venues.json (override with FINDSAUNAPLUNGE_ORIGIN), so a self-hosted copy serves exactly what the site serves.
src/mcp.ts is the whole server: one handleMcp(request, env) function mounted at /mcp inside the site's Cloudflare Worker. It has no dependencies. Tool results come from the static /api/v1/venues.json asset produced by the site build (fetched through the Worker's ASSETS binding and memoized per isolate), so the server can never disagree with the site and a deploy refreshes it automatically. server.json is the registry manifest.
This repository is the published source of that server. The site itself is not open source.
Stateless: no sessions, no server-initiated SSE. Every POST is self-contained.
Unknown arguments are rejected with a message naming the valid ones, rather than silently ignored.
Nothing here is, or will be, a paid placement.
MIT — see LICENSE. The venue data the server serves is separately licensed CC BY 4.0.
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.
v1.0.1get_city_statsget_data_freshnessget_venuelist_citiessearch_venuesScored across 5 tools
Each tool targets a distinct purpose: search vs. detail retrieval, city listing vs. city statistics, and dataset freshness. There is no meaningful overlap that would cause an agent to select the wrong tool.
All tool names follow a consistent verb_noun snake_case pattern, with search_, get_, and list_ used predictably. This makes the toolset easy to navigate and understand.
Five tools is well-scoped for a venue discovery server: search, detail lookup, city listing, city stats, and freshness metadata. Each tool earns its place with no bloat or redundancy.
The read-only venue discovery domain is fully covered: discovery, detail, aggregate insights, and data quality reporting. There are no obvious gaps or dead ends for an agent trying to answer venue-related questions.
US local-services data: find locals by trade and city, browse open jobs, see which markets answer
Verified US local service providers across 10 home-services trades. Owned data, no API key.
One API for public web data across social, directories and real estate, as clean JSON.
CMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
