Sunrays — Local Service Booking
Server Details
Book local tradespeople — plumber, electrician, HVAC, and 7 more — via your AI agent. All US.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.1/5 across 11 of 11 tools scored. Lowest: 3.5/5.
Each tool targets a distinct home service (appliance, electrician, garage door, etc.) with clear descriptions, leaving no ambiguity. The handyman tool is explicitly defined as non-specialist, avoiding overlap with specialists.
All booking tools follow the consistent 'book_<service>' pattern in snake_case, but 'request_other_service' breaks the pattern with 'request_' instead of 'book_', causing a minor inconsistency.
With 11 tools, the surface covers a comprehensive range of common home services without being overwhelming. The count is well-scoped for a local service booking domain.
Despite covering many services, the tools lack a crucial quote tool that all booking tools require to be called first, making the workflow incomplete. Additionally, there are no tools for cancellation, rescheduling, or listing existing bookings.
Available Tools
11 toolsbook_appliance_repairBook Local ServiceADestructiveIdempotentInspect
Book an appliance repair technician for washing machines, dryers, refrigerators, dishwashers, ovens, or other major home appliances. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds 'Returns a confirmed booking' and instructs to call /quote first, but does not elaborate on side effects, cancellation policies, or what happens if the quote is not obtained. 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 two sentences: first defines purpose and return value, second gives usage guidance ('Call /quote first'). No wasted words, front-loaded with essential 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 10 parameters (7 required), an output schema exists, and annotations are present, the description covers core aspects. It provides a key prerequisite (call /quote) but lacks details about payment handling, cancellation, or error states. Still, it is largely complete for a booking 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?
Input schema has 100% description coverage for all 10 parameters, each with clear textual descriptions. The tool description does not add further meaning beyond the schema, so baseline score 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 books an appliance repair technician for washing machines, dryers, refrigerators, dishwashers, ovens, or other major home appliances. It lists specific appliances and explicitly mentions 'appliance repair technician', distinguishing it from sibling tools like book_plumber or book_electrician.
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 instructs to call '/quote first', indicating a prerequisite step. It implies when to use this tool: for appliance issues. However, it does not explicitly state when not to use it or name alternatives, though sibling tool names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_electricianBook Local ServiceADestructiveIdempotentInspect
Book a licensed electrician for outlet repairs, breaker issues, smart home device installation, EV charger installation, lighting, or electrical inspections. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring idempotentHint=true and destructiveHint=false, the description adds the note about calling /quote first and returns a confirmed booking. Lacks details on failure modes or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: first states purpose with examples, second clarifies prerequisite and outcome. 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 10 parameters and high schema coverage, the description is adequate. Output schema exists to explain return values. Missing explicit mention of idempotency but annotations fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add meaningful parameter-level detail beyond listing service categories, so 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?
Description clearly states the verb 'Book', specific resource 'licensed electrician', and lists explicit services (outlet repairs, breaker issues, etc.). This distinguishes it from sibling tools that book other trades.
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?
Instructions to 'Call /quote first' provide explicit when-to-use guidance. However, does not explicitly state when not to use or contrast with siblings, leaving some ambiguity about scope boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_garage_doorBook Local ServiceADestructiveIdempotentInspect
Book a garage door technician for broken springs, off-track doors, opener failures, or new garage door installation. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint and non-destructive hints. Description adds that the tool returns a confirmed booking and requires a prior quote call, which are useful behavioral cues beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and examples. 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 complexity (10 params, 7 required, output schema exists), the description covers the main purpose and prerequisite. Could mention more about booking flow or output details, but output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. Description does not add new parameter details; 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?
Description includes specific verb 'Book', resource 'garage door technician', and examples of issues. Clearly distinguishes from sibling tools for other 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?
Mentions prerequisite 'Call /quote first', indicating when to use this tool after obtaining a quote. No explicit exclusion of alternatives, but the service type is clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_handymanBook Local ServiceADestructiveIdempotentInspect
Book a handyman for general home repairs: furniture assembly, TV mounting, drywall patching, door fixes, minor plumbing fixtures, and similar non-specialist tasks. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds that the tool 'Returns a confirmed booking' and requires a prior /quote call. It does not contradict annotations, but fails to disclose potential side effects or authentication details beyond the parameter descriptions.
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 concise sentences that immediately convey purpose, prerequisites, and return value. Every sentence is informative without 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?
Given the tool's complexity (10 parameters, output schema exists), the description is adequately complete. It covers the scope, return type, and a critical prerequisite. Minor gaps exist regarding optional parameters like spending_cap_signed, but schema compensates.
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% with detailed parameter descriptions. The tool description adds marginal value by providing examples of tasks (e.g., 'furniture assembly') that relate to the 'issue' parameter. Baseline of 3 is appropriate as schema does the heavy lifting.
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 action 'Book a handyman' for 'general home repairs' and lists specific tasks like furniture assembly and TV mounting. It distinguishes from sibling tools by specifying 'non-specialist tasks', avoiding overlap with specialized trades.
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 prerequisite: 'Call /quote first'. It implies when to use (general repairs) and when not (specialist tasks), but does not explicitly list alternative tools. The sibling list helps, but more explicit guidance would improve score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_hvacBook Local ServiceADestructiveIdempotentInspect
Book an HVAC technician for heating or cooling failures, AC tune-ups, furnace inspections, duct cleaning, or smart thermostat installation. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotency and non-destructiveness; the description adds that it returns a confirmed booking but does not disclose potential payment side effects or failure modes.
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, front-loaded with purpose. Could be more structured by separating the quote callout as a prerequisite step.
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?
Missing critical flow details: the quote requirement is vague, the spending_cap_signed parameter is unexplained, and the booking process assumes prior knowledge.
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 description adds minimal value beyond providing context for the 'issue' parameter via service examples.
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 'Book an HVAC technician' and lists specific services (e.g., AC tune-ups, duct cleaning), clearly distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call /quote first' implies a prerequisite but does not explain when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_lawn_careBook Local ServiceADestructiveIdempotentInspect
Book lawn care service for mowing, edging, fertilization, weed control, or leaf cleanup. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds 'Returns a confirmed booking', which is consistent but does not elaborate on side effects or permissions. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the core action and specifics, with no unnecessary words. 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?
With 10 parameters (7 required) and an output schema present to document return values, the description covers the main purpose and a prerequisite step ('Call /quote first'). It lacks details on fallbacks if the quote step is omitted, but overall 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%, with all parameters described in the schema. The description does not add additional meaning beyond what the schema provides, so it meets the baseline.
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 'book' and the resource 'lawn care service', listing specific services like mowing, edging, etc. It distinguishes from siblings (other book_* tools) by specifying 'lawn care', making the purpose unambiguous.
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 'Call /quote first', providing a clear prerequisite step. It does not, however, mention exclusions or alternatives among sibling tools, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_locksmithBook Local ServiceADestructiveIdempotentInspect
Book a locksmith for residential or commercial lockouts, rekeying, lock replacement, or security lock upgrades. High-urgency capable — can dispatch within 1 hour for emergencies. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: mentions high-urgency dispatch, need for prior quote, and that it returns a confirmed booking. 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?
Three concise sentences front-loading purpose, with each sentence adding value: scope, urgency, and workflow hint. No waste.
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 usage, prerequisites, key behavioral traits, and return value. Slight gap: no mention of what the response object contains beyond a confirmation, but output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add further parameter meaning beyond what is already in the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Book' and resource 'locksmith', and lists specific services (lockouts, rekeying, etc.), effectively distinguishing it from sibling tools for other 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?
Provides clear context: when to use (emergencies, lock services), mentions prerequisite 'Call /quote first', and states high-urgency capability. Lacks explicit comparison to alternatives, but siblings are distinct services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_pest_controlBook Local ServiceADestructiveIdempotentInspect
Book a pest control specialist for rodents, ants, cockroaches, bed bugs, termites, wasps, or general pest inspection. Returns a confirmed booking. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and not destructive. The description adds that booking returns a confirmed confirmation, but does not elaborate on side effects, auth needs, or failure behavior. With annotations present, this is adequate but minimal.
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 three short sentences: what it does, its outcome, and a prerequisite. No fluff; every sentence earns its place. Front-loaded with the core 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 output schema exists, return values are covered. The description provides the key prerequisite (quote) and the confirmed booking outcome. Missing minor details like error cases or quote auto-fetch, but overall sufficient for a booking tool with 10 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 coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter guidance (e.g., how to obtain spending_cap_signed), 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 states the action (book), the resource (pest control specialist), and the specific pests covered (rodents, ants, etc.), distinguishing it from sibling tools like book_plumber or book_electrician.
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 advises to 'Call /quote first', providing a clear prerequisite. It does not detail when not to use the tool or list alternatives, but the sibling tools imply other service options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_plumberBook Local ServiceADestructiveIdempotentInspect
Book a licensed plumber for leaks, clogs, water heater issues, pipe repairs, or drain emergencies. Returns a confirmed booking with price and dispatch time, or a payment setup link if no card is on file. Always call /quote first to get the spending_cap_signed token.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. The description adds useful details: returns a confirmed booking with price and dispatch time, or a payment link. 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 succinct with three sentences: purpose, return behavior, and prerequisite. No wasted words, and critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and output schema, the description covers the core purpose, return format, and a critical prerequisite. It could mention city/agent_id but schema handles those. Sufficient for a booking 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 covers all parameters (100% description coverage). The description adds value by explaining the spending_cap_signed parameter's origin (from /quote), which aids 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: booking a plumber for specific issues (leaks, clogs, etc.). It distinguishes from sibling tools like book_electrician by focusing on plumbing-specific 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 call /quote first for a token, providing a clear prerequisite. However, it does not elaborate on when not to use the tool or direct to alternatives, though sibling differentiation is inherent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_rooferBook Local ServiceADestructiveIdempotentInspect
Book a roofer for storm damage assessment, shingle replacement, roof leak repair, or gutter installation. Note: large custom roof replacements require on-site quote (not available here). Returns a confirmed booking for repair work. Call /quote first.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | US ZIP code of the service location (5 digits, e.g. '94102') | |
| city | No | City name for the service location | |
| issue | Yes | Brief plain-text description of the problem or service needed (e.g. 'kitchen sink clog', 'water heater not heating') | |
| phone | Yes | Caller phone number, including country code (e.g. '+1 415 555 1234' or '4155551234'). Required so the tradesperson can call before arrival. | |
| state | Yes | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | Yes | ISO 8601 datetime for the requested service window start (e.g. '2026-05-08T14:00:00Z') | |
| caller_id | Yes | Email address of the human on whose behalf the agent is booking (used as Stripe customer key) | |
| street_address | Yes | Street address where the work will happen, including unit/apartment number if applicable (e.g. '425 Mission St, Apt 5B'). Required so the tradesperson knows exactly where to go. | |
| spending_cap_signed | No | Optional. Signed spending cap token. If omitted, the server fetches a quote automatically and applies a default cap before booking. Pass through unchanged only if the caller already produced one. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. Present when status='error'. |
| status | Yes | Result state. 'booked' = booking confirmed. 'needs_card_setup' = first-time caller, present checkout_url to user then retry. 'no_coverage_yet' = ZIP outside service area. 'error' = see error field. |
| booking_id | No | Stable booking identifier. Present when status='booked'. |
| price_cents | No | Final quoted price in USD cents. Present when status='booked'. |
| provider_id | No | Identifier of the dispatched tradesperson. Present when status='booked'. |
| receipt_url | No | Stripe-hosted receipt URL. Present when status='booked'. |
| checkout_url | No | Hosted Stripe Payment Element URL. Present when status='needs_card_setup'. |
| scheduled_for | No | Confirmed dispatch window start (ISO 8601). Present when status='booked'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it returns a confirmed booking, which aligns with the idempotentHint. It also adds a behavioral constraint (large replacements need on-site quote) beyond what annotations provide. 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 two sentences, front-loaded with purpose, and every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and usage caveat well. With an output schema present, return values are documented. Could briefly mention that successful booking returns confirmation details, but not essential.
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% with thorough parameter descriptions. The tool description does not add additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it books a roofer for specific tasks (storm damage, shingle replacement, etc.) and distinguishes from sibling tools by specifying roofer-specific services. It also mentions a limitation (large custom roof replacements require on-site quote), adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when not to use the tool (large custom roof replacements) and directs to call /quote first for those cases. This provides clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_other_serviceRequest Other ServiceADestructiveInspect
Log a request for a service type not covered by the 10 named tools (e.g. carpet cleaning, dog walking, painting, moving). Does NOT book — adds to the waitlist to signal demand for future service expansion. Use this when none of the book_* tools match the user's need.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name for the service location | |
| issue | No | Additional context about what the person needs | |
| state | No | US state abbreviation (2 letters, e.g. 'CA') | |
| agent_id | No | DID or identifier of the calling agent (e.g. 'did:web:claude.ai'). Logged for analytics. | |
| datetime | No | Preferred service datetime (ISO 8601, e.g. '2026-05-09T14:00:00Z') | |
| caller_id | No | Email address of the human on whose behalf the agent is requesting (used to notify when service launches) | |
| location_zip | Yes | US ZIP code where the service is needed | |
| service_type_freetext | Yes | Plain-text description of the service type requested (e.g. 'carpet cleaning', 'dog walker', 'in-home massage') |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Human-readable error message. |
| status | Yes | 'logged' = waitlist entry created. 'error' = see error field. |
| request_id | No | Stable identifier for the waitlist entry. Present when status='logged'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which show no destructive or read-only hints), description adds that it only signals demand for future expansion, not a booking. This gives the agent understanding of side effects.
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, first sentence states purpose and examples, second clarifies behavior and usage. No fluff, 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?
Covers key differentiator (not booking, waitlist), alternatives, and purpose. Output schema exists, so return values are documented. Minor gap: no details on post-logging actions, but schema implies caller notification.
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?
Input schema has 100% coverage with descriptions for all 8 parameters. The description does not add extra meaning to individual parameters beyond the schema, but provides overall context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it logs a request for services not in the 10 named tools, with examples like carpet cleaning and dog walking. It explicitly distinguishes itself from booking tools by stating it only adds to a waitlist.
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 tells when to use: when none of the book_* tools match. Also explains what it does not do (book) and what it does (add to waitlist), providing clear usage boundaries.
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!