Return a salon's service menu (schema.org Menu shape: sections of priced services). Salon counterpart to get_menu. salon_id and entity_id are aliases; pass either.
| Name | Required | Description | Default |
|---|---|---|---|
| salon_id | No | ||
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds value by revealing the return structure ('sections of priced services') and the alias relationship between parameters, which are meaningful behavioral details not present in the annotations.
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 exceptionally concise: two sentences deliver the core purpose, return format, sibling differentiation, and parameter alias guidance without any redundant or filler content. Every phrase earns its place, making it easy to parse.
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?
Given the absence of an output schema, the description helpfully outlines the return shape ('schema.org Menu shape: sections of priced services') and clarifies parameter usage. It does not mention edge cases like pagination or limit behavior, but for a straightforward menu-listing tool with good annotations, this is a satisfactorily complete context.
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 no parameter descriptions (0% coverage), leaving the description to carry the burden. It explains that salon_id and entity_id are aliases and that either can be passed, which is a key semantic clarification. However, it does not elaborate on what each ID represents conceptually or any formatting/validation expectations, so the compensation is only partial.
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 unambiguously states the tool's function: 'Return a salon's service menu' with a clear schema.org Menu shape. It also differentiates from a sibling by explicitly calling itself the 'Salon counterpart to get_menu', making its purpose distinct among the many tools.
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 gives clear usage context by positioning this as the salon-specific service menu tool and noting 'salon_id and entity_id are aliases; pass either'. It does not explicitly exclude alternative tools like get_salon or get_details, but the 'Salon counterpart to get_menu' phrasing provides enough directional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
There is notable overlap among search, search_web, search_restaurants, and search_salons, as well as between filter_restaurants/filter_salons and search with constraints. However, descriptions clarify the intended vertical or corpus, and entity getters are distinct. The overlap is manageable but could cause misselection.
Names mostly follow a get_/list_/search_/register_/delete_/submit_/vote_ pattern in snake_case. Minor deviations like 'recall', 'remember', 'research', and 'travel_health' are less predictable but still readable. Overall consistent and clear.
38 tools is on the heavy side for a single MCP server, exceeding the typical well-scoped range. While the server covers multiple subdomains (search, travel disruptions, memory, feedback, research), the sheer number may overwhelm agents and suggests potential consolidation.
The tool surface covers core workflows: search and entity retrieval for restaurants/salons, disruption monitoring with standing queries and webhooks (register/list/delete), research submission/polling, and memory/feedback mechanisms. Minor gaps exist (e.g., no cancel for research jobs, no explicit entity list endpoint), but these are workable and do not break typical agent tasks.