Mercantry Registry
Server Details
Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- mercantry/registry
- GitHub Stars
- 0
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.2/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Each tool targets a distinct action: search/list merchants, get details, place/modify/cancel bookings, check status, submit feedback. No significant overlap; get_availability vs get_merchant serve different purposes.
All tools follow a consistent 'verb_noun' pattern (e.g., get_merchant, place_booking, submit_feedback). No mixed conventions or vague verbs.
9 tools is well-scoped for a restaurant registry server, covering the full booking lifecycle and merchant discovery without bloat.
Covers CRUD for bookings (create, read status, modify, cancel) plus merchant search/detail and feedback. Minor gap: no tool to list bookings by client_reference_id or user, but core workflows are covered.
Available Tools
9 toolscancel_bookingCancel a bookingAInspect
Cancel 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavioral traits: it notifies the merchant for confirmed reservations and mentions tracking per developer key. However, it does not cover reversibility, permission needs, or side effects like refunds, leaving gaps.
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 with no extraneous content. It is front-loaded with the core action and adds important context. Slight improvement could separate state details more cleanly.
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 low complexity, the description provides adequate purpose and usage guidance but lacks parameter documentation and deeper behavioral info. It is sufficient but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters (booking_id and reason). The description only implies booking_id through context but offers no additional meaning beyond the schema's bare structure.
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 ('cancel') and resource ('booking'), specifies the allowed states ('any non-terminal state, or a confirmed reservation'), and distinguishes from siblings like modify_booking by focusing on cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Cancellation is mandatory when the human no longer wants the table' and emphasizes consequences of no-shows, providing clear usage context. It does not explicitly list alternatives but implies when to use.
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)AInspect
V1 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of disclosing behavior. It upfront states 'V1 does NOT hold live table availability', which is a critical behavioral trait that prevents misuse. It also honestly marks the tool as 'honest v1 behavior'.
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 focused sentences with no redundant information. It front-loads the key caveat and concisely conveys purpose and return content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one parameter), no output schema, and no annotations, the description sufficiently covers the tool's purpose, behavior, return content, and usage context. It enables an agent to decide when to call this tool and what to expect.
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 single parameter 'merchant_id' has no schema description (0% coverage). The description does not explain the parameter beyond the tool's context. While the parameter is simple, the lack of any explicit description or format constraints leaves room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 'the merchant's reservation policy, structured hours, and holiday exceptions' with the specific purpose to 'pick a plausible time before calling place_booking'. It distinguishes itself from sibling tools by explicitly noting it does not hold live 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?
The description tells when to use this tool ('before calling place_booking') and what it does not do ('does NOT hold live table availability'). It implies when not to use it (for live availability), but does not explicitly list exclusions or alternatives beyond place_booking.
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 statusAInspect
State 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes the tool's behavior: it returns state transitions, structured confirmation details, failure reasons, and needs_input options. It also explains the include_events parameter effect. However, it does not explicitly state the tool is read-only or non-destructive, but the nature of status retrieval makes this obvious.
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 yet informative, using a clear state machine notation. It packs essential details without unnecessary fluff. One minor improvement could be separating the state list from the parameter note for better readability.
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 status retrieval tool with two parameters and no output schema, the description provides adequate context: state machine, structured return values, and the optional audit log. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only explains the include_events parameter ('include_events=true returns full audit log'). The booking_id parameter is not described, though its purpose is implicit. Given the low coverage, the description partially compensates but could be more explicit about both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the current state machine position of a booking, with explicit state transitions listed. It effectively distinguishes from sibling tools like cancel_booking or modify_booking, as it focuses solely on status retrieval.
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 indirectly indicates use when needing to check a booking's status and understand its state, including confirmation or failure details. It lacks explicit guidance on when not to use or direct alternatives, but the context is clear enough for most scenarios.
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)AInspect
Every 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's behavior: it returns maximal data without scoring or ranking. It details what is included (schema fields, hours, feedback, stats, provenance) and underscores that the registry never scores, providing complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading key detail about data types and adding clarification about no scoring. Every sentence provides 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 single required parameter and no output schema, the description comprehensively explains what data the tool returns, including provenance and stats. It covers all needed context for a reader to understand the tool's 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?
The schema has no description for the merchant_id parameter (0% coverage), and the description does not add any meaning about its format, constraints, or source. It only mentions 'one merchant' but fails to compensate for the lack of schema description.
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 returns all registry fields for a merchant, listing specific data types like schema fields, structured hours, feedback history, stats, and provenance. This clearly distinguishes it from sibling tools like search_merchants.
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 for retrieving comprehensive merchant data and mentions 'zero opinion' but does not explicitly state when to use this tool over siblings like search_merchants or get_availability. No excluded scenarios or alternatives given.
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 metadataAInspect
Evaluate 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It states 'Honest by design — including how stale the data is,' revealing transparency about staleness. No mention of side effects, but the read-only nature is 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?
Two concise sentences cover purpose and behavioral promise. Could be slightly more structured, but it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists key return items (coverage, counts, stats). It provides enough context for an agent to understand what data it will receive.
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 no parameters, so schema coverage is 100%. The description does not need to add parameter semantics; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates the registry itself, listing specific data points like per-city coverage, counts, stats, and staleness. It is distinct from sibling tools which handle bookings and merchants.
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?
No explicit when-to-use or alternatives are given, but the context of sibling tools implies it is for introspection. The description lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
modify_bookingModify a booking / resolve needs_inputAInspect
Amend 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the critical behavior that modifying a confirmed booking cancels it and returns a new booking_id. It could mention other side effects (e.g., whether original booking is fully replaced), but the key behavioral trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The purpose is stated first, and critical behavioral detail (cancellation during modify) is provided efficiently.
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 moderate complexity (5 params, two modes) and no output schema, the description explains the two scenarios and the key side effect. It lacks details about parameter combinations and window_minutes, but overall it provides sufficient context for correct tool invocation.
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% (2 of 5 params described in schema). Description adds meaning: explains that datetime/party_size re-queues an amended request, and accept_option_index confirms an offered time. However, window_minutes and party_size are not elaborated, and the description does not fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies a booking (verb+resource) and distinguishes two distinct use cases: booking in 'needs_input' status vs. confirmed booking. It also implicitly differentiates from sibling tools like cancel_booking and place_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 explicitly advises when to use for each mode (needs_input with accept_option_index vs. confirmed with new datetime/party_size). It does not explicitly list alternatives or when not to use, 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.
place_bookingPlace a booking (async)AInspect
Request 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 | |
| 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses async nature, immediate queued state, polling/webhook options, idempotency via client_reference_id, auto-acceptance behavior, and human operator processing. Comprehensive behavioral disclosure.
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?
Slightly lengthy but each sentence adds value. Front-loaded with key async behavior. Could be more structured (e.g., bullet points for retry and auto-acceptance), but overall efficient for the complexity.
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 async process, retry safety, counter-offer handling, channel types, and booking strategy. Complete for a tool of this complexity, given that related tools handle output status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 70% schema coverage, the description adds significant meaning: explains client_reference_id idempotency and conflict behavior, auto-acceptance logic for accept_within_window, and datetime timezone handling. Goes well 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 that the tool requests a table reservation. It uses specific verbs like 'Request a table reservation' and describes the async behavior, distinguishing it from synchronous tools like get_booking_status.
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 client_reference_id for retry safety ('Never re-call place_booking after a timeout without one'), when auto-acceptance is recommended, and advises booking ahead for human_call channel. Implicitly differentiates from modify_booking by describing when to use it for counter-offers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_merchantsSearch merchantsAInspect
Filter-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 | |
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses not ranked, deterministic order (merchant_id ASC default, distance ASC when lat/lng + order_by='distance'), returns compact records with pagination. Could add detail on pagination format or error behavior but sufficient for typical usage.
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?
Four well-structured sentences, front-loaded with purpose, then ordering, then return format and alternative tool, then filter optionality. No redundancy or 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 14 parameters, no output schema, no annotations, description provides good overview including ordering, pagination, and sibling tool references. Could elaborate on pagination details (e.g., default limit) or error conditions, but adequate for most agents.
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 57%, but description adds valuable context: ordering logic (merchant_id vs distance) and pagination behavior. Per-parameter details are mostly in schema. No missing critical parameter info.
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 starts with 'Filter-based search over the restaurant registry' clearly stating verb (search) and resource (restaurant registry). Distinguishes from sibling get_merchant (full signal dump) and get_registry_meta (coverage info).
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 directs to get_merchant for full signal dump. Explains ordering behavior (deterministic, merchant_id or distance) and that all filters optional and combinable. Specifies use case for get_registry_meta. Clear when to use vs alternatives.
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 feedbackAInspect
Report 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? |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that feedback data is served raw via get_merchant and never editorialized or scored, which adds some behavioral context. However, it does not mention whether the operation is destructive, authentication requirements, 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?
The description is three sentences long, front-loading the main purpose and key constraints. It is efficient, though it could be slightly more concise by combining the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 2 required, no output schema, and no annotations, the description is incomplete. It does not explain return values, error handling, or what happens on success. The constraints are clear, but the agent lacks information about the outcome of the call.
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%, with descriptions only for matched_description and reservation_honored. The description adds meaning for free_text (optional, max 500 chars) but does not explain booking_id, would_repeat, or seated_on_time. It mentions structured fields generally but does not list them, so it only partially compensates for the 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 identifies the tool's purpose: reporting how a confirmed reservation actually went. It uses specific verbs ('Report') and resources ('post-visit feedback'), and it is distinct from sibling tools like cancel_booking or place_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 clear usage constraints: only against a confirmed booking_id, once per booking, within 14 days of confirmation. It also mentions structured fields first and optional free text with a 500-character limit, but does not explicitly state when not to use it or suggest 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!