Campo Belo — neighborhood directory: local places, events, menus, offers, and services.
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.2/5 across 26 of 28 tools scored. Lowest: 3.6/5.
Each tool targets a distinct action on a specific resource (e.g., create_booking vs create_checkout vs reserve_event_tickets). Descriptions clearly differentiate purposes, and no two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_availability, list_categories, search_dishes). Verbs like get, list, create, request, rsvp are used uniformly, making the set predictable.
28 tools is above the typical 3-15 range, but the server covers a broad domain (places, events, movies, booking, store, etc.). Each tool serves a clear purpose, so the count is justified for the scope.
The tool surface is extensive, covering searching, details, reviews, booking, events, menus, etc. Minor gaps exist (e.g., no cancel/update operations), but they are likely intentional given the user-facing nature of the server.
create_bookingAInspectBook an appointment slot at a venue (Wix Bookings). NOTHING IS BOOKED UNTIL THE CUSTOMER PAYS: this returns a checkout URL, and the booking stays off the venue's calendar until a human opens that URL and completes payment on the venue's own site. Tell the user they must open the link. Call get_availability immediately before this — the slot is re-validated server-side and a taken slot is rejected. The contact email is NOT verified at this step; the checkout is what confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | Yes | Who the booking is for. All three are required by the venue to confirm or reschedule. | |
| endDate | Yes | Slot end as an ISO instant, exactly as returned by get_availability. | |
| serviceId | Yes | Service ID from list_booking_services (called with the same place_slug). | |
| startDate | Yes | Slot start as an ISO instant, exactly as returned by get_availability. | |
| place_slug | Yes | Venue place slug from search_places. | |
| resourceId | No | Optional staff/resource ID from the slot, when the user picked a specific professional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses key behaviors: nothing is booked until payment, returns checkout URL, slot re-validated, taken slot rejected, email not verified. 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?
Two paragraphs, front-loaded with critical payment gotcha, then usage order and constraints. Every sentence 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?
Given tool complexity (6 params, nested object, no output schema), description covers purpose, output (checkout URL), preconditions, post-conditions, and caveats comprehensively.
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%, but description adds contextual meaning beyond schema: dates must match get_availability, place_slug from search_places, contact fields required by venue. Adds significant 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 clearly states the verb 'Book' and the resource 'appointment slot at a venue (Wix Bookings)', and distinguishes it from siblings by highlighting the payment step and checkout URL return.
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: call get_availability before usage, inform user to open link, warns about slot re-validation and email verification. Clearly communicates when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_checkoutAInspectCreate a direct checkout URL for one or more store products (Wix Stores). The user clicks the URL to complete payment on the site — no login required on the AI agent side.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Products to add to cart. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses that the tool creates a checkout URL and that no AI agent login is needed. However, it does not mention potential side effects (e.g., does it create a temporary resource?), required permissions, or any idempotency guarantees. The disclosure is basic but adequate for a straightforward tool.
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 the purpose and adding a key constraint (no login required). Every part is essential and efficient, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter) and no output schema, the description covers the core function and a usage constraint. However, it does not mention return value (the URL) or error scenarios, which would be helpful for an agent. Still, it is mostly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents parameters. The tool description adds value by clarifying that multiple products can be included ('one or more store products') and that it is for checkout, which helps the agent understand the context. This goes slightly beyond the bare 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's action: 'Create a direct checkout URL for one or more store products (Wix Stores).' It specifies the resource (store products) and the result (a URL for payment). This distinguishes it from sibling tools like create_booking or list_products.
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 notes that 'no login required on the AI agent side,' clarifying a usage condition. However, it does not explicitly compare to alternatives or state when not to use this tool. The purpose alone differentiates it from most siblings, but explicit guidance is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_availabilityAInspectGet available time slots for a bookable service on a given date (Wix Bookings). Pass the serviceId from list_booking_services and a date in YYYY-MM-DD. Pass the same place_slug you used there — slot times are returned in the VENUE's timezone, which is not necessarily the directory's.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format (e.g. "2026-06-25"). | |
| serviceId | Yes | Service ID from list_booking_services. | |
| place_slug | No | Venue place slug — use the same one passed to list_booking_services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that slot times are returned in the venue's timezone, but does not mention read-only nature, rate limits, or other behavioral traits like empty results handling.
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 the core purpose. No unnecessary words or repetition.
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 lacks details about output format (e.g., array of time slots) and constraints like date must be in future. Given no output schema, some explanation of return value would improve 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 100%, but the description adds value by clarifying that place_slug must match the one used in list_booking_services and that times are in venue's timezone. This goes beyond 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 explicitly states 'Get available time slots for a bookable service on a given date', clearly identifying the action (get) and resource (available time slots). It distinguishes from sibling tools like create_booking, which uses these slots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear instructions on how to use the tool, including prerequisite parameters from list_booking_services and date format. It also notes the timezone caveat. However, it does not explicitly state when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_ticketsAInspectGet ticket types and prices for a specific event (Wix Events). Pass the event slug from list_events. Returns ticket names, prices, sale status, and how many are left.
| Name | Required | Description | Default |
|---|---|---|---|
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully describes the tool's behavior: it returns ticket names, prices, sale status, and remaining count. It does not mention destructive effects or auth needs, but the read-only nature is implied.
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, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description sufficiently covers input requirements, output contents, and ties to a sibling tool ('list_events'), making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'event_slug' with 100% coverage. The description adds useful context by specifying that the slug comes from 'list_events', enhancing the parameter's meaning.
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 ticket types and prices for a specific event in Wix Events. It specifies the resource and context, and differentiates from siblings like 'reserve_event_tickets' and 'list_events'.
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 tells the agent to pass the event slug from 'list_events', which is a clear prerequisite. It also describes the return values but does not mention when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_loyalty_infoAInspectGet the loyalty/rewards program details for this site (Wix Loyalty). Returns program name, points currency name, and tier structure with required points per tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should bear the burden of behavioral disclosure. It implies a read operation but does not explicitly state read-only, idempotent, or authorization needs. The description is adequate but not comprehensive.
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?
Single sentence is highly concise, includes key specifics (program name, points currency, tier structure), and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers return values adequately. However, it could mention read-only nature or site-scoping 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?
No parameters exist, so baseline is 4. The description adds no parameter info, but schema coverage is 100% (empty), so no deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves loyalty/rewards program details for the site, listing specific attributes (name, points currency, tier structure), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_site_info or other tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_placeAInspectGet full details for a specific place by its URL slug, including opening hours, a precomputed open_now boolean, amenity attributes (slugs), a delivery array of curated delivery-app deep-links (ifood, rappi, uber-eats — each { platform, url }), ratings, address, and neighborhood.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug of the place, e.g. "cafe-example". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses return fields (including precomputed open_now and delivery deep-links) and implies a safe read operation. It does not discuss error handling, permissions, or rate limits, but the information provided is sufficient for basic understanding.
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 a single sentence that efficiently conveys purpose and key fields. It front-loads the primary action and resource, but the dense list of fields could be more readable if restructured.
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 a single required parameter and no output schema, the description comprehensively covers the expected response fields. It does not mention edge cases or error conditions, but these are minor omissions for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'slug' parameter. The tool description adds only the phrase 'by its URL slug', which aligns with but does not substantially extend the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details for a specific place by URL slug, listing specific fields (opening hours, open_now, attributes, delivery links, ratings, address, neighborhood). This distinguishes it from sibling tools like search_places that search rather than fetch a specific resource.
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 getting a known place by slug but does not explicitly mention when to use this tool versus alternatives (e.g., search_places for querying). No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsCInspectGet published reviews for this site (Wix Reviews). Returns reviewer name, rating, title, and content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reviews to return (default 10, max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the return fields but does not disclose behavioral traits such as default ordering, pagination behavior, authentication requirements, or any side effects. Since no annotations are provided, the description carries the full burden for transparency and falls short.
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 a single, concise sentence that effectively communicates the core purpose and output. It is front-loaded and contains no redundant information. However, it could include more structure or additional details without becoming verbose.
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 simplicity of the tool (one optional parameter, no output schema), the description provides the essential purpose and return fields. However, it lacks information on result ordering or pagination, which might be needed for complete understanding. It is minimally 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?
The input schema already fully describes the only parameter (limit) with documentation on default and max values. The tool description adds no additional meaning beyond what the schema provides, so the 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?
Clearly states the action 'Get published reviews' and specifies the resource 'Wix Reviews'. It also lists the returned fields (reviewer name, rating, title, content), making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like list_products or list_blog_posts.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where this tool is appropriate or not. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_site_infoAInspectReturns basic information about this neighborhood directory: name, locale, domain, description, canonical URLs for key sections, plus the current LOCAL TIME and CURRENT WEATHER at the neighborhood (temperature, condition). Use this for any "what time is it there" or "what's the weather like" context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses the tool's output (local time, weather, site info). It is a simple read operation, and no hidden behaviors are expected.
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 a single, well-structured sentence that front-loads the core purpose and adds specific details 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 no parameters, no output schema, and a straightforward purpose, the description covers all relevant aspects of the tool's behavior and 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?
No parameters exist (0 params, schema coverage 100%). Description correctly does not add parameter info. Baseline for 0 params is 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 it returns basic information about a neighborhood directory, listing specific data points like name, locale, domain, description, canonical URLs, and current local time and weather. This clearly distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this for any 'what time is it there' or 'what's the weather like' context.' No exclusion criteria are given, 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.
list_blog_postsAInspectList recent published blog posts for this site (Wix Blog). Returns title, excerpt, author, published date, reading time, categories, and the post URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts to return (default 10, max 50). | |
| category | No | Filter by category label. Case-insensitive substring match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it returns recent published posts with specified fields, providing some behavioral context. However, lacks details on sorting order, pagination beyond limit, authentication needs, or side effects. No annotations present to supplement.
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?
Single sentence efficiently conveys purpose and return fields. Slightly dense but front-loaded and earns its place; could be split for 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?
In absence of output schema, describes return fields adequately. Covers key aspects but omits potential error scenarios or advanced behaviors like cursor-based pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds no extra meaning beyond what the schema already provides for parameters, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes the tool as listing recent published blog posts for the Wix Blog, with specific verb 'List' and resource 'blog posts'. Distinguishes from sibling list tools that cover other entities like events or products.
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 guidance on when to use this tool versus alternatives. While the context implies use for blog posts, there is no mention of prerequisites, when not to use it, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_booking_servicesAInspectList a venue's services — what it offers, with price and duration. Pass place_slug (from search_places) to list the services of a specific VENUE — a salon, clinic or studio listed in this directory; that is what you want in almost every case, and it is the only form whose serviceId works with create_booking. Omitting place_slug lists the directory site's own services instead, which most sites do not have. Returns name, description, price, duration in minutes, and bookableViaMcp. Services are listed for EVERY venue, including those with no online booking system — check bookableViaMcp: when it is false, id is null and you cannot book through create_booking, so point the user at bookingUrl or the venue's page instead.
| Name | Required | Description | Default |
|---|---|---|---|
| place_slug | No | Venue place slug from search_places. Strongly recommended — without it you get the directory's own services, not a venue's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it lists services for every venue (including non-bookable ones), explains the bookableViaMcp flag, and notes that id is null when not bookable. Discloses output fields and consequence for create_booking.
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 a single paragraph but well-structured: purpose first, then conditional guidance, then return fields and caveat. It is front-loaded and every sentence adds value. Could be slightly shorter or broken into bullets for clarity, but remains 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?
For a simple 1-parameter tool with no output schema, the description is remarkably complete: it names all return fields, explains the critical bookableViaMcp field, and provides actionable next steps. No gaps remain.
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?
Although schema coverage is 100%, the description adds deep context: the conditional behavior of place_slug (venue vs directory services), the link to search_places and create_booking, and the interpretation of the bookableViaMcp field. This goes beyond the schema's 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 clearly states the tool lists a venue's services with price and duration. It uses a specific verb 'List' and resource 'venue's services'. It distinguishes itself from siblings like create_booking and get_availability by focusing on service listing and linking to search_places.
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 explicit guidance: use place_slug from search_places to list a specific venue's services (the common case), and omit it only for the directory's own services (rare). It also warns that services include non-bookable venues, advising to check bookableViaMcp and redirect to bookingUrl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspectReturns the full category taxonomy of this directory site: top-level groups with their subcategories, localized labels, schema.org types, and live place counts.
| 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 the return data structure: top-level groups, subcategories, localized labels, schema.org types, and live place counts. This provides clear behavioral expectations for an idempotent read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that immediately communicates the tool's purpose and return content. Every word adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema and no annotations, the description completely documents what the tool returns, including specific data fields. No additional information is necessary for correct 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?
The tool has zero parameters, and schema description coverage is 100% (none). Per rules, baseline is 4 since no parameters need explanation. Description does not repeat schema information.
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 full category taxonomy of a directory site, including specific components like top-level groups, subcategories, localized labels, schema.org types, and live place counts. This verb+resource description distinguishes it from sibling list_ tools that return different types of data.
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 guidance is provided on when to use this tool versus alternatives. While the context shows many list_ siblings, the description does not offer any conditions, prerequisites, or exclusions to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_eventsAInspectList upcoming events in this neighborhood with date, venue, price, and URL. Events within the next 7 days include a weatherForecast (condition + min/max temperature) for the event day — use it to tell users e.g. "the event is at X and it will be raining". Pass filter to narrow by time or price; filter: "agora" answers "what can I go to right now" and is resolved live on every call, which no cached page can do.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events to return (default 20, max 50). | |
| filter | No | Narrow the list: "agora" = on stage at this exact moment (season runs and day-granular sources are excluded, because their stored window says nothing about whether a session is on right now); "hoje"/"amanha"/"fim-de-semana" = running on those days, including multi-day runs; "gratis" = free to attend, including externally-ticketed events priced at 0. | |
| upcoming_only | No | Only return upcoming or in-progress events (default true). |
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 discloses that events within 7 days include weather forecast and that the 'agora' filter is resolved live. However, it does not mention potential side effects (likely none for a list tool).
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 front-loaded with the main purpose and has clear structure. It is somewhat verbose with the filter explanations, but each sentence contributes necessary details.
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 no output schema, the description adequately explains return fields (date, venue, price, URL, weather for next 7 days). It could mention ordering or pagination, but overall is complete for typical use.
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%, but the description adds significant value by explaining the meaning of each filter value in detail (e.g., 'agora' excludes season runs, 'gratis' includes externally-ticketed free events). It also notes the default limit and maximum.
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 lists upcoming events with specific fields (date, venue, price, URL) and includes weather for events within 7 days. It distinguishes from sibling tools like list_movies or list_offers by focusing on events.
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 the filter parameter, especially 'agora' for real-time events, contrasting with cached pages. It lacks explicit guidance on when not to use this tool versus alternatives like get_event_tickets or rsvp_event, 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.
list_faqsAInspectGet all FAQ questions and answers for this site (Wix FAQ). Grouped by category. Use this to answer common questions about the site — opening hours, parking, policies, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It correctly indicates a read operation (Get all) and specifies the output includes grouping by category. No contradictions; it sufficiently discloses expected 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 extremely concise with two sentences, no extraneous information, and is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool does and when to use it, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the schema description coverage is 100%. The description does not need to add parameter details, and it provides enough context about the data returned.
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 all FAQ questions and answers for the site, grouped by category. This provides a specific verb and resource, and distinguishes it from sibling tools which do not involve FAQs.
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 using this tool to answer common questions about the site, with examples like opening hours and parking. This gives clear context, though it lacks explicit 'when not to use' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_formsAInspectList available contact/signup forms on this site (Wix Forms). Returns form name, ID, and field definitions (label, type, required). Use before submit_form to discover which fields to fill.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return fields, but no annotations exist; could mention absence of pagination or potential empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and returns, every sentence valuable.
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?
Fully adequate for a simple zero-parameter tool with no output schema, covering purpose, returns, and usage hint.
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?
No parameters, baseline score of 4; description adds no parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available contact/signup forms, specifies the return data (name, ID, field definitions), and distinguishes it from the sibling submit_form tool.
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 using this tool before submit_form to discover fields, but does not provide exclusions or 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.
list_guidesAInspectList curated editorial guides ("best of" lists) published by this site — ranked places with editorial notes. The best source for "best X in this neighborhood" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max guides to return (default 20, max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It describes the content (ranked places with editorial notes) and implies a list operation, but does not disclose ordering, pagination beyond schema defaults, or read-only nature explicitly.
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 wasted words. Front-loaded with the core action and resource, followed by usage guidance.
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 list tool with one optional parameter and no output schema, the description adequately conveys what is returned. Could mention ordering or filtering limitations, but is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'limit' parameter, so baseline is 3. The description adds context about the content ('ranked places with editorial notes') but does not add meaning beyond the schema's own 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 clearly states it lists editorial guides with ranking and editorial notes, distinguishing it from other list tools by specifying it's for 'best X in neighborhood' questions.
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 'The best source for 'best X in this neighborhood' questions,' indicating when to use it, though it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_offersBInspectList active promotions and deals available in this neighborhood directory. Returns discount label, promo code (if any), CTA link, validity window, and which business/place it belongs to. FLASH offers have a countdown deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by offer kind. FLASH = time-limited flash sale with countdown. Omit to return all active offers. | |
| limit | No | Max offers to return (default 20, max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses returned fields (discount label, promo code, CTA link, validity window, business/place) and notes that FLASH offers have a countdown deadline, but does not mention pagination, sorting, or what happens when no offers are active.
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 fluff. The first sentence defines the core purpose, and the second adds important specificity about FLASH offers. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists returned fields but lacks an output schema. For a listing tool, details about pagination, default ordering, and response structure (array vs object) would improve completeness. Current description is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds contextual value by explaining FLASH offers have a countdown deadline, which complements the kind enum. No extra semantics for the limit parameter.
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 'list' and the resource 'active promotions and deals in this neighborhood directory'. It distinguishes the resource from siblings like list_products or list_events by focusing on offers/promotions/deals, but does not explicitly call out differentiation.
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 guidance on when to use this tool versus alternatives like get_loyalty_info or list_pricing_plans. The description lacks explicit when/when-not context, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pricing_plansAInspectList membership or subscription plans (Wix Pricing Plans). Pass place_slug (from search_places) to list the plans of a specific VENUE — a gym, studio or clinic listed in this directory (e.g. its monthly/annual membership); that is what you want in almost every case. Omitting place_slug lists the directory site's own plans instead, which most sites do not have. Returns plan name, description, price, billing cycle, perks, and a direct checkout URL.
| Name | Required | Description | Default |
|---|---|---|---|
| place_slug | No | Venue place slug from search_places. Strongly recommended — without it you get the directory's own plans, not a venue's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the effect of the parameter and what the tool returns (plan details and checkout URL), giving full 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?
Three sentences with no extraneous information: purpose, parameter guidance, return fields. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no output schema, the description covers all necessary information: what it does, how to use it, and what it returns. Completely 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?
The schema covers the parameter with 100% coverage, and the description adds extra context about its significance and when to use it, reinforcing the schema's 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 'List membership or subscription plans (Wix Pricing Plans)', specifying the verb and resource. It distinguishes from sibling tools by explaining the two use cases (venue-specific vs directory-wide plans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to pass `place_slug` (for venue plans, 'almost every case') and what happens when omitted (directory's own plans). It provides clear guidance on the typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspectList products in this site's store (Wix Stores). Returns name, price, stock status, and product type.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional search term matched against product name. | |
| limit | No | Max products to return (default 20, max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation by stating it lists products, but does not explicitly confirm non-destructiveness. No annotations are provided, so the description carries the burden, but 'list' is generally understood as safe. No details on authentication, rate limits, 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?
Two sentences with no wasted words. First sentence clearly states purpose, second lists return fields. 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 list tool with no output schema, the description covers the core purpose and return fields. However, it lacks details on pagination behavior beyond the limit parameter and does not mention ordering or error conditions. Still, it is largely 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?
Schema coverage is 100% with descriptions for both parameters (q and limit). The description adds context about returned fields (name, price, stock status, product type) but does not enhance parameter meaning further. Baseline of 3 is appropriate as schema already documents parameters well.
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 'List products in this site's store (Wix Stores)', specifying verb, resource, and context. This distinguishes it from sibling tools that list other entities like blog posts or events.
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 guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest other tools for specific cases (e.g., filtering by other criteria).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_profilesAInspectList solo service-provider profiles on this site — businesses without a fixed physical location (e.g. dog walkers, tutors, personal trainers). Returns name, profile URL, category, and any available metadata (age, height, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max profiles to return (default 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, description only lists returned fields but doesn't disclose side effects, auth needs, 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?
Single sentence with example, efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists return fields. Missing ordering or pagination details but adequate for simple 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?
Single parameter 'limit' fully documented in schema; description adds no extra meaning.
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 the tool lists solo service-provider profiles without a fixed physical location, with examples. Distinct from sibling list 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?
Implies when to use (for solo service-providers) but no explicit exclusion or comparison to alternative list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_reservationAInspectRequest a table at a restaurant. THE RESTAURANT IS NOT NOTIFIED YET: the request is held and a confirmation email is sent to the address you provide, and only when that person clicks the link does the restaurant receive it. Tell the user to check their inbox — the link expires in 24 hours. Use a real address belonging to the person you are acting for; the confirmation link is deliberately not returned to you. This is a request, not a confirmed booking: the restaurant confirms out of band.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name the table is under. | |
| Yes | The guest's own email — the confirmation link is sent here. | ||
| phone | No | Optional phone number for the restaurant to reach the guest. | |
| message | No | Optional note (occasion, dietary needs, seating preference). | |
| partySize | Yes | Number of people (1–30). | |
| place_slug | Yes | Restaurant place slug from search_places. | |
| requestedAt | Yes | Desired date and time as an ISO instant. Must be in the future. |
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 fully discloses the asynchronous nature: restaurant is not notified until email confirmation, link expires, confirmation link is not returned to the agent. It clearly states this is not a confirmed booking.
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, consisting of four sentences with no wasted words. It is front-loaded with the main action and logically presents the key behavioral points.
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 moderate complexity (asynchronous booking request) and lack of annotations or output schema, the description covers the essential behavioral aspects well. It explains the confirmation process and user expectation. Minor gap: no mention of error handling or failure scenarios.
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 baseline is 3. The description reinforces the purpose of the 'email' parameter (the guest's own email) and the flow, but does not add significant new parameter semantics 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 tool's purpose: 'Request a table at a restaurant.' It distinguishes itself from a confirmed booking by emphasizing it is a request, not a confirmed booking, and explains the email confirmation flow. This differentiates it from sibling tools like 'create_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 explicit usage instructions: tell the user to check their inbox, the link expires in 24 hours, use a real address. It implicitly distinguishes from alternatives by emphasizing that the restaurant is not notified until confirmation. It could be improved by directly comparing to 'create_booking'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reserve_event_ticketsAInspectHold tickets for an event sold through this site (Wix Events) and return a checkout URL. THE HOLD IS TEMPORARY AND NOTHING IS PAID: the tickets are not the user's until a human opens the URL and completes checkout, and the hold expires on its own if they don't. Max 10 tickets and 10 ticket types per reservation. Only works for events this site sells directly — for events sold elsewhere (Sympla, Ingresse, Sesc), use the event's own ticketUrl instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tickets | Yes | Ticket types and quantities to hold. | |
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It transparently explains that the hold is temporary, unpaid, requires human checkout via the URL, and expires. It does not cover authorization or error scenarios, but for a non-destructive operation this is adequate. Slight deduction for lack of failure behavior details.
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, each earning its place: first sentence states purpose, second clarifies the temporary/unpaid nature, third gives limits and alternatives. No redundancy, front-loaded with key 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 no output schema or annotations, the description provides sufficient context for a reservation tool: returns a checkout URL, explains the hold mechanism, and notes limitations. It lacks details on response format or error cases, but for a straightforward tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds context that event_slug comes from list_events and ticketDefinitionId from get_event_tickets, and mentions the overall limits (10 tickets/types). This adds marginal value beyond the schema, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hold tickets for an event sold through this site (Wix Events) and return a checkout URL.' It uses a specific verb ('Hold') and resource ('tickets for an event'), and distinguishes itself from sibling tools like create_booking or create_checkout by emphasizing the temporary, unpaid hold.
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 explicit when-to-use and when-not-to-use guidance: it works only for events sold directly through this site, and for external events users should use the event's own ticketUrl. It also states limits (max 10 tickets and 10 ticket types), helping the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rsvp_eventAInspectRSVP to a free event on this site (Wix Events). NOBODY IS ON THE GUEST LIST YET: a confirmation email goes to the address you provide, and the RSVP is only submitted when that person clicks the link (expires in 24 hours). Tell the user to check their inbox. Use a real address belonging to the person you are acting for — the confirmation link is deliberately not returned to you.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The guest's own email — the confirmation link is sent here. | ||
| lastName | Yes | Guest last name. | |
| firstName | Yes | Guest first name. | |
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It comprehensively discloses the two-step RSVP process (confirmation email, link click), the 24-hour expiry, and the fact that the confirmation link is deliberately not returned. It also instructs the agent to use a real address and tell the user to check their inbox.
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 compact—a few sentences that front-load the purpose and then add essential behavioral details. Every sentence earns its place; there is 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 the tool's simplicity and the absence of an output schema, the description covers main usage and behavior. It does not mention possible error states (e.g., invalid event slug, duplicate email) or success feedback beyond the email being sent, which could be helpful for agent error handling.
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 4 parameters with descriptions (100% coverage), setting baseline at 3. The description adds value by emphasizing that the email must be a real address belonging to the person acting for, reinforcing the schema's note that the confirmation link goes there. This is critical for agent behavior.
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: RSVP to a free event on Wix Events. It distinguishes from siblings like list_events (listing) and reserve_event_tickets (likely paid events) by specifying 'free event'. The verb 'RSVP' and resource 'event' are specific.
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 free events requiring RSVP confirmation. It provides crucial context: that confirmation is via email link, expires in 24h, and the link is not returned. However, it does not explicitly mention when not to use (e.g., for paid events, use reserve_event_tickets), which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_dishesAInspectFind which restaurants serve a dish in this neighborhood. Searches every menu item across all restaurants on the site, grouped by dish — e.g. query "feijoada" returns each restaurant serving it with price, description, dietary labels, and the place URL. Omit the query to list the most-served dishes. Use this for any "where can I eat X" question.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max dishes to return (default 20, max 50). | |
| query | No | Dish name or part of it, e.g. "feijoada", "pizza margherita". Omit to list top dishes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool searches all restaurants, groups results by dish, and what fields are returned. It does not mention authentication or rate limits, but for a read-only search tool this 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 three sentences: first states purpose, second details behavior with an example, third gives usage guidance. No wasted words, front-loaded with the main action.
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 search tool with only 2 optional parameters and no output schema, the description completely covers what the tool does, how to use it, and what the response looks like.
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 descriptions for 'limit' and 'query'. The description adds context about grouping by dish and the return format, which supplements the schema nicely.
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: 'Find which restaurants serve a dish in this neighborhood.' It provides a concrete example with a query and what information is returned, and it implicitly distinguishes from sibling tools like 'get_restaurant_menus' by specifying it searches across all restaurants.
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 'Use this for any 'where can I eat X' question' and explains behavior when omitting the query. While it does not list when not to use it, the context is clear and sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_placesAInspectSearch for places (restaurants, cafes, shops, etc.) in this neighborhood. The q match is accent-insensitive and typo-tolerant ("acai" finds "Açaí", "restaurnt" finds "Restaurante"), ranked by relevance. Compose filters for multi-condition queries: category, neighborhood, open_now (true = open at this exact moment), and attributes (amenity slugs, ALL must match). Each result includes a precomputed open_now boolean, an attributes array (amenity slugs), a delivery array of curated delivery-app deep-links (ifood, rappi, 99food, uber-eats — each { platform, url }), rating, and structured hours (Google Maps periods: day 0=Sun–6=Sat, time "HHMM"). Common amenity slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free (availability varies per place).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text term matched against place name and address — accent-insensitive and typo-tolerant. | |
| limit | No | Max results to return (default 20, max 100). | |
| category | No | Filter by category label (e.g. "Café"). Case-insensitive substring match. | |
| open_now | No | When true, return only places open at the current local time (computed server-side from their opening hours). | |
| attributes | No | Amenity slugs a place must ALL have, e.g. ["wifi","outdoor-seating"]. Common slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free. | |
| neighborhood | No | Filter by neighborhood name. Case-insensitive substring match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and details key behaviors: accent-insensitive and typo-tolerant matching, ranking by relevance, filter semantics (open_now computed server-side, attributes ALL must match), result structure (open_now boolean, attributes array, delivery links, hours). This is thorough.
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 moderately long but well-organized: opens with purpose, then details search behavior, then filters, then result structure. Every sentence adds information; no redundancy. Could be slightly more concise on result details but still 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 no output schema, the description sufficiently explains the return format (open_now, attributes, delivery, rating, hours). All 6 parameters are covered. Complexity is moderate, and the description provides adequate completeness for an agent to understand inputs and outputs.
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 beyond schema: e.g., 'q' is typo-tolerant, 'open_now' computed server-side, 'attributes' ALL must match, and common amenity slugs. This enriches understanding beyond the schema's type/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 clearly states the tool searches for places (restaurants, cafes, shops) in a neighborhood, specifying the verb and resource. It distinguishes from siblings like 'get_place' and 'search_dishes' implicitly through scope, but doesn't explicitly differentiate.
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 the tool's functionality and filters, but doesn't explicitly state when to use this tool vs. siblings like 'get_place' for specific details or 'search_dishes' for dish-level queries. Usage context is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_formAInspectSubmit a form on behalf of the user (Wix Forms). Call list_forms first to get the formId and field keys. Returns a submissionId on success.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Key-value pairs matching the field keys from list_forms. Example: { "field_1": "João", "field_2": "joao@email.com" } | |
| formId | Yes | Form ID from list_forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a write operation (submission) and the return value, but does not disclose authentication needs, rate limits, or potential side effects. Adequate for a simple submission tool.
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 long, front-loading the purpose and then giving essential usage instructions. Every sentence adds necessary information 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 the tool's low complexity (2 required params, no enums, no output schema), the description covers the primary workflow (prerequisite call, what it returns). It lacks details on error handling or response format but is sufficient for the intended use.
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 already well described. The description adds value by reinforcing the prerequisite (list_forms) and providing an example of field key-value pairs, which helps the agent understand the dynamic nature of the fields parameter.
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 submits a form on behalf of the user specifically for Wix Forms. It identifies the resource (form) and action (submit), and distinguishes from sibling tools like list_forms, which is a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call list_forms first to obtain formId and field keys, providing clear prerequisite context. Also states it returns a submissionId. Does not mention when to avoid using the tool, but for a single-purpose tool this is minor.
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!