Find, compare, and book local service businesses: live availability, prices, reviews, booking.
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.
Average 4.1/5 across 13 of 13 tools scored.
All 13 tools have clearly distinct purposes, from searching and comparing businesses to booking, canceling, and checking availability. Even similar tools like check_availability and get_availability_now are differentiated by scope (specific service vs. urgent same-day).
All tools follow a consistent verb_noun pattern in snake_case, such as book_appointment, check_availability, and get_business_details. The naming is predictable and intuitive.
With 13 tools covering the full service booking workflow—from discovery to booking, cancellation, and waitlisting—the count is well-scoped. Each tool serves a necessary function without bloat.
The toolset covers the entire booking lifecycle: discovery (search, details, reviews, comparisons, prices, promotions), availability checking, booking, cancellation/rescheduling, waitlisting, and business-specific Q&A. There are no obvious gaps.
ask_business_questionAAnswer a specific question about one business, grounded in that business's own knowledge base (FAQs, policies, service descriptions) rather than model guesswork. Returns 'unknown' when unanswerable — never fabricates.
Returns: {answer, confidence: 'high'|'low'|'unknown', source: 'faq'|'policy'|'services'}
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | e.g. 'do they do walk-ins?', 'is parking available?', 'do they service tankless water heaters?' | |
| business_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by describing return structure and grounding sources (faq, policy, services). With readOnlyHint=true and openWorldHint=false already present, the description clarifies known-world behavior and honesty policy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences plus return format. No redundancy, all sentences earn their place. Purpose and behavior are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params, no output schema), the description covers purpose, behavior, return format, and usage guidelines. An agent can correctly invoke and interpret results.
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 at 50% (only question has description). The description adds an example for the question parameter but does not elaborate on business_id. Provides moderate semantic enrichment 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 'Answer' and resource 'a specific question about one business', distinguishing it from sibling tools like search_businesses and compare_businesses. It specifies grounding in the business's own knowledge base.
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 clear context: use for grounded answers, never fabricates, returns 'unknown' for unanswerable. Lacks explicit when-not-to-use or alternative tool names, but the single-business scope implicitly excludes multi-business tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_appointmentABook the appointment. ONLY call after the user has explicitly confirmed the business, service, price, and exact slot. Writes to the business's calendar and emails/texts the customer a confirmation.
Returns: {confirmation_id, status: 'confirmed' | 'pending_deposit',
payment_url (present when a deposit is required — user completes payment
on the hosted page), booking_page_url, cancellation_policy}
Errors: SLOT_TAKEN (re-run check_availability and offer alternatives),
DEPOSIT_REQUIRED, INVALID_CONTACT.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| slot_id | Yes | ID from check_availability | |
| service_id | Yes | ||
| business_id | Yes | ||
| customer_name | Yes | ||
| customer_email | Yes | ||
| customer_phone | Yes | E.164 preferred, e.g. +17325551234 | |
| idempotency_key | Yes | Client-generated UUID. Retries with the same key return the original booking instead of creating a duplicate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent write, no destruction. Description adds details: writes to calendar, emails/texts confirmation, returns specific fields, and lists error types (SLOT_TAKEN, DEPOSIT_REQUIRED, INVALID_CONTACT). 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?
Very concise: two short paragraphs. First sentence states purpose and usage constraint. Second covers returns and errors. No fluff, 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?
Covers when to call, what it does, return structure, error types. Missing explicit mention of notes parameter and customer fields' role, but implied by 'emails/texts the customer'. Adequate for a booking tool with 8 parameters.
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 38% (3/8 parameters described). Description adds general context about business, service, slot, but doesn't provide explicit parameter-level details for customer fields or notes. Partial compensation.
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?
Clear verb+resource: 'Book the appointment'. Distinguishes from siblings like check_availability, cancel_or_reschedule, join_waitlist by specifying writing to calendar and sending confirmation.
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?
Explicit precondition: 'ONLY call after the user has explicitly confirmed the business, service, price, and exact slot.' This tells the agent exactly when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cancel_or_rescheduleACancel or reschedule an existing booking. Enforces the business's cancellation window; returns REFUND_FORFEITED warning when a deposit is non-refundable so the assistant can warn the user BEFORE confirming.
Returns: {confirmation_id, status, refund_status, message}
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'cancel' | 'reschedule' | |
| new_slot_id | No | Required for reschedule; from check_availability | |
| customer_email | Yes | Must match the booking — acts as verification | |
| confirmation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and idempotentHint=true. The description adds value by explaining the refund forfeited warning and return fields. It does not contradict annotations, though additional details on idempotency or actual mutation effect could improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a return format line. No filler, front-loaded with purpose, and every sentence adds necessary context. Highly 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?
Given 4 parameters and no output schema, the description covers the core behavior, special conditions (refund warning), and return fields. Lacks explanation of idempotency or reschedule mechanics (e.g., does it modify or recreate?), but sufficient for basic usage.
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 covers 75% of parameters with descriptions. The description reinforces action options and new_slot_id usage ('from check_availability'), but adds little beyond schema for customer_email and confirmation_id. Adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Cancel or reschedule an existing booking.' This is a specific verb-resource pair that distinguishes it from sibling tools like book_appointment (create) or check_availability (read). No sibling tool does exactly this.
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 mentions the cancellation window enforcement and refund warning, advising the assistant to warn the user 'BEFORE confirming.' This provides clear when-to-use guidance, though it does not explicitly state when not to use (e.g., if the booking is already past the window).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_availabilityAList open, bookable time slots for one service from the business's live calendar. Slots are held nothing — they can be taken by others until book_appointment succeeds, so book promptly after user confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | Last day to check, max 14 days after date_from | |
| date_from | Yes | First day to check (business-local) | |
| service_id | Yes | ID from get_business_details | |
| business_id | Yes | ||
| preferred_time_of_day | No | Optional: 'morning' | 'afternoon' | 'evening' |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond the readOnlyHint annotation: it states that slots are not held and can be taken by others, which is essential for the agent to understand the non-reservation nature. This does not contradict the annotation; in fact, it complements it by explaining the behavior during the read operation.
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 that front-load the primary purpose and then provide a key behavioral note. Every sentence adds value; there is no fluff.
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 presence of an output schema and the description's focus on core purpose and behavioral nuance, it is largely complete. It covers what the tool does, its single-service scope, and the urgency of booking. The lack of explicit return value details is acceptable since the output schema should cover that. However, it could hint at what the response contains (e.g., list of time slots).
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?
With 80% schema description coverage, the baseline is 3. The description does not add significant meaning to the parameters beyond the schema; it mentions 'one service' but doesn't elaborate on the parameters themselves. The schema already describes date_from, date_to, service_id, and preferred_time_of_day adequately.
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 open, bookable time slots for a single service from a live calendar. It uses a specific verb 'list' and specifies the resource 'time slots', distinguishing it from sibling tools like get_availability_now (immediate availability) or book_appointment (booking).
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 useful guidance: it notes that slots are not held and can be taken by others, advising to book promptly after user confirmation. This implies when to use (to find slots) and hints at the need to follow up with book_appointment. It does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_businessesASide-by-side comparison of 2-4 businesses the user is deciding between: prices for comparable services, ratings, soonest availability, policies, and a one-line 'best for' verdict per business.
Returns: {comparison_table: list[dict], best_for: dict[str, str]}
| Name | Required | Description | Default |
|---|---|---|---|
| criteria | No | Optional focus: 'price' | 'rating' | 'availability' | 'services' | |
| business_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by specifying the return format and business count constraint. However, it does not discuss failure cases, performance, or any special auth requirements beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and scope. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is missing, the description provides return format. It covers core functionality well but lacks details on error states (e.g., less than 2 valid IDs) or behavior with null criteria. Overall adequate for a read-only comparative 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?
Schema descriptions cover criteria partially; description adds '2-4 businesses' for business_ids (already in schema constraints) and lists comparison items (prices, ratings, etc.) which map to criteria but not explicitly. With 50% schema coverage, this adds moderate context but not full compensation for undocumented parameters.
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 performs side-by-side comparison of 2-4 businesses, listing specific items (prices, ratings, availability, policies) and a verdict. This distinguishes it from siblings like get_business_details or check_availability which focus on individual businesses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when a user is deciding between businesses, but does not explicitly mention when to avoid it or name alternative tools. The sibling list provides context but the description itself lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availability_nowAAnswer urgency: 'who can fit me in today?', 'emergency plumber available now'. Returns only businesses with a genuinely open slot inside the window, sorted by soonest slot. Ideal for same-day and emergency requests (HVAC, plumbing, urgent dental).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| location | Yes | ||
| within_hours | No | ||
| service_query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds specific behavioral context: returns only businesses with genuinely open slots, sorted by soonest slot, and implies a time window. This adds value beyond annotations, but does not cover all behavioral traits (e.g., pagination, response format).
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 extremely concise: two sentences that front-load the core purpose and use cases. Every word adds value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required) and an output schema exists, the description adequately covers the overall use case but lacks specifics on parameter semantics (location format, service_query usage). It is adequate for a simple tool but not fully 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 description coverage is 0%, so the description must compensate. It mentions 'window' (related to within_hours) and gives category examples (HVAC, plumbing, dental), but does not explain location format, service_query usage, or constraints. It adds some meaning but not enough to fully compensate for the missing 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 with specific verbs ('Answer urgency', 'Returns only businesses with a genuinely open slot'), gives concrete examples ('who can fit me in today?', 'emergency plumber'), and distinguishes from sibling tools like 'check_availability' by emphasizing time-critical, same-day 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 explicitly says 'Ideal for same-day and emergency requests (HVAC, plumbing, urgent dental)', providing clear context. It does not explicitly state when not to use or name alternatives, but the use cases imply that general or future availability queries should use other tools 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_detailsAGet a business's full profile: services with prices and durations, hours, booking and cancellation policies, review summary, photos, and hosted booking page URL. Call this before quoting prices to the user.
Returns: {business: BusinessSummary, services: list[ServiceItem],
hours: dict[str, str], policy: BookingPolicy, review_summary: str}
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | ID from search_businesses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. Description adds the return structure and scope, which is useful but doesn't disclose additional behavioral traits 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?
Two sentences plus a return type listing. Front-loaded with purpose, no extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and annotations present, the description covers the tool's purpose, usage, and return structure thoroughly. Sufficient for an agent to invoke 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%: the single parameter business_id already has a description ('ID from search_businesses'). The tool description adds no further meaning to the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a business's full profile' and lists specific contents (services, hours, policies, etc.). Distinguishes from siblings like get_reviews or compare_businesses by being comprehensive.
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 'Call this before quoting prices to the user.' Provides clear context for when to use it. No explicit when-not-to-use or alternatives, but the directive is strong and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_local_insightsAMarket-level answers: most-booked services in this area, typical price ranges, busiest days/times (book early), and top-rated businesses. Useful when the user asks broad questions like 'what do people usually get at a med spa' or 'when is the best time to book HVAC maintenance'.
Returns: {popular_services: list[{name, median_price_usd, share}],
busiest_days: list[str], booking_lead_time_days, top_rated: list[BusinessSummary]}
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| location | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only (readOnlyHint=true). The description adds behavioral context: it provides market-level aggregated data (not real-time availability), includes booking lead time and busy times, and returns a specific structure. No contradictions with annotations, and the description adds value beyond the structured fields.
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 short paragraphs with no extraneous content. It starts with the purpose, then gives usage examples, and ends with a clear return structure. Every sentence adds value. It is concise but not over-simplified.
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 read-only tool with 2 simple parameters and annotations present, the description covers purpose, usage context, and return format. It lacks details on error conditions or rate limits, but these are not critical for this tool. The output schema is not provided, but the description defines the return structure adequately.
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 tool has 2 required parameters (location, category) with no schema descriptions (0% coverage). The tool description does not explain the parameters, such as location format (e.g., city name, zip code) or that category must be one of the 20 enum values. Although the examples imply usage ('med spa' corresponds to 'med_spa'), the description fails to add explicit parameter guidance, which is necessary given the lack of 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 uses specific verbs ('most-booked services', 'typical price ranges', 'busiest days/times') and clearly states the resource: market-level answers. It provides concrete examples ('what do people usually get at a med spa') that distinguish it from sibling tools like get_business_details or search_businesses which focus on individual entities.
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 'Useful when the user asks broad questions' and gives two example queries. While it doesn't list when not to use this tool, the context and examples make it clear that this is for aggregated market insights, not specific business queries. Sibling tools like ask_business_question imply alternatives for narrower questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_estimatesAAnswer 'how much does X cost near me' with real local prices — not national averages. Returns low/median/high from actual listed prices of businesses in the area, plus the 3 best-value businesses with links.
Returns: {service, location, price_low_usd, price_median_usd,
price_high_usd, sample_size, best_value: list[BusinessSummary]}
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| location | Yes | ||
| service_query | Yes | Service, e.g. 'gel manicure', 'AC tune-up', 'dental cleaning' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. The description adds behavioral context: it returns real local prices (not national averages), includes low/median/high estimates, sample size, and the 3 best-value businesses with links. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a return structure line. It front-loads the main purpose and every sentence adds value. 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 the tool has 3 parameters (2 required) and no output schema, the description sufficiently explains what it does and what it returns (low/median/high prices, sample_size, best_value list). It is complete for an agent to understand usage and expected output.
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 only 33% (only service_query has a description). The description does not add meaning for 'location' or 'category' beyond the schema. While it explains the overall purpose, it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: answering 'how much does X cost near me' with real local prices, not national averages. It distinguishes from sibling tools (e.g., search_businesses, get_local_insights) by focusing specifically on price estimates.
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 use it: when a user asks about cost near a location. It provides a clear use case but does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_promotionsAAnswer 'any deals near me?' — current promotions, first-visit offers, and seasonal specials from local businesses, each with validity dates and a direct booking link.
Returns: list[{business: BusinessSummary, offer, valid_until, terms}]
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| location | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming this is a safe read operation. The description adds useful behavioral context by specifying the return structure (list of promotions with validity dates and booking links) and the scope (local businesses). It does not contradict 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 front-loaded with the core purpose. It uses a natural language example to immediately convey the tool's intent, followed by a clear return structure. Every sentence is relevant and there is no extraneous content.
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 3 parameters and an output schema, the description is partially complete. It explains the return type but does not elaborate on parameter usage or behavior (e.g., default values, constraints). While annotations and output schema provide some context, the lack of parameter documentation leaves gaps for an agent to properly invoke the 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 description adds minimal value beyond the schema for parameters. It implies location through 'near me' but does not explain the 'category' parameter (which filters by business type) or 'max_results' (which limits results and caps at 10). With 0% schema description coverage, the description should compensate but fails to do so.
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 natural language query 'Answer any deals near me?' which clearly indicates the tool's purpose of retrieving promotions. It specifies the types of deals (current promotions, first-visit offers, seasonal specials) and distinguishes from sibling tools like search_businesses and get_business_details by focusing on deals with validity dates and booking links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user asks about deals or promotions near a location, but it does not explicitly state when to avoid using this tool or mention alternative sibling tools. The lack of guidance on when-not-to-use or when to prefer siblings reduces clarity for an AI agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsAAnswer 'is this place any good?' — recent reviews plus a themed summary (what customers praise, what they complain about) so the assistant can give a balanced recommendation.
Returns: {rating, review_count, themes: {praise: [...], complaints: [...]},
recent_reviews: list[{rating, date, text_snippet}]}
| Name | Required | Description | Default |
|---|---|---|---|
| business_id | Yes | ||
| max_reviews | No | ||
| sentiment_summary | No | If true, include themed pros/cons summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's role is reduced. It adds value by detailing the return structure (rating, review_count, themes, recent_reviews) and the themed pros/cons summary, which goes beyond the annotations but does not contradict them.
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 extremely concise: two sentences with zero wasted words. The first sentence captures the purpose, and the second details the return format. It is front-loaded and 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?
Given the tool has 3 parameters, no output schema, but read-only annotations, the description is sufficiently complete. It covers the core functionality, use case, and return format. It could mention that business_id is required (though schema does), but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only sentiment_summary has a description). The tool description does not explain business_id or max_reviews parameters, though the return structure hints at the effect of sentiment_summary. It partially compensates but does not fully describe all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: answering 'is this place any good?' by providing recent reviews and a themed summary. It uses specific verbs (answer, give) and identifies the resource (reviews), clearly distinguishing it from siblings like ask_business_question or compare_businesses.
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 a clear use case (when someone asks about a place's quality) and implies the tool is for balanced recommendations. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_waitlistAWhen no slot fits, capture demand instead of losing it: add the customer to the business's waitlist. They are auto-notified (email/SMS) when a matching slot opens. Only call after the user explicitly agrees to join the waitlist.
Returns: {waitlist_id, position, status}
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | ||
| business_id | Yes | ||
| customer_name | Yes | ||
| customer_email | Yes | ||
| customer_phone | Yes | ||
| idempotency_key | Yes | ||
| preferred_dates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note the tool is idempotent and not read-only or destructive. The description adds useful behavioral context: auto-notification via email/SMS when a slot opens, and return values (waitlist_id, position, status). 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 short (3 sentences), front-loaded with purpose, and each sentence serves a distinct role: purpose, usage behavior, and return format. 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?
For a join-waitlist tool of moderate complexity, the description covers purpose, usage condition, behavioral details (auto-notification), and return summary. No output schema exists, but the description compensates by listing return fields. Could mention idempotency key, but annotation covers that.
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 0% for 7 required parameters. The description does not explain individual parameters beyond their names (e.g., business_id, customer_name). While the parameter names are somewhat self-explanatory, the description adds no additional meaning to guide correct usage.
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: adding a customer to a business's waitlist when no slot fits. It uses specific verb ('add') and resource ('business's waitlist'), and distinguishes from sibling tools like book_appointment and check_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call only after the user explicitly agrees to join the waitlist, providing a clear when-to-use condition. Also implies when not to use (when slot fits, use booking tool), contrasting with sibling book_appointment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_businessesAFind top-rated local service businesses matching a need near a location.
Returns ranked businesses with rating, distance, price band, one-line
highlight, the soonest available slot, and a hosted booking URL. Results
are bookable directly via check_availability + book_appointment.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language need, e.g. 'gel manicure', 'emergency water heater repair', 'deep tissue massage'. Not a business name — use get_business_details if the user names a business. | |
| category | No | Filter by vertical | |
| location | Yes | City/neighborhood/ZIP, e.g. 'Edison, NJ' or '08817' | |
| open_now | No | Only businesses open right now | |
| radius_km | No | ||
| min_rating | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. The description aligns by detailing output fields (rating, distance, price band, soonest slot, booking URL) and states that results are bookable via other tools. It adds context about ranking and bookability beyond the annotations. No contradictions. It effectively communicates the read-only nature and follow-up steps.
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 consists of two concise sentences. The first immediately states the purpose, and the second lists output fields and bookability. Every word adds value. No fluff or repetition. Front-loaded and 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?
Given the existence of an output schema, the description sufficiently explains the output (rating, distance, price band, slot, booking URL) and next steps. It does not mention pagination or sorting criteria, but these are acceptable gaps given the output schema. The description is nearly complete for a search tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 57% of parameters with descriptions (query, category, location, open_now). Three parameters (radius_km, min_rating, max_results) lack schema descriptions. The tool description does not add meaning for these parameters; it only provides a natural-language example for 'query'. It fails to compensate for the missing parameter documentation, which is necessary for an agent to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding top-rated local service businesses matching a need near a location. It specifies the output (rating, distance, price band, etc.) and distinguishes itself from siblings like get_business_details (which details a named business) and check_availability (which checks slots for a specific business). The verb 'find' and resource 'businesses' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to discover businesses by need and location. It mentions that results are bookable via check_availability and book_appointment, hinting at follow-up actions. However, it does not explicitly state when not to use the tool or compare it to alternative siblings like ask_business_question or get_business_details. The guidance is adequate but lacks exclusions.
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.
No comments yet. Be the first to start the discussion!
