Sunrays — Local Service Booking
Server Details
Book real local tradespeople — plumber, electrician, HVAC, and 7 more — via your AI agent. All US. Confirmed bookings with price and receipt.
- 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/5 across 11 of 11 tools scored.
Each tool targets a distinct service category (appliance, electrician, garage, handyman, HVAC, lawn, locksmith, pest, plumber, roofer, plus a catch-all). There is no overlap; an agent can clearly differentiate which tool to use based on the service needed.
The vast majority follow a consistent 'book_<service>' pattern. The exception is 'request_other_service' which uses 'request' instead of 'book', but it is still a recognizable pattern for the catch-all category.
With 11 tools covering the most common home service categories plus a catch-all, the number is well-scoped for a local service booking platform. It is neither too few nor excessively many.
A critical gap exists: every book_* tool instructs agents to 'Call /quote first', but no quote tool is provided, creating a dead end. Additionally, the catch-all 'request_other_service' only adds to a waitlist rather than enabling booking, so agents cannot fulfill requests for uncovered services.
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 destructiveHint=true and idempotentHint=true, so the mutation nature is clear. The description adds that it returns a confirmed booking and hints at a quote prerequisite. This adds some context but does not significantly expand 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?
Three sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value (purpose, return value, prerequisite). Highly concise and well-structured.
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, annotations, output schema existence, and sibling tools, the description adequately covers the tool's purpose and prerequisite. It doesn't explain the output schema but that is not required when it exists. Sufficient for effective use but could mention the need for address/phone, which are in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description adds no additional parameter meaning, earning the baseline score of 3.
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 names the tool as booking an appliance repair technician for major home appliances, listing specific appliance types. It distinguishes from sibling tools (electrician, plumber, etc.) by specifying the domain. It also states the return value (confirmed 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 a clear prerequisite: 'Call /quote first.' It implies context of use (appliance repair) but does not explicitly state when not to use or name alternatives. This is clear context with no exclusions, fitting a 4.
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?
The description discloses that the tool returns a confirmed booking, implying a mutation of state, which aligns with destructiveHint=true. It also adds the behavioral context of needing a prior /quote call. Annotations already provide readOnlyHint=false and idempotentHint=true, so the description adds value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose in one concise line, and the second gives a prerequisite and outcome. Every word earns its place; 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?
With 10 parameters, 100% schema coverage, and an output schema, the description is complete enough for the agent to understand the tool's role and required prior step. It could optionally mention the output format (but the output schema likely covers that), so not a major 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%, so baseline is 3. The description adds value by enumerating example issues (outlet repairs, breaker issues, etc.) that go beyond the schema's generic 'issue' field description, helping the agent understand what to include.
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 specifies that the tool books a licensed electrician for specific electrical tasks such as outlet repairs, breaker issues, and EV charger installation, clearly distinguishing it from siblings like book_plumber or book_hvac.
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 tells the agent when to use this tool (for electrical work) and explicitly instructs 'Call /quote first,' providing a prerequisite step. It does not, however, explicitly state when not to use it or compare to alternatives beyond the sibling list.
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 already indicate destructiveHint=true (mutation) and idempotentHint=true (safe retry). The description only adds 'Returns a confirmed booking,' which repeats the obvious output, adding no extra behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences, front-loading the core purpose immediately. Every sentence earns its place without 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 tool's complexity (10 parameters, 7 required) and the existence of an output schema, the description covers core purpose and a key caveat but omits details about the booking confirmation flow, handling of optional parameters like spending_cap_signed, or integration with the quote endpoint.
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 parameters are fully documented in the input schema. The description does not elaborate on parameter meanings or usage, meeting the baseline but adding no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair 'Book a garage door technician' and lists common garage door issues (broken springs, off-track doors, opener failures, new installations), clearly distinguishing it from sibling tools that book other trade 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 includes an important prerequisite 'Call /quote first' indicating a required prior action. However, it does not explicitly state when not to use the tool or provide alternative tools for different scenarios.
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 destructive and not read-only, so the description adds the important context that a prior quote is needed. However, it does not disclose other behavioral traits like cancellation policies, payment handling, or any side effects beyond booking creation.
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 very concise with two sentences, covering scope and a key prerequisite. It is front-loaded with the main action and examples, though the 'Call /quote first' instruction could be placed earlier.
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, and sibling tools, the description is minimal. It explains what tasks are covered but omits details on pricing, availability, geographic limitations, or output format (though output schema exists). Adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no further parameter meaning 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?
The description clearly states it books a handyman for general home repairs, listing specific tasks (furniture assembly, TV mounting, etc.) that distinguish it from specialist tools like book_electrician or book_plumber. It also mentions the return of a confirmed 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 gives a prerequisite instruction ('Call /quote first') and implicitly differentiates from sibling tools by listing non-specialist tasks. However, it does not explicitly state when to avoid using this tool or mention alternatives.
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 provide readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=true. Description adds 'returns a confirmed booking' and 'call /quote first', which are usage hints rather than deeper behavioral context. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences front-loading purpose, then outcome, then prerequisite. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and output schema, description covers purpose and behavior adequately. It mentions the booking return value and advice to get a quote, but does not explain how the quote relates to the spending_cap_signed parameter, leaving a minor 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%, so baseline is 3. Description does not add meaning beyond schema; it only lists service types but no parameter specifics. The 'Call /quote first' hint relates to usage, not parameter semantics.
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 tool books HVAC technicians for specific issues like heating/cooling failures, AC tune-ups, etc. It distinguishes from sibling tools like book_electrician or book_plumber by focusing on HVAC context. Verb 'book' plus resource 'HVAC technician' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives clear context: HVAC failures, tune-ups, inspections, etc. It advises 'Call /quote first', indicating a prerequisite step. However, it does not explicitly exclude other use cases or compare with siblings beyond the specific examples.
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?
The description states it returns a confirmed booking, which aligns with annotations (destructiveHint=true, idempotentHint=true). It does not contradict annotations. Additional context about calling /quote first is helpful, but it could disclose more about required authentication or 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?
The description consists of three concise, front-loaded sentences that immediately convey the purpose, return value, and prerequisite. Every sentence adds value with 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?
Given 10 parameters and the existence of an output schema, the description is somewhat brief. It covers purpose and a prerequisite but lacks details on authentication, error handling, or when to use alternatives. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description adds context by listing eligible services but does not significantly enhance parameter understanding 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 action ('Book lawn care service') and lists specific services (mowing, edging, fertilization, weed control, leaf cleanup). It distinguishes from sibling tools like book_electrician or book_plumber by focusing exclusively on lawn care tasks.
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 the agent to call /quote first, which is a valuable prerequisite. However, it does not explicitly state when not to use this tool or provide comparisons to siblings, though the context of lawn care is clear.
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 context beyond annotations: high-urgency dispatch, confirmed booking return, and quote prerequisite. However, does not explain side effects of destructiveHint or idempotent behavior, nor details on authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, urgency, and prerequisite. Every sentence adds value with 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?
Covers primary use case and urgency. With output schema existing, return value explanation is not required. Lacks details on post-booking process (cancellation, confirmation) but adequate 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% with good parameter descriptions. The tool description adds minimal parameter-level 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 it books a locksmith for specific residential/commercial services (lockouts, rekeying, replacement, upgrades), distinguishing it from sibling tools for 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?
Provides clear context for locksmith needs and mentions high-urgency capability, but does not explicitly compare to alternatives or state when not to use. The prerequisite 'Call /quote first' offers some guidance.
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 provide key behavioral hints (destructiveHint=true, idempotentHint=true). The description adds context about returning a confirmed booking and the need for a prior quote, which is useful but does not go beyond what annotations imply. 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), with the key action ('Book a pest control specialist') front-loaded. Every sentence adds value: specifying pests, stating the output, and giving usage guidance. 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's complexity (10 parameters, siblings, output schema), the description covers the main purpose, output, and a prerequisite. It does not detail return format (but output schema exists) or all parameter relationships, but is sufficient for an agent to understand the core task.
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 all parameters have descriptions. The tool description only mentions a few pest types and does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'book' and the specific resource 'pest control specialist', listing common pests and inspection types. It distinguishes from sibling tools like 'book_electrician' by specifying the pest control domain.
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 includes a clear prerequisite ('Call /quote first'), which guides when to use the tool. However, it does not explicitly state when to prefer this tool over its siblings or when not to use it. For a tool with many siblings, this is a minor gap.
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?
The description adds that the tool returns a confirmed booking with price and dispatch time or a payment link, which is useful. However, annotations already indicate destructiveHint=true (mutation) and readOnlyHint=false. No additional behavioral traits beyond what annotations imply are disclosed.
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 well-structured sentences. The first sentence states the purpose, and the second provides return behavior and a key prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters (7 required), a standard output schema, and the description covers the core functionality and prerequisite, it is sufficiently complete for the complexity. Minor omissions (e.g., agent_id parameter not mentioned) are acceptable as schema covers them.
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 baseline is 3. The description adds minimal extra meaning; it mentions the 'spending_cap_signed' parameter's role and the prerequisite call, but doesn't significantly expand on other parameters 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?
The description clearly states the verb 'Book' and the resource 'plumber', and lists specific plumbing issues (leaks, clogs, water heater, etc.), distinguishing it from sibling tools like book_electrician or book_hvac.
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 the agent to call '/quote' first to get the 'spending_cap_signed' token, providing clear prerequisite guidance. However, it does not explicitly mention when not to use this tool or suggest alternatives.
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?
Annotations indicate destructiveHint=true (mutation) and idempotentHint=true. The description adds that it 'Returns a confirmed booking' and the prerequisite to call /quote, but does not detail side effects (e.g., charges, calendar entries) beyond the confirmation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note, no redundant words. The primary purpose and key limitations are front-loaded. Every sentence earns its place without 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 tool's complexity (10 params, 7 required, output schema exists), the description covers the main use case, a key limitation, and a prerequisite step. It does not explain the output schema (covered separately) but is sufficiently complete for an agent to understand the tool's role.
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 has 100% parameter description coverage, so baseline is 3. The description does not discuss parameters beyond listing service types, which map to the 'issue' parameter implicitly. No additional semantic value added over 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?
Description specifies the resource (roofer) and lists specific services: storm damage assessment, shingle replacement, roof leak repair, gutter installation. It also clarifies what is not available (large custom roof replacements), distinguishing its scope from 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?
Explicitly advises to 'Call /quote first' and notes that large custom replacements require on-site quote, providing a clear when-to-use and when-not-to-use. However, it does not compare with sibling tools explicitly, though the context implies roofing-specific booking.
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?
Describes non-booking behavior and waitlist purpose. Annotations already indicate destructiveHint: true, but description adds context that it's only adding to demand signal, not mutating existing data.
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 and usage. No unnecessary words. 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 8 parameters, 2 required, and an output schema exists, the description is adequate. Covers purpose, usage, behavioral nuance, and parameter semantics sufficiently.
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 8 parameters with descriptions. The tool description adds only minor extra context (e.g., caller_id used for notification). Baseline 3 due to high 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?
Clearly states it logs a request for service types not covered by 10 named tools, with examples. Distinguishes from siblings by explicitly referring to book_* 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?
Explicitly says when to use (when no book_* tool matches) and what it does NOT do (does not book, adds to waitlist). Provides clear alternatives.
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!