business_infoUse this when the user asks about Johnson Bros. contact details, credentials, hours, payment methods, service area, or booking process. Do not use it for live availability or a customer-specific record.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | ||
| booking | Yes | ||
| success | Yes | ||
| business | Yes | ||
| review_sandbox | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context about the information scope (e.g., hours, payment methods) but does not mention any additional behavioral traits like rate limits or auth requirements, which are not needed here given the read-only nature.
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 concise sentences: first states the purpose, second gives the exclusion. No filler, front-loaded with the main use case.
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 zero-parameter, read-only tool with an output schema, the description fully covers when to use it and what it provides. No missing guidance for an agent to call it correctly.
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?
Tool takes zero parameters, so there is nothing to explain. Baseline of 4 is appropriate given no parameter documentation is needed.
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?
Description clearly states the tool provides Johnson Bros. contact details, credentials, hours, payment methods, service area, and booking process. It uses specific verbs and names the resource, making it distinct from siblings like check_service_area or get_availability.
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?
Explicitly states when to use the tool and when not to: 'Do not use it for live availability or a customer-specific record.' This gives clear routing guidance against siblings that handle those cases.
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.
Most tools have clear, distinct purposes: business_info vs search vs get_services_pricing are separable. However, get_services_pricing and get_quote overlap somewhat—both provide pricing info, though one is for general browsing and the other for specific estimates. The descriptions do help distinguish them, so the ambiguity is low.
Tool names generally follow a verb_noun pattern (e.g., business_info, check_service_area, confirm_booking, get_availability, get_quote). Some names are single verbs or nouns (e.g., fetch, search) which deviate slightly, but overall the pattern is consistent and predictable.
11 tools is within the ideal range for a booking-focused MCP server. Each tool covers a distinct part of the customer journey: info lookup, service area check, pricing, availability, booking, confirmation, callbacks, emergencies, and document retrieval. No tool seems redundant or unnecessary.
The tool set covers the core booking lifecycle: check service area, get availability, request booking, confirm booking, request callback, and get quotes. Emergency help is also provided. Minor gaps include lack of a cancel/update booking tool, but the server context suggests that might not be needed for the public-facing purpose.