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.5/5 across 10 of 10 tools scored. Lowest: 3.9/5.
Each tool has a distinct purpose: search, info retrieval, pricing, services, availability checks (per-service or cross-business), booking, inquiries, and agent chat. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores (e.g., search_businesses, book_appointment, get_services). The naming conventions are uniform and predictable.
With 10 tools, the server covers the full spectrum of local business discovery and booking without being overly large or sparse. Each tool serves a necessary step in the user flow.
The tool set covers discovery, info, availability, booking, and communication. Minor gaps exist: no tools for updating or canceling appointments. However, the business agent tool may handle these, and the core workflow is complete.
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 ONLY when the user explicitly asks for availability, booking, the soonest appointment, or a specific appointment time. Examples: 'book me a dentist', 'who has availability tomorrow?', 'find the soonest groomer appointment', 'get me a dermatologist next Wednesday'. Do NOT use this for generic discovery requests like 'find me a dentist in Paris' or 'show me pet groomers near me'; use search_businesses for discovery. 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. An empty result does NOT mean no matching businesses exist; it only means no directly bookable matching slots were indexed. If this returns no results, call search_businesses before responding to the user.
| 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 critical behavioral context: results include only directly bookable slots; an empty result doesn't mean no businesses exist; fallback to search_businesses. 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 well-structured, starting with purpose, then usage guidelines, then behavioral notes. Each sentence adds value. While slightly long, it is appropriate for the tool's complexity and avoids 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?
Given the tool's complexity (12 params, no output schema), the description covers purpose, usage, behavior, and fallback instructions. It lacks explicit return format details, but the behavioral context compensates. Mostly complete 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 coverage is 100%, so the schema already documents all parameters. The description adds guidance on extracting fields and using serviceQuery, but does not provide significant additional semantic depth beyond the schema. 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 clearly states the tool's purpose: 'Find the next available bookable appointment starts across matching local service businesses.' It uses a specific verb and resource, and provides examples that distinguish it from sibling tools like search_businesses and 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 explicitly specifies when to use the tool (user asks for availability, booking, soonest appointment, specific time) and when not to use it (generic discovery). It gives examples and directs to use search_businesses as an alternative.
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?
The description adds context beyond the annotations: it states what the tool returns (attributes with possible option values, universal serviceMode options) and describes the behavior when refinementAvailable is false. There is no contradiction with the readOnlyHint and openWorldHint 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 and front-loaded with purpose and usage. However, it could be slightly more concise by omitting some redundant phrasing (e.g., 'politely ask the user whether to narrow by any of these dimensions — and always offer them the option to see all results without filtering' is slightly verbose). Still, it is efficient overall.
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, no output schema, and is relatively simple, the description fully covers what the tool does, what it returns, and how to use it in the broader workflow.
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 schema has 100% description coverage. The description provides additional guidance on how to select the subCategory parameter value (e.g., 'Pick the most specific value from ProfessionalProfileSubCategory', 'Use 'None' only when no profession'). This adds meaning beyond the enum listing.
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 lists refinement dimensions for a specific subcategory, using a specific verb and resource. It distinguishes itself from sibling tools like search_businesses by indicating when it should be used (before search_businesses for broad requests).
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 says when to call this tool (before search_businesses for broad requests), how to respond to the user (politely ask whether to narrow by dimensions, offer option to see all without filtering), and includes a conditional (if refinementAvailable is false, skip refinement). This provides comprehensive usage guidance.
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 local service businesses by structured fields. Use this as the FIRST discovery tool for requests such as 'find me a dentist in Paris', 'show me groomers near me', 'recommend a dermatologist', or 'I need a plumber'. This returns businesses even when they do not support direct booking. Do NOT skip this tool just because the user mentions a professional category; availability search is only for explicit booking, availability, soonest-slot, or specific appointment-time requests. 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). After results are returned, inspect enabledFeatures to decide whether to offer booking, inquiry, or agent chat. 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 indicate readOnlyHint=true and openWorldHint=true, and the description adds behavioral context: returns businesses even without direct booking, explains enabledFeatures, agentChatAvailable, attributeDetails, slug, and what fields to ignore. 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 long but well-structured with clear sections and important notes highlighted. Slightly verbose at points (e.g., repeated emphasis), but every sentence 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 complexity (9 parameters, many enums, no output schema), the description is thorough. Covers parameter usage, result interpretation, edge cases (broad requests), and integration with sibling tools like get_refinement_options and ask_business_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 coverage is 100%, but the description adds significant semantic guidance: how to derive subCategory, locationText, countryCode, when to pass latitude/longitude, and the syntax for attributeFilters. This goes beyond the 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 purpose ('Search for local service businesses by structured fields') and provides examples of when to use it ('find me a dentist in Paris', 'show me groomers near me'). It also distinguishes it from siblings by noting it's the first discovery tool and contrasting with availability 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?
Explicitly specifies when to use (first discovery tool for requests like 'find me a dentist') and when not to ('availability search is only for explicit booking requests'). Provides a multi-step workflow with get_refinement_options for broad requests and clear instructions on when to skip refinement.
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.