Click on "Install 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?
Annotations mark destructiveHint=true, and the description adds critical behavioral details: return statuses (pending, confirmed, completed), idempotency via clientRequestId, and cautions about not misinterpreting status. It also explains booking respects bookingStartPolicy and maxParticipants, going beyond 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 well-structured with clear sections, but slightly verbose. It front-loads the purpose and returns, then adds usage notes. Could be tightened without losing information.
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 thoroughly covers return values and usage context. It includes prerequisites, conditional address requirement, idempotency guidance, and status interpretation rules. Completely addresses agent needs.
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?
Despite 100% schema coverage, the description adds significant value: instructs to copy slug verbatim, use dateTime from check_availability, generate clientRequestId once and reuse for dedup, and conditionally provide customerAddress. This far exceeds baseline expectations.
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 books an appointment with a local service business, creates a booking record, and adds to the calendar. It distinguishes itself from sibling tools like check_availability and get_business_info, which are query 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 provides explicit conditions for use: only call if the business has 'booking' in its enabledFeatures, and only after using check_availability for the dateTime. It also advises when to ask for address. However, it doesn't explicitly list when not to use it compared to other tools like send_inquiry, but context makes it clear.
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?
Annotations (readOnlyHint=true, openWorldHint=true) set a baseline. The description adds valuable context: slug echoing, instruction to ignore UI-only fields, and assurance of availability. No contradictions detected.
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 structured and mostly concise, but a few sentences (e.g., listing every data field) could be tightened. It is front-loaded with the main purpose and then provides usage tips.
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's simplicity (one parameter, no output schema) and the presence of annotations, the description covers all necessary details: what data is returned, how to use slug, and which fields to ignore. It is fully adequate for an AI 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%. The schema already explains the slug parameter well ('Copy it verbatim'), and the tool description reinforces this. The description adds no new semantic meaning 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's purpose: 'Get business information including name, type, service area, contact details, working hours, supported languages, enabled features, and a profile image.' It uses specific verbs ('get') and resources ('business information'), distinguishing it from sibling tools focused on booking, availability, 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?
The description advises using 'attributeDetails' to reason about fit and notes that the response echoes the slug for reuse. However, it does not explicitly state when not to use this tool or provide alternatives to other info-gathering tools, missing an opportunity to guide agent decision-making.
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 indicate readOnlyHint: true and openWorldHint: true, which align with the description's 'Get a price quote' (read-only). The description adds beyond annotations by specifying that the tool accounts for emergency requests and weekend rates, giving behavioral transparency about pricing rules.
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?
Description is two sentences: first sets the purpose, second adds key details. No extraneous words, front-loaded with the action. Every sentence earns its place.
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 pricing tool with 4 parameters and no output schema, the description covers essential context: purpose, special pricing rules, and general availability. It omits specifics on the return format, but given annotations and the tool's simplicity, this is acceptable. Slightly higher would require mentioning that pricing may vary or that the response includes a quote object.
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 all 4 parameters. The description adds significant value by instructing to copy the slug verbatim from search_businesses or get_business_info, and by contextualizing the isEmergency and requestedDate parameters with mentions of emergency requests and weekend rates. This helps the agent use parameters correctly.
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 'Get a price quote for a specific service from a local business.' The verb 'get' paired with resource 'price quote' is specific. It distinguishes from sibling tools like book_appointment, check_availability, etc., which focus on booking or availability, not 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?
Description provides context on when to use by mentioning 'takes into account emergency requests, weekend rates' and 'always available,' implying this tool handles special pricing scenarios. However, it does not explicitly state when NOT to use it or suggest alternatives, but the context is sufficient for most use cases.
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?
The description adds value beyond annotations by listing exactly what information is returned and stating it's always available. This aligns with readOnlyHint and openWorldHint, and there is no contradiction.
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 purpose and is informative. However, it is a single long sentence listing many fields, which could be slightly more concise. Still effective.
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 only one parameter and no output schema, the description adequately explains what is returned and that it's always available. It does not mention pagination or result limits, but for this type of tool it's sufficient.
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 'slug', which has detailed instructions to copy verbatim from search_businesses or get_business_info. The tool description does not add further parameter context, so baseline score 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 clearly states the tool retrieves the service catalog and lists specific fields (names, descriptions, durations, etc.). It uses the verb 'Get' and specifies the resource, distinguishing it from sibling tools like search_businesses or get_business_info.
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 says 'Always available for any business,' providing context for when to use it, but it does not mention when not to use it or provide alternatives. For example, it doesn't clarify that it's not for checking availability or booking.
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. Dates show when Glama detected each change.
v1.0.6book_appointmentcheck_availabilityfind_next_available_appointmentsget_business_infoget_pricingget_refinement_optionsget_servicessearch_businessessend_inquiryEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/QasperAI/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
