Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@qasperai/mcp-server find a plumber in Austin"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Qasper — discover and book local service businesses (barbers, dentists, plumbers, hair salons, mechanics, and more) directly from any MCP-compatible AI assistant.
This package is a thin stdio shim that proxies to Qasper's hosted MCP server at https://qasper.ai/mcp. All tool definitions are pulled live from the upstream so this package never goes out of date.
SearchBusinesses — find local businesses by category and location (text or lat/lng).
GetBusinessInfo — name, hours, languages, contact info.
GetServices — service catalog with durations and price ranges.
GetPricing — quote a service with emergency / weekend modifiers.
CheckAvailability — open slots from the business's calendar.
BookAppointment — create a confirmed booking.
SendInquiry — send a free-form question or quote request.
Related MCP server: Relay
The server is hosted at https://qasper.ai/mcp and can be used directly by any MCP client that supports remote (HTTP) servers — no install required:
{
"mcpServers": {
"qasper": {
"url": "https://qasper.ai/mcp"
}
}
}For clients that only support stdio, add to claude_desktop_config.json:
{
"mcpServers": {
"qasper": {
"command": "npx",
"args": ["-y", "@qasper/mcp-server"]
}
}
}npx -y @qasper/mcp-serverEnv var | Default | Description |
|
| Upstream MCP endpoint. |
MIT
Book an appointment with a local service business. Creates a booking record and adds the appointment to the business calendar. Returns a reference number and a status field indicating the actual resulting state — 'pending' (the business reviews each booking), 'confirmed' (auto-approved by the business), or 'completed' (the business auto-finalizes). Use a dateTime returned by check_availability for the selected service so bookingStartPolicy is respected. For services with maxParticipants > 1, the start can be booked until remainingCapacity reaches 0. Read the status and statusDescription verbatim and relay them accurately: do NOT tell the customer 'confirmed' when the status is 'pending'. If the selected service has requiresCustomerAddress=true, ask the customer for their full service address before calling this tool and pass it as customerAddress. ONLY call this if the business has 'booking' in its enabledFeatures array.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. | |
| serviceName | Yes | The name of the service to book | |
| dateTime | Yes | Appointment start date and time in ISO 8601 format (e.g. '2026-04-07T14:00:00+03:00') | |
| customerName | Yes | Full name of the customer | |
| customerPhone | Yes | Customer phone number | |
| customerEmail | Yes | Customer email address | |
| jobDescription | Yes | Detailed description of the job or reason for appointment. Include any visual details about the issue — damage, location, severity, photos described in text form. | |
| clientRequestId | Yes | REQUIRED. Stable UUID identifying this booking attempt. Generate ONCE at the moment you decide to book; reuse the SAME value on every retry of the same logical attempt so the server can dedup. A fresh value on retry will mint a duplicate calendar event. | |
| customerAddress | No | Customer's full service address. Required when the selected service has requiresCustomerAddress=true; omit or leave blank for services that do not need an address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses critical behaviors: the status field semantics ('pending', 'confirmed', 'completed'), the deduplication behavior of clientRequestId on retries, and the warning not to misreport 'pending' as 'confirmed'. It also details the address requirement condition, adding rich behavioral context.
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 front-loaded with the core purpose and then delivers dense, high-value guidance. Every sentence addresses an essential operational detail—status handling, feature gating, address requirements, and idempotency—without redundant filler.
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, the description compensates by explaining return fields (reference number and status). It covers prerequisites, conditional requirements, and error-prone customer messaging. For a complex mutation tool with 9 parameters, this description is remarkably complete.
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?
Even though schema coverage is 100%, the description substantially enriches parameter semantics. It explains that clientRequestId must be generated once and reused on retries to avoid duplicate calendar events, that dateTime must come from check_availability to respect bookingStartPolicy, and that customerAddress is conditionally required.
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 states the tool's function: 'Book an appointment with a local service business. Creates a booking record and adds the appointment to the business calendar.' This specific verb and resource combination distinguishes it from siblings like check_availability and send_inquiry.
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 provides explicit usage conditions: 'ONLY call this if the business has booking in its enabledFeatures array.' It also instructs to use a dateTime from check_availability and specifies when to provide customerAddress, giving clear when-to-use and prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check available appointment slots for a specific service at a local business on a given date. Returns time windows when the business is free and the service bookingStartPolicy permits the start. For services with maxParticipants > 1, partially booked starts remain available until capacity is full. ONLY call this if the business has 'booking' in its enabledFeatures array. If the business doesn't support booking, share their contact info from get_business_info instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. | |
| date | Yes | The date to check availability for (YYYY-MM-DD format, e.g. '2026-04-07') | |
| serviceName | Yes | The name of the service to check availability for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: returns available windows based on business free time and bookingStartPolicy, and partially booked slots remain available until full for services with maxParticipants > 1. No contradiction with 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?
Two concise sentences plus a conditional note, no wasted words. Purpose is front-loaded.
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 no output schema, the description explains the logic (returns time windows) but does not specify the return structure. However, for a read-only availability check, this is adequate.
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 coverage is 100%; description adds value by instructing to copy slug verbatim. The baseline of 3 is exceeded due to this helpful extra guidance.
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?
Clearly states 'Check available appointment slots for a specific service at a local business on a given date.' This directly describes the action, resource, and scope, differentiating it from siblings like book_appointment or find_next_available_appointments.
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 says 'ONLY call this if the business has 'booking' in its enabledFeatures array' and provides an alternative action (use get_business_info contact info) if not. Also explains behavior for services with maxParticipants > 1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the next available bookable appointment starts across matching local service businesses. Use this for requests like 'find me the next available boat trip' or 'who has the soonest dentist appointment'. The CALLER (you, the agent) extracts the structured search fields the same way as search_businesses, and passes the service or activity wording in serviceQuery. The response only includes businesses with direct booking support, a matching service, and at least one slot whose bookingStartPolicy and remainingCapacity allow booking.
| Name | Required | Description | Default |
|---|---|---|---|
| subCategory | Yes | Exact ProfessionalProfileSubCategory enum value derived from the user's request (e.g. 'EventPlanner', 'Dentist', 'Therapist'). Required. | |
| serviceQuery | Yes | Service or activity wording from the user, e.g. 'boat trip', 'therapy session', 'haircut'. | |
| startDate | Yes | First local date to search from (YYYY-MM-DD). Use today's date when the user asks for the next available option. | |
| locationText | No | Place name as the user said it. Pass null only for remote or nationwide service searches. | |
| countryCode | No | ISO-3166 alpha-2 country code (e.g. 'GR', 'US', 'GB'). Set when deducible. | |
| latitude | No | Latitude of the search location. Pass when the client has a map viewport or GPS position. | |
| longitude | No | Longitude of the search location. Pass alongside latitude. | |
| radiusKm | No | Search radius in kilometers, default 10. | |
| serviceMode | No | Hard filter on how the business delivers service. One of: 'in_person', 'remote', 'service_area', 'nationwide'. | |
| attributeFilters | No | Hard filter on vertical-specific attributes as a JSON object. Keys and values come from get_refinement_options. | |
| daysToSearch | No | Number of calendar days to scan starting at startDate. Defaults to 14 and is clamped between 1 and 31. | |
| resultLimit | No | Maximum number of available appointment matches to return. Defaults to 5 and is clamped between 1 and 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by specifying that the response includes only businesses with direct booking support, matching service, and available slots - going beyond what annotations provide.
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 well-structured and front-loaded with purpose, followed by examples, caller instructions, and response filtering. Each sentence earns its place without fluff, though it could be slightly more concise.
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 12 parameters, 3 required, and no output schema, the description adequately explains what the tool returns (businesses with direct booking, matching service, available slots). It also provides caller guidance. While it doesn't detail default parameters, the schema covers those.
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%, so baseline is 3. The description adds value by explaining that the agent extracts structured search fields similarly to search_businesses and passes wording in serviceQuery, providing meaningful context beyond the schema.
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 states the tool finds the next available bookable appointments across local service businesses. It provides specific examples ('find me the next available boat trip', 'who has the soonest dentist appointment') and explains the response criteria, distinguishing it from general business search.
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 explicitly tells when to use the tool ('use for requests like...') and how the agent should extract search fields. While it doesn't explicitly state when not to use it or mention alternatives, it provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get business information including name, type, service area, contact details, working hours, supported languages, enabled features, and a profile image (logo or personal photo) when the owner has uploaded one. Use 'attributeDetails' (natural-language sentences about the business's offerings, approach, and specialties) to reason about fit for the user. The 'cardChips' and 'cardChipGroups' fields are UI-only display data — ignore them. The response echoes the exact slug; reuse it verbatim in later tool calls. Always available for any business.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses (e.g. 'nikos-plumbing-a3f2'). Copy it verbatim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and openWorld annotations, the description adds valuable behavioral details: it notes that profile images are only present if uploaded, identifies cardChips/cardChipGroups as UI-only and instructs to ignore them, and mentions that the slug is echoed for reuse. These disclosures go well beyond the structured annotations and greatly aid the agent's decision-making.
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 a compact paragraph with each sentence conveying essential guidance: what fields are returned, how to use attributeDetails, which fields to ignore, and the slug echo behavior. No superfluous content; the structure is straightforward and front-loaded.
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 single parameter and no output schema, the description thoroughly explains the return contents and gives actionable guidance on using attributeDetails and ignoring UI fields. It is complete for the tool's purpose, with no additional clarification needed.
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 sole parameter 'slug' is fully documented in the schema with format and source instructions ('returned by search_businesses... copy it verbatim'). The description reinforces the reuse instruction but adds no new semantic meaning beyond the schema, so a baseline score of 3 is appropriate given the 100% schema coverage.
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 states the tool's function: retrieving business information, and enumerates the specific fields returned (name, type, service area, etc.). It distinguishes this from sibling tools by focusing on a general business profile rather than specific aspects like services or pricing.
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?
It provides context that this tool is always available and that the slug should be sourced from search_businesses and reused verbatim. It also instructs the agent to use attributeDetails for reasoning about fit. However, it does not explicitly contrast with sibling tools like get_services or get_pricing, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a price quote for a specific service from a local business. Takes into account emergency requests, weekend rates, and other pricing rules. Always available for any business.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. | |
| serviceName | Yes | The name of the service to get pricing for | |
| isEmergency | No | Whether this is an emergency/urgent request | |
| requestedDate | No | The requested date (YYYY-MM-DD), used to determine weekend rates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context such as 'Takes into account emergency requests, weekend rates, and other pricing rules' and 'Always available for any business,' which goes beyond the annotation hints and clarifies the tool's behavior regarding special pricing conditions.
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 front-load the core purpose, with no filler. The second sentence adds valuable context about availability and pricing rules without redundancy.
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 description adequately covers the tool's purpose and key behavioral nuances, and the schema handles all parameter details. It does not describe the return format, but given the simplicity of the tool and absence of an output schema, this is a minor gap that does not impair selection or invocation.
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 coverage is 100%, so baseline is 3. The description adds meaning by explicitly mentioning 'emergency requests' and 'weekend rates,' which maps to the isEmergency and requestedDate parameters, helping the agent understand how these parameters affect pricing beyond their schema descriptions.
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 states the tool's function: 'Get a price quote for a specific service from a local business.' This is a specific verb+resource combination that distinguishes it from siblings like get_services (listing services) or book_appointment.
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 usage context by mentioning emergency requests and weekend rates, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The phrase 'Always available for any business' offers some guidance but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the refinement dimensions (specializations, practice areas, service types, service modes, etc.) available for a specific subcategory. Call this BEFORE search_businesses when the user's request is broad (e.g. 'therapist in Greece', 'lawyer in London') so you can politely ask the user whether to narrow by any of these dimensions — and always offer them the option to see all results without filtering. Returns the attributes defined for the vertical with their possible option values, plus the universal serviceMode options. If refinementAvailable is false, skip refinement and go directly to search_businesses.
| Name | Required | Description | Default |
|---|---|---|---|
| subCategory | Yes | The exact subcategory enum the user is asking about (e.g. 'Therapist', 'Plumber', 'Dentist'). Pick the most specific value from ProfessionalProfileSubCategory based on the user's words. Use 'None' only when the user's request truly does not name a profession. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it returns 'attributes defined for the vertical with their possible option values, plus the universal serviceMode options' and explains the refinementAvailable flag behavior. This goes beyond the annotations to describe the output and conditional flow.
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 plus a conditional note, all front-loaded with the main purpose. No extraneous information; every sentence adds value by explaining usage, output, and integration with search_businesses.
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 tool has one parameter and no output schema, the description is complete: it explains what is returned (attributes, option values, serviceMode options) and the conditional refinementAvailable flag. Integration with sibling tools is clearly specified.
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% for the single parameter subCategory, which has a detailed description in the schema. The description does not add additional parameter semantics beyond what the schema provides, so a baseline of 3 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 explicitly states 'List the refinement dimensions... available for a specific subcategory' and differentiates from sibling tools by specifying it should be called BEFORE search_businesses for broad queries. The verb 'List' is specific to retrieval, and the resource is clearly defined.
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?
Provides explicit guidance: 'Call this BEFORE search_businesses when the user's request is broad... so you can politely ask the user whether to narrow by any of these dimensions' and 'If refinementAvailable is false, skip refinement and go directly to search_businesses.' This covers when to use, alternatives, and conditional behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the service catalog for a local service business, including service names, descriptions, estimated durations, price ranges, max participants, booking start policy, and whether the customer's address is required to book. Always available for any business.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds value by listing the exact return fields (price ranges, booking start policy, address requirement) and the 'always available' guarantee, which provides behavioral context beyond the annotations. It does not disclose edge cases like invalid slugs, but that is covered by the schema's 'exact URL slug' instruction.
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, information-dense sentence that front-loads the primary action ('Get the service catalog') and lists the key return elements. Every word adds value, and there is no redundancy or filler.
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 read-only tool with one fully-documented parameter, no output schema, and strong annotations, the description sufficiently covers the return content and availability. It explains what the tool returns and confirms it works for any business, making the tool fully understandable for an agent.
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% for the single 'slug' parameter, with clear guidance to copy it verbatim from search_businesses or get_business_info. The tool description itself adds no additional parameter semantics, so the 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 clearly states 'Get the service catalog for a local service business' and enumerates specific content (service names, durations, price ranges, etc.), which strongly distinguishes it from sibling tools like get_pricing (pricing-only) or get_business_info (business details). The verb+resource+scope pattern is clear and specific.
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 provides clear context with 'Always available for any business' implying no prerequisites or restrictions. However, it does not explicitly mention when to use it versus alternatives (e.g., 'use this instead of get_pricing when you need the full service catalog'), so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available local service businesses by structured fields. The CALLER (you, the agent) is responsible for extracting subCategory, locationText, and countryCode from the user's request — pick the most specific subCategory enum, pass the user's place wording in locationText, and infer countryCode when deducible. The server handles SQL filtering, geocoding, ranking, and bucketing. IMPORTANT: If the user's request is broad (e.g. 'therapist in Greece', 'lawyer in London') and they haven't named a specific specialization or service mode, call get_refinement_options FIRST with the subCategory, ask the user what to narrow by, then call this tool with the answer in attributeFilters and/or serviceMode. Skip that step when the user already named specifics or explicitly asked to see everything. Each result includes an 'enabledFeatures' array indicating what the business supports: 'info' (always on), 'inquiry' (can receive SMS inquiries), 'email_inquiry' (can receive email inquiries), 'booking' (can be booked directly). Use 'attributeDetails' (natural-language sentences about each business's offerings, approach, and specialties) to reason about fit for the user. The 'cardChips', 'cardChipGroups', and 'matchedFilterValues' fields are UI-only display data — ignore them. Each result also includes the exact slug to reuse verbatim in later tool calls. Pass latitude/longitude only when the client has an explicit map viewport or GPS position that should override the coordinates geocoded from locationText.
| Name | Required | Description | Default |
|---|---|---|---|
| subCategory | Yes | Exact ProfessionalProfileSubCategory enum value derived from the user's request (e.g. 'Therapist', 'Plumber', 'Dentist'). Required. Use 'None' only if the user truly hasn't named a profession — in that case the server refuses with a clarification response, and you should ask the user instead of guessing. | |
| locationText | No | Place name as the user said it, in their language. Examples: 'Athens', 'Greece', 'Πεκίνο', 'New York City'. Pass null when the user did not name a location. | |
| countryCode | No | ISO-3166 alpha-2 country code (e.g. 'GR', 'US', 'GB'). Set when deducible from locationText or context, even if locationText is just a city — the server uses it to short-circuit geocoding for country-scope queries. | |
| latitude | No | Latitude of the search location. Pass when the client has a map viewport or GPS position that should override coordinates geocoded from locationText. | |
| longitude | No | Longitude of the search location. Pass alongside latitude. | |
| radiusKm | No | Search radius in kilometers, default 10. | |
| serviceMode | No | Hard filter on how the business delivers service. One of: 'in_person', 'remote', 'service_area', 'nationwide'. Only profiles matching the mode are returned. Leave null when the user has no preference. | |
| attributeFilters | No | Hard filter on vertical-specific attributes as a JSON object. Keys and option values come from get_refinement_options. Example: '{"specializations":["trauma_ptsd"],"approaches":["emdr"]}'. Multiple values within a key are ALL required (AND). Multiple keys are ALL required (AND). Leave null when the user has no preference. | |
| resultLimit | No | Maximum number of businesses to return. Defaults to 5 and is clamped between 1 and 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable context: it explains that the server handles SQL filtering, geocoding, ranking, and bucketing, and details result fields (enabledFeatures, attributeDetails, etc.) and fields to ignore (cardChips, etc.). This goes beyond annotations to fully inform the agent about behavior.
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 well-structured, starting with the core purpose, then parameter instructions, an important note about refinement flow, and result field explanations. While informative, it is somewhat lengthy and could be slightly more concise without losing clarity.
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 tool has 9 parameters, no output schema, and annotations providing readOnlyHint and openWorldHint, the description is highly complete. It covers how to use the tool in conjunction with get_refinement_options, what to extract and ignore from results, and parameter extraction logic, fully addressing the tool's complexity.
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 coverage is 100% with descriptions for all parameters, but the description enriches semantics beyond the schema. For subCategory, it advises picking the most specific enum and using 'None' only if necessary. For locationText, it says to pass the user's wording. For lat/lng, it specifies conditions for overriding. These additions provide practical guidance.
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 states the tool's purpose: 'Search for available local service businesses by structured fields.' It uses a specific verb ('search') and resource ('local service businesses'), and distinguishes itself from sibling tools like book_appointment and get_refinement_options by focusing on the search function.
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 provides explicit usage guidelines, including when to first call get_refinement_options for broad requests and when to skip that step. It also instructs the caller on parameter extraction (subCategory, locationText, countryCode) and when to pass lat/lng coordinates, offering clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a general inquiry to a local service business. Use this when the customer has a question, needs a custom quote, or wants to describe an issue that doesn't fit a specific bookable service. The business owner will be notified immediately via every enabled inquiry channel and will contact the customer directly. ONLY call this if the business has 'inquiry' or 'email_inquiry' in its enabledFeatures array.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. | |
| customerName | Yes | Full name of the person making the inquiry | |
| customerPhone | Yes | Customer phone number | |
| customerEmail | Yes | Customer email address | |
| message | Yes | Detailed description of the inquiry, question, or issue. Include any visual details about damage, location, severity, and urgency. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the business owner will be notified immediately via every enabled inquiry channel, which adds behavioral context beyond annotations. Annotations already indicate destructiveness and non-idempotence, but the description explains the notification side effect. No contradictions.
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 highly concise with two sentences plus an imperative condition. Every sentence adds value, and the key condition is front-loaded for quick parsing.
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 description explains that the business owner will contact the customer directly, completing the mental model for a submission tool without an output schema. It covers what happens after invocation, which is sufficient for this tool's simplicity.
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?
All 5 parameters are described in the schema with 100% coverage. The description adds minor guidance (e.g., slug copied verbatim, message include details), but does not significantly augment schema descriptions. Baseline 3 for high coverage.
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 defines the tool as sending a general inquiry to a local service business, specifying use cases like questions, custom quotes, or non-bookable issues. It effectively distinguishes from siblings like book_appointment by targeting scenarios that don't fit a specific service.
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 explicitly states when to use (customer has non-bookable inquiry) and includes a conditional rule about the business's enabledFeatures. However, it does not contrast with specific siblings like check_availability or find_next_available_appointments, which could further clarify appropriate usage.
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.6book_appointmentcheck_availabilityfind_next_available_appointmentsget_business_infoget_pricingget_refinement_optionsget_servicessearch_businessessend_inquiryScored across 9 tools
Each tool targets a distinct action: searching, getting info, checking availability, booking, sending inquiry, etc. Even the two availability tools differ in scope (specific vs. cross-business next available). No ambiguity.
All tools follow a consistent verb_noun pattern in snake_case, e.g., book_appointment, check_availability, get_business_info. No mixing of conventions.
9 tools is well-scoped for a local service discovery and booking platform. Each tool serves a clear purpose without unnecessary duplication or bloat.
The tool set covers core workflows: search, info, pricing, availability, booking, inquiry. Missing cancellation or booking management, but the inquiry tool can handle custom requests. Minor gap but not critical.
MCP layer for local businesses: discover, query, book, and transact with verified SMB AI agents.
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Live Google Maps business search, review, and photo data for AI agents over MCP.
