Agent Salon SF

Search salons

search_merchants

Read-onlyIdempotent

Filter collection=public-research for researched menus, add-ons, public stylist information and policies. Call get_merchant for the full public_research object. Discovery and name/address lookup, not an extras-inclusive price decision. For a supported service with budget, extras or date, start with compare_options. Find San Francisco hair salons and barbers by name/street (q), neighborhood (with nearby), service, date/time and online booking. Returns compact task summaries by default: depth (profiled = researched in depth; listed = public records + the business’s own site, see depth_note), booking_cta, hours_for_day (published hours for date, not live slots), up to 3 matched_offerings with prices, license_status, freshness, availability_basis (published_hours / schedule_candidates = unconfirmed / none); profiled salons add candidate_start_times. Unknown values are null. For published hours/detail only, call check_availability. Before selecting a budget option, call compare_options; follow next_action to confirm unresolved charges and actual appointment availability with the merchant.

Input Schema

Name	Required	Description
`q`	No	Business name or street, fuzzy (e.g. "cinta", "hairshaper", "23 grant")
`day`	No	Open on this day per published hours: Mo..Su or e.g. "saturday"
`date`	No	YYYY-MM-DD in the city’s timezone (default today): hours_for_day is computed for this date
`view`	No	summary = compact task view (default); full = every field
`after`	No	HH:MM earliest start (with date); applied to start times only under require_availability
`depth`	No	Only salons of this depth: profiled (booking-system depth), detailed (priced menu + booking link + hours or durations), listed (the rest)
`limit`	No	Default 10, max 25
`before`	No	HH:MM latest start (with date); applied to start times only under require_availability
`offset`	No
`service`	No	Service tag (e.g. "balayage"), intent slug (e.g. "hair-color", "open-saturday", "mens-haircut") or free text
`stylist`	No	Stylist display name (profiled salons)
`max_price`	No	Base offering price in USD, not the complete service with extras; use compare_options for that. Only offerings whose price is KNOWN to be at most this (fixed or bounded range); starting prices do not count
`specialty`	No
`collection`	No	Only independently researched public-source profiles; missing fields are UNKNOWN; booking stays on salon website
`open_after`	No	Closes after HH:MM (on `day` if given)
`time_after`	No	HH:MM — with date: only intervals open after this time count
`hair_length`	No
`has_booking`	No	Only salons with (true) / without (false) an online booking link
`time_before`	No	HH:MM — with date: only intervals open before this time count
`haircut_type`	No	Only salons with an offering of this normalized haircut type (profiled salons)
`neighborhood`	No	Neighborhood slug, label or alias (e.g. "soma", "mission") or an area (e.g. "union-square")
`open_on_date`	No	Only salons open on `date` per published hours (not live slots)
`include_nearby`	No	With neighborhood: also include salons within ~400 m (match="nearby", distance_label). Default true.
`require_availability`	No	Only offerings with PROVIDER-CONFIRMED start times in the date/after/before window. Schedule-derived candidate start times never satisfy it; salons that have only candidates are returned under `unconfirmed` with unconfirmed_reason. No salon has provider-confirmed availability today.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / collection

Added value: +{
+  "const": "public-research",
+  "description": "Only independently researched public-source profiles; missing fields are UNKNOWN; booking stays on salon website",
+  "type": "string"
+}

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), but the description adds substantial context beyond that: the default compact return shape, the null-for-unknown convention, what hours_for_day actually means (published hours, not live slots), the availability_basis taxonomy, the ~400m nearby behavior, and the blunt caveat that no salon currently has provider-confirmed availability. This is unusually candid about limits.

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

Conciseness4/5

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

Front-loaded with the collection filter and the sibling routing before the long return-value enumeration, and nearly every clause carries information. It is, however, a run-on paragraph with a dense semicolon chain that could be broken into labeled bullets for faster scanning.

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

Completeness5/5

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

With 24 optional params and no output schema, the description carries the return-value burden itself and does so thoroughly: default vs full view, matched_offerings cap, candidate_start_times for profiled salons, availability_basis values, and null semantics. An agent can call and interpret results without guessing.

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

Parameters4/5

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

Schema coverage is already 88%, and the description still adds meaning on top: depth distinctions (profiled/listed with depth_note), max_price explicitly excluding starting prices, and collection's 'missing fields are UNKNOWN' semantics. A few params (specialty, hair_length) get nothing beyond the schema, so not a full 5.

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?

States a specific verb and resource (search/filter the public-research collection for salons) plus the discovery scope (name/street, neighborhood, service, date/time, booking). It explicitly separates itself from siblings by naming get_merchant for full records and compare_options for price decisions, so an agent can route without opening schemas.

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?

Gives explicit when-to-use ('Discovery and name/address lookup'), an explicit when-not ('not an extras-inclusive price decision'), and named alternatives with the conditions that select them (compare_options for budget/extras/date, check_availability for published hours/detail only, get_merchant for the full object). It also prescribes a next_action follow-up before selecting a budget option.

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

All Agent Salon SF tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?