qasper
Server Details
Discover and book businesses via AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- QasperAI/mcp-server
- GitHub Stars
- 0
- Server Listing
- @qasperai/mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: search, get info, pricing, availability, booking, inquiry, and agent chat. Even the two availability tools (check_availability vs find_next_available_appointments) target different granularities, preventing confusion.
All tool names follow a consistent 'verb_noun' snake_case pattern (e.g., book_appointment, get_business_info, search_businesses), making the set predictable and easy to navigate.
10 tools is well-scoped for a local business discovery and booking server. Each tool serves a necessary step in the workflow without redundancy or bloat.
The tool surface covers the full discovery-to-booking pipeline: search, details, pricing, availability, booking, inquiry, and agent interaction. Minor gaps exist in post-booking management (e.g., no cancel/update appointment), but the core use case is well-served.
Available Tools
10 toolsask_business_agentADestructiveInspect
Ask one specific Qasper business agent through the same chat path as that business's public agent page. Use this only after selecting a business and copying its exact slug from search_businesses or get_business_info. The business agent can use its configured business tools for services, pricing, availability, bookings, and inquiries when appropriate.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact URL slug returned by search_businesses or get_business_info. Copy it verbatim. | |
| question | Yes | The customer's direct question or request for this specific business agent. | |
| conversationId | No | Optional existing Qasper business-agent conversation id for audit grouping. Leave null for a new conversation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by stating that the business agent can use its configured business tools for services, pricing, availability, bookings, and inquiries, which is valuable. However, it does not explicitly mention the side effects implied by the destructiveHint annotation (e.g., starting a conversation), but the bar is lowered since annotations exist.
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 concise with two sentences, no wasted words. It front-loads the main action and follows with the usage guideline, making it easy to scan.
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 simple nature (asking a question to an agent), the description covers the prerequisites and capabilities adequately. There is no output schema, but the expected return (agent's response) is implied. For this complexity level, it is sufficiently 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?
Schema coverage is 100%, baseline 3. The description adds meaning by specifying that the slug must be the exact copy from search results and that the question is the customer's direct request. It also adds context for the conversationId parameter as optional and for audit grouping, going 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 verb 'Ask' and the resource 'one specific Qasper business agent', and it distinguishes this tool from sibling tools by specifying it uses the same chat path as the business's public agent page, which sets it apart from direct action tools like book_appointment or get_services.
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 instructs to use the tool only after selecting a business and copying its exact slug from search_businesses or get_business_info, providing clear context. However, it does not explicitly state when not to use this tool versus alternatives, but the precondition is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_appointmentADestructiveInspect
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. | |
| dateTime | Yes | Appointment start date and time in ISO 8601 format (e.g. '2026-04-07T14:00:00+03:00') | |
| serviceName | Yes | The name of the service to book | |
| customerName | Yes | Full name of the customer | |
| customerEmail | Yes | Customer email address | |
| customerPhone | Yes | Customer phone number | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description elaborates: it 'creates a booking record' and explains the three possible statuses. It warns about dedup via clientRequestId and the requiresCustomerAddress condition, adding context beyond annotations without 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 a single paragraph that is front-loaded and covers all essential points without excessive verbosity. Slight room for structuring conditions more clearly, but overall efficient.
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?
Covers all aspects: when to call, parameter details, behavior of statuses, idempotency, and prerequisite conditions. No output schema, but the description adequately describes return values (reference number and status).
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%, and the description adds significant value: explains clientRequestId for dedup, customerAddress condition, and dateTime referencing check_availability. Each parameter's usage is clarified 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: 'Book an appointment with a local service business.' It specifies that it creates a booking record and adds to the calendar, distinguishing it from sibling tools 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?
Provides explicit guidance: 'ONLY call this if the business has 'booking' in its enabledFeatures array.' It instructs to use a dateTime from check_availability and explains when to ask for customerAddress. Also specifies how to handle status fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_availabilityARead-onlyInspect
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, provider-returned 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 |
|---|---|---|---|
| date | Yes | The date to check availability for (YYYY-MM-DD format, e.g. '2026-04-07') | |
| 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 check availability for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds context about capacity and bookingStartPolicy, which goes beyond the annotations without contradicting them. However, it doesn't cover all potential edge cases.
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?
Three sentences front-load the purpose, then provide behavioral nuance, then a precise usage condition. No wasted words.
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 what is returned (time windows) and the logic. It is complete enough but could mention the response format or pagination if applicable.
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 already has 100% description coverage for all three parameters. The description adds extra guidance like 'Copy it verbatim' for slug and an example format for date, providing marginal added value.
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 verb 'Check' and the resource 'available appointment slots for a specific service at a local business on a given date'. It distinguishes itself from siblings like 'book_appointment' and 'find_next_available_appointments' by specifying the scope.
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 when to call ('ONLY call this if the business has 'booking' in its enabledFeatures array') and what to do instead ('share their contact info from get_business_info instead'). 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_next_available_appointmentsARead-onlyInspect
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 |
|---|---|---|---|
| latitude | No | Latitude of the search location. Pass when the client has a map viewport or GPS position. | |
| radiusKm | No | Search radius in kilometers, default 10. | |
| longitude | No | Longitude of the search location. Pass alongside latitude. | |
| startDate | Yes | First local date to search from (YYYY-MM-DD). Use today's date when the user asks for the next available option. | |
| countryCode | No | ISO-3166 alpha-2 country code (e.g. 'GR', 'US', 'GB'). Set when deducible. | |
| resultLimit | No | Maximum number of available appointment matches to return. Defaults to 5 and is clamped between 1 and 20. | |
| serviceMode | No | Hard filter on how the business delivers service. One of: 'in_person', 'remote', 'service_area', 'nationwide'. | |
| subCategory | Yes | Exact ProfessionalProfileSubCategory enum value derived from the user's request (e.g. 'EventPlanner', 'Dentist', 'Therapist'). Required. | |
| daysToSearch | No | Number of calendar days to scan starting at startDate. Defaults to 14 and is clamped between 1 and 31. | |
| locationText | No | Place name as the user said it. Pass null only for remote or nationwide service searches. | |
| serviceQuery | Yes | Service or activity wording from the user, e.g. 'boat trip', 'therapy session', 'haircut'. | |
| attributeFilters | No | Hard filter on vertical-specific attributes as a JSON object. Keys and values come from get_refinement_options. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true and openWorldHint: true. The description adds behavioral detail: only businesses with direct booking support, matching service, and slots respecting bookingStartPolicy and remainingCapacity are returned. 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?
The description is reasonably concise, front-loading purpose and usage. Two paragraphs without superfluous text, though slightly verbose in explaining the search fields extraction.
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 and no output schema, the description covers purpose and basic behavior but omits details on output format, error handling, or edge cases (e.g., no available appointments). Adequate but not fully comprehensive.
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 the baseline is 3. The description mentions serviceQuery and alludes to structured search fields, but does not add significant meaning beyond the schema's parameter 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 finds next available bookable appointments across matching local service businesses, with examples like 'find me the next available boat trip'. It distinguishes from sibling tools by specifying it only returns businesses with direct booking support, matching service, and bookable slots.
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 scenarios (e.g., 'find me the next available boat trip') and instructs the agent to extract structured search fields similarly to search_businesses. However, it lacks explicit when-not-to-use guidance or direct comparison with alternatives like check_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_business_infoARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that the response echoes the exact slug for reuse, that 'cardChips' and 'cardChipGroups' are UI-only and should be ignored, and that a profile image is returned if uploaded. No contradictions 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?
The description is fairly concise, listing key fields and providing important caveats (ignore UI fields, reuse slug). It could be slightly tighter but is well-structured and front-loaded with the main purpose.
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 covers the main points: returned fields, how to use the slug, which fields are meaningful, and that it's always available. It is sufficiently complete for a read-only business info lookup tool.
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 already provides a clear description of the 'slug' parameter, stating it should be copied verbatim from search_businesses. The description reinforces this but adds no new information beyond the schema. With 100% schema coverage, baseline 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 that the tool retrieves business information including name, type, service area, contact details, working hours, supported languages, enabled features, and a profile image. It distinguishes from siblings by focusing on comprehensive business data retrieval, not search or service listing.
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 notes 'Always available for any business' and advises using 'attributeDetails' for reasoning about fit, but does not explicitly state when to use this tool versus alternatives like search_businesses or get_services. Usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingARead-onlyInspect
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. | |
| isEmergency | No | Whether this is an emergency/urgent request | |
| serviceName | Yes | The name of the service to get pricing for | |
| requestedDate | No | The requested date (YYYY-MM-DD), used to determine weekend rates |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds context about pricing rules (emergency, weekend) and availability, which is useful. However, it does not clarify what 'other pricing rules' entails or any limitations.
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, front-loading the purpose. Every word is functional, with no redundancy or unnecessary detail.
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 should explain what the agent receives (e.g., price quote format). It mentions inputs but not output structure, leaving uncertainty about the return value.
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 parameters have descriptions in the schema with 100% coverage. The description's mention of emergency and weekend rates slightly reinforces the purpose of isEmergency and requestedDate, but adds no new semantic detail 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 gets a price quote for a specific service, mentioning key factors like emergency and weekend rates. This differentiates it from sibling tools like check_availability 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 does not explicitly guide when to use this tool versus alternatives, nor does it mention contraindications. It states 'Always available for any business' but provides no exclusion criteria or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_refinement_optionsARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by describing the return structure (attributes with option values plus universal serviceMode options) and the refinementAvailable flag. No contradictions 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?
The description is concise and well-structured: first sentence states purpose, second sentence gives usage guidelines, third describes returns, fourth provides conditional logic. Every sentence is necessary and adds value.
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 (single parameter, no output schema), the description covers purpose, usage, response content, and conditional logic. It provides examples of broad requests. Could be enhanced with error handling details, but current level is adequate for effective use.
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%. The description adds context beyond the schema's description by emphasizing to use the most specific subcategory value and that 'None' is only when no profession is named. This helps the agent choose the correct parameter value.
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 it lists refinement dimensions for a specific subcategory, with specific verb 'List'. It distinguishes from sibling tool 'search_businesses' by instructing to call this before search_businesses when the user's request is broad.
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 call (before search_businesses for broad requests), how to use the response (ask user to narrow), and provides a conditional (skip if refinementAvailable is false). Also mentions offering the option to see all results without filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_servicesARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it is always available, returns a comprehensive set of fields (names, durations, pricing, etc.), and involves no destructive actions. No contradictions 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?
The description is a single, well-front-loaded sentence that efficiently communicates the tool's purpose and output. It could be more structured (e.g., bullet points for the listed fields), but it avoids redundancy and unnecessary words.
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 low-complexity tool with one parameter and no output schema, the description covers the return content and availability. It lacks error scenarios or output format details, but the annotations and schema cover safety and parameter usage, making it reasonably 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?
The input schema has 100% coverage with a detailed description for the single parameter (slug). The tool description does not add additional parameter information beyond what the schema provides, meeting the baseline expectation.
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 specifies the verb 'Get' and the resource 'service catalog', listing the exact fields returned. It distinguishes from sibling tools like get_business_info (which returns business details) and get_pricing (which focuses on pricing), making the tool's unique purpose evident.
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 states 'Always available for any business,' providing clear usage context and implying no prerequisites. However, it doesn't explicitly contrast with alternatives or specify when not to use it, which would make it stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_businessesARead-onlyInspect
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 general inquiries), 'email_inquiry' (can receive email inquiries), 'booking' (can be booked directly). Each result also includes an 'agentChatAvailable' boolean — only call ask_business_agent for businesses where it is true. 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 |
|---|---|---|---|
| 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. | |
| radiusKm | No | Search radius in kilometers, default 10. | |
| longitude | No | Longitude of the search location. Pass alongside latitude. | |
| 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. | |
| resultLimit | No | Maximum number of businesses to return. Defaults to 5 and is clamped between 1 and 20. | |
| 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. | |
| 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. | |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds rich behavioral context: the server handles SQL filtering, geocoding, ranking, and bucketing; subCategory='None' triggers a server-side clarification; attributeFilters use AND logic; resultLimit is clamped 1-20; and each result includes enabledFeatures, agentChatAvailable, attributeDetails, and slug. This goes well 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 thorough and well-structured: purpose first, then flow instructions, then behavioral notes, then field-specific guidance. It is not extremely concise but every sentence adds useful information. Given the tool's complexity (9 parameters, many usage nuances), the length is justified.
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 covers all essential aspects: what the tool does, what each result field means (enabledFeatures, agentChatAvailable, attributeDetails, slug), which fields to ignore, how to use locationText vs lat/lng, and the interplay with siblings. No output schema exists, but the description compensates by detailing result contents. The tool is fully specified for an agent to use 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?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining agent responsibilities for extracting subCategory, locationText, and countryCode, giving examples for locationText, explaining attributeFilters as a JSON object with AND logic, clarifying subCategory='None' behavior, noting radiusKm default and resultLimit clamping. This enriches each parameter beyond the schema alone.
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 starts with a clear verb+resource: 'Search for available local service businesses by structured fields.' It distinguishes itself from siblings by explicitly mentioning when to use get_refinement_options first or skip it, and how to use ask_business_agent afterward. The purpose is unmistakable.
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 when-to-use and when-not-to-use guidance: call get_refinement_options first for broad requests, skip if specifics are given. It instructs the agent on extracting subCategory, locationText, and countryCode, and when to pass latitude/longitude. It also tells which fields to ignore and how to use agentChatAvailable to decide on follow-up calls. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_inquiryADestructiveInspect
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. | |
| message | Yes | Detailed description of the inquiry, question, or issue. Include any visual details about damage, location, severity, and urgency. | |
| customerName | Yes | Full name of the person making the inquiry | |
| customerEmail | Yes | Customer email address | |
| customerPhone | Yes | Customer phone number | |
| clientRequestId | Yes | Required stable UUID for this inquiry attempt. Generate once and reuse on retries of the same logical attempt. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (destructiveHint=true, openWorldHint=true) indicate mutation. Description adds that the business owner will be notified immediately via all enabled channels. No contradiction with annotations, and it provides useful behavioral context beyond what annotations convey.
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?
Extremely compact: three sentences total, front-loaded with purpose. Every sentence adds essential information. No filler or redundant text.
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 6 required params, no output schema, and destructive nature, description covers when to use, parameter details, and notification outcome. Missing clarification on response format (e.g., success/failure), but openWorldHint may downplay need. Nevertheless, it is mostly 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?
Schema coverage is 100%, but description adds value: for 'message' it advises including visual details (damage, location, severity, urgency); for 'clientRequestId' it explains generation and reuse; for 'slug' it says copy verbatim. This provides guidance 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 'Send a general inquiry to a local service business' and specifies use cases: questions, custom quotes, issues not fitting bookable services. It distinguishes from bookable services, ensuring the agent understands when to invoke this tool.
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 condition: 'ONLY call this if the business has inquiry or email_inquiry in its enabledFeatures array.' It also contrasts with bookable services but does not compare with siblings like ask_business_agent, which may handle inquiries differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.