Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 9 of 9 tools scored.
Every tool has a clear and distinct purpose: booking operations (place, modify, cancel, status), merchant discovery (search, details, availability), registry metadata, and feedback submission. No overlap or ambiguity.
All tool names follow a verb_noun pattern using underscore_case (e.g., place_booking, get_merchant, search_merchants). Verbs are descriptive and consistent across the set.
9 tools are well-scoped for a booking registry server, covering all necessary operations without being overly numerous or sparse. Each tool earns its place.
The tool set covers the full lifecycle: search merchants, get details and availability, place/modify/cancel bookings, check status, submit feedback, and registry metadata. No obvious gaps for the intended domain.
cancel_bookingCancel a bookingAInspectCancel a booking in any non-terminal state, or a confirmed reservation (the registry notifies the merchant). Cancellation is mandatory when the human no longer wants the table — no-shows destroy merchant trust and are tracked per developer key.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| booking_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable context: cancellation notifies the merchant and no-shows are tracked per developer key. It could further disclose reversibility or side effects, but the provided info is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information. It could be slightly more structured, but it is clear 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?
The description covers purpose and behavior but omits parameter details and output. For a tool with 2 parameters and no output schema, more context on parameters is needed for completeness.
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 0% and the description does not mention the parameters at all. It fails to explain that booking_id is required or what reason is used for.
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 cancels a booking in specific states and distinguishes from siblings like modify_booking by focusing on cancellation as mandatory when the human no longer wants the table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says cancellation is mandatory when the human no longer wants the table, providing clear guidance. However, it does not mention when to use alternatives like modify_booking instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityGet availability (honest v1 behavior)AInspectV1 does NOT hold live table availability — availability is checked on the phone call at booking time. This tool returns the merchant's reservation policy, structured hours, and holiday exceptions so you can pick a plausible time before calling place_booking.
| Name | Required | Description | Default |
|---|---|---|---|
| merchant_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses the key limitation: no live table availability. It also states the return contents (policy, hours, holidays). Additional behavioral context like idempotency is not necessary for this simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous words. The key limitation is front-loaded, and the purpose is directly stated.
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 gives a high-level idea of return contents but lacks detail on specific fields or structure. Given no output schema, this gap may force agents to guess the exact response format.
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 0% description coverage and the only parameter (merchant_id) is not elaborated in the description. The agent must infer its meaning from context, which is minimal. The description adds no parameter-specific guidance.
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 returns merchant reservation policy, hours, and holiday exceptions, and distinguishes it from live availability tools by noting it does not hold real-time data. It also relates it to place_booking for picking plausible times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is used to pick a plausible time before calling place_booking, and clarifies that live availability is checked during the phone call. Provides clear context but does not explicitly list when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_booking_statusGet booking statusAInspectState machine position for a booking: pending → queued → in_progress → confirmed | failed | needs_input (plus cancelled). Includes structured details on confirmation (confirmed_time, confirmation_code, merchant_instructions), structured failure reason (no_answer | fully_booked | closed | policy_mismatch | merchant_declined | bad_data), or needs_input options awaiting your decision. include_events=true returns the full audit log.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes | ||
| include_events | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses the return structure (confirmation details, failure reasons with enumerated causes, needs_input options) and the effect of include_events. However, it does not explicitly state that the operation is read-only or any potential 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 front-loads the core purpose and lists statuses concisely. It is slightly verbose with examples but remains efficient 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?
For a simple read operation with 2 parameters and no output schema, the description covers the state machine, return details, and parameter behavior adequately. It is fairly complete but could mention that it does not modify state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the include_events parameter ('returns the full audit log'), adding value beyond the schema. However, booking_id is not described, and schema coverage is 0%. Overall provides some but not complete parameter 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?
The description clearly states the tool returns the state machine position for a booking, enumerates all possible states (pending, queued, in_progress, confirmed, failed, needs_input, cancelled), and specifies the structured details returned. This distinguishes it from sibling tools like cancel_booking, modify_booking, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking booking status but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like get_registry_meta or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_merchantGet merchant (full signal dump)AInspectEvery field the registry holds on one merchant: schema fields, structured hours, raw feedback history, platform-observed operational stats, and per-field provenance with timestamps. Maximal data, zero opinion — the registry never scores or ranks.
| Name | Required | Description | Default |
|---|---|---|---|
| merchant_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'maximal data, zero opinion' indicating non-destructive read and unbiased data, but does not disclose potential performance implications, rate limits, or response size expectations.
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 essential information, no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many fields, no output schema), the description provides a reasonable high-level list of data categories. It could be more specific about operational stats and provenance, but is sufficient for an agent to understand the tool's broad output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate but only mentions 'one merchant' implicitly. It does not clarify the format or source of 'merchant_id', adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves every field the registry holds on a single merchant, listing specific data types (schema fields, hours, feedback, stats, provenance). It effectively distinguishes from siblings like 'search_merchants' (list) and 'get_registry_meta' (metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when full merchant data is needed, but lacks explicit guidance on when to use versus alternatives, no when-not scenarios, and no mention of prerequisites (e.g., validity of merchant_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_registry_metaGet registry metadataAInspectEvaluate the registry itself: per-city coverage (with each city's IANA timezone), merchant/bookable counts, verification and freshness stats, feedback corpus size, schema version, and the documented deterministic ordering rule. Honest by design — including how stale the data is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses a read-only evaluation, including output details like per-city timezone, counts, freshness stats, and ordering rule. The phrase 'honest by design — including how stale the data is' adds transparency about data staleness.
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 the core action ('Evaluate the registry itself'), and every detail (coverage, counts, stats, honesty) adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient context: what data is returned and the 'honest' nature. It lacks explicit mention of how results are emitted (e.g., JSON format), but the detail is adequate for a metadata tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. The description correctly avoids parameter explanations, maintaining a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool evaluates the registry itself, listing specific attributes (per-city coverage, counts, stats). It clearly distinguishes from sibling tools focused on bookings, merchants, or availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by listing registry-wide metrics, but there is no explicit statement on when to use or not use this tool versus alternatives like search_merchants or get_booking_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modify_bookingModify a booking / resolve needs_inputAInspectAmend a booking before or after the call. For a booking in needs_input: pass accept_option_index to take one of the merchant's offered times (confirms immediately), or pass a new datetime/party_size to re-queue an amended request. Modifying an already-confirmed booking cancels it and books the new request (new booking_id returned).
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | No | New requested time, ISO-8601; naive means the merchant's local wall time | |
| booking_id | Yes | ||
| party_size | No | ||
| window_minutes | No | ||
| accept_option_index | No | Index into needs_input_options to accept |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: modifying a confirmed booking cancels it and returns a new booking_id; for needs_input, passing accept_option_index confirms immediately. Missing details on side effects or authorization.
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 tight sentences that quickly convey the primary use case and two sub-scenarios. No redundant 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?
Covers the main scenarios but omits return value details (e.g., new booking_id structure) and potential errors. Given no annotations and 5 parameters, additional context would be helpful.
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 40%. The description adds context for accept_option_index and datetime/party_size but does not explain window_minutes or booking_id. Partially compensates for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Amend' and the resource 'booking', and distinguishes between two distinct scenarios (needs_input and confirmed bookings), making the purpose unambiguous and differentiating from siblings like cancel_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?
Provides explicit guidance on when to use for needs_input and confirmed bookings, and explains how to modify vs accept. However, it does not explicitly state when not to use or mention alternatives like place_booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
place_bookingPlace a booking (async)AInspectRequest a table reservation. Returns booking_id with state 'queued' immediately; fulfillment is asynchronous (a call is placed to the merchant). Poll get_booking_status or supply callback_url for webhooks. RETRY SAFETY: pass a unique client_reference_id (recommended: always); if this call times out or errors ambiguously, retry with the SAME client_reference_id and the registry returns the already-created booking instead of double-booking the restaurant. Never re-call place_booking after a timeout without one. If the merchant counter-offers a time within window_minutes and accept_within_window=true, it is auto-accepted (recommended). Otherwise the booking pauses in needs_input for you to resolve via modify_booking. Merchants on the human_call channel are fulfilled by a human operator during the operator window published in get_registry_meta — those bookings queue until worked (up to the channel SLA), so book ahead rather than for the next hour.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | No | Optional phone/email for confirmation relay to the end human | |
| datetime | Yes | Requested time, ISO-8601. Naive ('2026-07-18T19:00') means the merchant's LOCAL wall time (see the merchant's timezone field); an explicit offset ('2026-07-18T19:00:00+09:00') is also accepted | |
| party_size | Yes | ||
| merchant_id | Yes | ||
| callback_url | No | Webhook URL for booking state-change events | |
| window_minutes | No | Acceptable +/- window around datetime | |
| sandbox_outcome | No | TEST ONLY, sandbox merchants (sandbox: true): force the simulated call's result so you can exercise a specific branch on demand — confirmed, no_answer (retries then fails), counter_offer (pauses in needs_input), fully_booked, merchant_declined, bad_data. Rejected for real merchants; omit it in production | |
| reservation_name | Yes | Name for the reservation | |
| special_requests | No | ||
| client_reference_id | No | Your unique ID for this booking request (a UUID is ideal). Retrying with the same value returns the existing booking (idempotent_replay: true) instead of creating a duplicate; the same value with different parameters is rejected as client_reference_conflict | |
| accept_within_window | No | Auto-accept merchant counter-offers inside the window (recommended: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses async fulfillment, idempotency via client_reference_id, auto-accept behavior, human_call channel operator delays, and sandbox testing. 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?
Description is detailed but not unnecessarily verbose; front-loaded with core purpose and async behavior. Could be slightly more structured, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, description covers all behavioral aspects: async flow, idempotency, merchant channels, auto-accept, testing, and error handling. Complete for agent understanding.
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?
Adds significant meaning beyond the schema: explains datetime naive vs offset, client_reference_id idempotency details, sandbox_outcome usage, and accept_within_window recommendation. Schema coverage is 73%, but description enhances understanding.
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 'Request a table reservation' and distinguishes it from siblings like cancel_booking, get_booking_status, and modify_booking. It specifies the async nature and immediate return of booking_id with state 'queued'.
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 guidance on polling get_booking_status, using callback_url, retry safety with client_reference_id, and resolving paused bookings via modify_booking. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_merchantsSearch merchantsAInspectFilter-based search over the restaurant registry (coverage cities + timezones in get_registry_meta). NOT ranked: results come back in deterministic order (merchant_id ASC by default; distance ASC when lat/lng given and order_by="distance"). Returns compact records with pagination. Use get_merchant for the full signal dump on a specific merchant. All filters are optional and combinable.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude for geo-radius filter (requires lng and radius_km) | |
| lng | No | ||
| limit | No | ||
| offset | No | ||
| open_at | No | ISO-8601 datetime; only merchants open at this time. With an explicit offset ('2026-07-18T19:00:00+09:00' or trailing Z) the instant is evaluated in each merchant's own timezone; without one it means each merchant's local wall clock | |
| sandbox | No | Filter by merchant kind. true = sandbox test merchants only (safe integration targets: they book end-to-end and return a SIMULATED confirmation, never dialing a real venue). false = real merchants only — use this for any booking a human will act on. Omitted = both. Every result carries `sandbox`; never present a sandbox confirmation to a user as a real reservation. | |
| order_by | No | ||
| radius_km | No | Radius in km around lat/lng | |
| party_size | No | Only merchants that can seat this party size | |
| cuisine_tags | No | Match ANY of these cuisines, e.g. ['japanese','korean'] | |
| neighborhood | No | Exact neighborhood name, e.g. 'Mission' | |
| bookable_only | No | Only merchants the registry can book right now (phone-verified, accepts reservations, not opted out) | |
| attribute_tags | No | Match ALL of these attributes, e.g. ['outdoor_seating','vegetarian_friendly'] | |
| price_band_max | No | ||
| price_band_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that results are not ranked, have deterministic order (merchant_id ASC or distance ASC with lat/lng), and returns compact records with pagination. No mention of rate limits or destructive actions, but the provided traits are clear.
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-loaded with purpose, no filler. Every sentence adds useful 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 15 optional parameters and no output schema, the description explains pagination, ordering, and the distinction from get_merchant. It could mention what fields are in 'compact records' but that's minor. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%; the description adds value by explaining the open_at timezone behavior and the sandbox filter semantics. However, many parameters (e.g., lat/lng/radius_km dependency) are not elaborated beyond the schema. Baseline 3 is appropriate with some additional 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?
The description clearly states 'Filter-based search over the restaurant registry' and distinguishes itself from get_merchant by noting 'compact records with pagination' vs. 'full signal dump'. It also mentions coverage info via get_registry_meta.
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 explains when to use this tool (for filtered search) and when to use get_merchant instead. It notes that all filters are optional and combinable, and describes the default ordering behavior. It does not explicitly list when not to use, but provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit post-visit feedbackAInspectReport how a confirmed reservation actually went. Accepted only against a confirmed booking_id, once per booking, within 14 days of confirmation. Structured fields first; optional free text ≤ 500 chars. This corpus is served raw to all agents via get_merchant — it is never editorialized or turned into a score.
| Name | Required | Description | Default |
|---|---|---|---|
| free_text | No | ||
| booking_id | Yes | ||
| would_repeat | No | ||
| seated_on_time | No | ||
| matched_description | No | Did the merchant match the registry's description? | |
| reservation_honored | Yes | Did the merchant honor the reservation? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states that feedback is served raw to get_merchant and not editorialized, which is informative. However, it does not disclose any side effects, permissions required, or whether the submission is reversible.
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, each sentence adds necessary information without waste. 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?
The description provides key constraints (booking_id required, once per booking, 14-day window) and explains how feedback is used (raw to get_merchant). However, it does not describe return behavior (e.g., success/error responses) or the outcome of submission. Lacks completeness given 6 parameters and no output 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 only 33% (two parameters have descriptions). The description adds minimal value beyond the schema: it mentions 'Structured fields first' and 'optional free text ≤ 500 chars,' but the free text constraint is already in the schema. No explanation is given for booking_id, would_repeat, or seated_on_time, which are missing from the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Report how a confirmed reservation actually went,' using a specific verb ('report') and resource ('how a confirmed reservation went'). It distinguishes from sibling tools like cancel_booking, get_availability, etc., which handle different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit conditions are given: 'Accepted only against a confirmed booking_id, once per booking, within 14 days of confirmation.' It also notes optional free text with a 500-char limit. No exclusions or alternatives are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.