Sauna Guide Quotes

Start a personal sauna provider search

submit_sauna_quote_request

DestructiveIdempotent

Store a complete sauna project request and send confirmation and internal notification emails. Call only after prepare_sauna_quote_request and after the user explicitly approves submission. This never subscribes the user to a newsletter and never shares contact details with providers.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	Yes	City where the sauna will be installed.
`email`	Yes	Email address for personal provider-search updates.
`notes`	No	Optional project details such as space, access, foundation, or electrical work.
`phone`	Yes	US phone number for questions about the project.
`state`	Yes	Two-letter US state code for the project.
`budget`	Yes	Expected project budget range in US dollars.
`heatType`	Yes	Preferred sauna heat type, or hybrid_or_unsure when not decided.
`timeline`	Yes	Expected purchase or installation timeline.
`requestId`	Yes	The requestId returned by prepare_sauna_quote_request for this project.
`postalCode`	Yes	US ZIP code where the sauna will be installed.
`contactName`	Yes	Name of the person requesting the quote.
`projectType`	Yes	Prebuilt, custom indoor, custom outdoor, or not yet decided.
`brandOrModel`	No	Optional sauna brand or model already under consideration.
`confirmRequest`	Yes	Set to true only after the user explicitly approves storing the request and sending confirmation and internal notification emails.
`electricalReadiness`	No	Optional description of the electrical power currently available at the site.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`testMode`	Yes
`duplicate`	Yes
`requestId`	Yes
`updateTiming`	Yes
`newsletterOptIn`	Yes
`contactDetailsSharedWithProvider`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful side-effect context beyond annotations: it stores a request, sends confirmation/internal emails, and explicitly excludes newsletter subscription and provider contact sharing. However, it does not elaborate on the destructiveHint=true annotation, such as whether the prepared request is consumed or whether submission is irreversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: function first, then the call conditions, then the privacy guarantees. Every sentence carries distinct useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter tool with a full schema and output schema, the description covers the essential call sequence and consent requirement. The only notable gap is the meaning of destructiveHint=true, which is left to the annotation without explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter (including confirmRequest and requestId) is documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('Store a complete sauna project request') and its side effects ('send confirmation and internal notification emails'). It also situates the tool relative to its only sibling ('after prepare_sauna_quote_request'), so an agent can tell submit from prepare.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit preconditions: call only after prepare_sauna_quote_request and only after the user explicitly approves submission. This clearly tells an agent when the tool is appropriate and when it is premature.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Sauna Guide Quotes tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

prepare_sauna_quote_request is explicitly read-only validation, while submit_sauna_quote_request stores data and sends emails. Their side effects are completely disjoint and the required call order is stated clearly.

Naming Consistency5/5

Both tool names follow the same snake_case verb_object pattern using the same object, 'sauna_quote_request'. There are no mixed naming conventions or vague verbs.

Tool Count4/5

Two tools is slightly below the typical range, but the server has a narrow, well-defined purpose: validate and submit a quote request. Each tool is necessary, though the surface feels minimal.

Completeness4/5

The prepare/submit pair covers the core request intake lifecycle with clear guardrails and expected behavior. There is no tool to retrieve, edit, or cancel a submitted request, which is a minor gap if users need to manage existing requests.

Resources

Need Help?