Gracie Barra Jiu-Jitsu — directory of martial arts schools, classes, instructors, ranks, and events.
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.3/5 across 28 of 28 tools scored. Lowest: 3.4/5.
Each tool targets a distinct resource and action. Even similar operations like create_booking, request_reservation, reserve_event_tickets, and rsvp_event are clearly differentiated by their descriptions and the entities they handle (bookable services, restaurant tables, paid events, free events). No two tools appear to do the same thing.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., create_booking, get_availability, list_events, search_places). This uniform convention makes the tool set predictable and easy for an agent to understand and select from.
With 28 tools, the set is relatively large, exceeding the typical well-scoped range of 3-15. While each tool serves a specific purpose within the neighborhood directory domain, the count feels heavy and may overwhelm simple use cases. A reduction or grouping could improve coherence.
The tool set covers a broad range of user-facing operations for a neighborhood directory: searching places, browsing menus, booking services, reserving tables and event tickets, listing products and events, retrieving reviews and FAQs, and submitting forms. Minor gaps exist (e.g., no cancellation or create_review tool), but the core workflows are well-supported.
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?
Discloses critical behavior: nothing is booked until payment, a checkout URL is returned, and the slot is re-validated server-side. With no annotations, this fully covers the 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?
Concise single paragraph with essential information front-loaded. Every sentence adds value; no repetition 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?
Covers prerequisites, return value description, and important caveats. With no output schema, it explains the checkout URL and user action needed. Adequate for a tool with nested parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond the schema by referencing related tools (get_availability, list_booking_services, search_places) and explaining how to obtain parameter values. The schema already has 100% coverage, but the description enriches this with context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it books an appointment slot and specifies the Wix Bookings context. Distinguishes from siblings like get_availability and create_checkout by noting the workflow and that payment is required separately.
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 get_availability immediately before, warns that a taken slot is rejected, and tells the user to open the returned checkout URL. Also notes that email is not verified at this step.
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?
Discloses that no login is required on the AI side, implying a user-driven action. No annotations, so description provides needed 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?
Single sentence, front-loaded with action and scope, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value description (presumably a URL) and lack of explicit link to list_products as prerequisite, but sufficient 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?
Schema covers 100% with descriptions, description adds no extra parameter detail beyond overall context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a direct checkout URL for store products, specific verb and resource, distinguishes from siblings like 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?
Clear context that it's for creating checkout URLs, but no explicit alternatives 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.
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 provided, so description carries full burden. Discloses timezone behavior (slots returned in venue's timezone). Could mention pagination or result structure, but current disclosure is good for a read 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?
Two sentences, no redundancy. Key points about source, date format, and timezone are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description does not specify return format, which may leave agent uncertain. However, core functionality and usage are complete. Sibling tools list is large but description sufficiently differentiates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description adds context: source of serviceId, date format reinforcement, place_slug consistency requirement. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get available time slots', resource 'bookable service', and specific constraints (date, venue). Distinguishes from sibling tools like list_booking_services and create_booking by focusing on 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?
Explicitly tells when to use: pass serviceId from list_booking_services, date in YYYY-MM-DD, same place_slug. Warns about timezone behavior. No exclusion statements but sufficient guidance.
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?
With no annotations provided, the description discloses return contents (ticket names, prices, sale status, availability count). It implies a read-only operation without side effects, which is appropriate. 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 concise sentences that front-load the purpose, then provide usage guidance and return info. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, parameter source, and return content. It could mention potential errors or authentication, but the completeness is adequate given low 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?
Schema description coverage is 100% with a single parameter event_slug. The description repeats that the slug comes from list_events, adding no new detail beyond the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets ticket types and prices for a specific Wix Events event. It distinguishes this from sibling tools that handle bookings, checkouts, etc., by specifying the exact resource (ticket info) and context (Wix 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?
Description instructs the agent to pass the event slug from list_events, providing a clear prerequisite. While it does not explicitly state when not to use or compare alternatives, the context is sufficient for a simple retrieval tool.
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 carries the full burden. It clearly indicates a read operation returning specific details (program name, points currency, tier structure). It does not mention destructive behavior or auth requirements, but given the zero-parameter read-only nature, this is acceptable.
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 then detailing return fields. Every sentence adds value 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 no output schema, the description sufficiently explains return values. It covers the key aspects of the tool (scope, data returned). Minor gap: does not mention if authentication is required, but for a read-only tool with no params, this is a minor omission.
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?
There are zero parameters, and schema description coverage is 100% (empty). The description adds meaning by specifying the return fields and context (site-specific loyalty program), which is the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('loyalty/rewards program details for this site (Wix Loyalty)'), and explicitly lists return fields (program name, points currency name, tier structure). It clearly distinguishes from sibling tools like get_site_info, which would return broader site 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?
The description implies usage for retrieving loyalty program details. While it does not explicitly state when not to use it or name alternatives, the context (0 parameters, specific purpose) makes it clear that this is the tool for loyalty info, and no sibling tool overlaps directly.
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?
No annotations provided. The description correctly identifies a read operation and lists returned data. It does not mention permissions or edge cases, but for a simple read, the behavior is transparent enough.
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 listing many fields, which is efficient but slightly dense. It could be split for readability, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly enumerates the response contents (opening hours, open_now, attributes, delivery links, ratings, address, neighborhood). This provides sufficient context for the agent to use 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 single parameter 'slug' is well-described in the schema (100% coverage). The description reiterates 'by its URL slug' without adding new semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details for a specific place by its URL slug, listing included fields. This distinguishes it from sibling tools like search_places (searching) and get_restaurant_menus (menus only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a slug and need comprehensive place data. It does not explicitly exclude alternatives, but the context of siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsBInspectGet 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?
No annotations exist, so the description must fully disclose behavior. It does not mention whether the tool is read-only, requires authentication, or any other side effects. Only the return fields are listed.
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 that are front-loaded with the core purpose. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description is mostly complete, mentioning the return fields. However, it lacks behavioral context such as authentication requirements, which slightly reduces 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?
The input schema covers the only parameter 'limit' with a description, so the description adds no new semantic meaning beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'published reviews', specifies the app context 'Wix Reviews', and lists the return fields (reviewer name, rating, title, content). This differentiates it from sibling tools that handle other resources.
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 the many sibling tools. Explicit context for selection is missing.
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?
No annotations are provided, so the description carries the full burden. It lists the returned fields but does not explicitly confirm it is a read-only operation or disclose any side effects. This is adequate for a simple info tool but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose. 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?
No output schema, but the description lists the returned fields (name, locale, domain, description, canonical URLs, local time, weather). For a simple, parameterless tool, this is complete and leaves no ambiguity.
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%. The description adds context about what is returned, which is sufficient given no parameters to explain.
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 returns basic information about the neighborhood directory, including specific fields like local time and weather. It distinguishes itself from siblings which are focused on bookings, events, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions use cases: 'Use this for any "what time is it there" or "what's the weather like" context.' This provides clear guidance on when to use this tool.
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?
No annotations provided, so description carries full burden. It discloses return fields but omits ordering, pagination behavior, or whether the operation is read-only (likely safe but not stated).
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 efficiently convey purpose and return data, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately covers purpose, parameters, and return fields. Missing ordering and pagination details, but acceptable for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds overall context but does not enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists recent published blog posts for a specific site (Wix Blog) and enumerates returned fields, distinguishing it from sibling tools like list_products or 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?
Description implies usage context (blog posts) but does not explicitly state when to use or avoid this tool, nor provide alternatives among siblings.
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?
No annotations are provided, so the description carries full burden. It discloses that services are listed for all venues, including those without online booking, and explains the bookableViaMcp flag: when false, id is null and create_booking cannot be used. It also lists return fields (name, description, price, duration, bookableViaMcp).
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 and front-loaded with the main purpose. Each sentence adds necessary detail, though the explanation of bookableViaMcp and alternatives slightly extends the length. It could be tightened 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?
Given no output schema, the description adequately covers return fields and key behaviors. It does not mention pagination or ordering, but the tool is straightforward. The critical nuance about bookableViaMcp is well explained, making it complete enough for correct agent 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% with a clear description for place_slug. The description adds context about the effect of omitting it and the relationship to create_booking, but the schema already provides the source and recommendation. The added value is moderate, warranting a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists a venue's services with price and duration. It distinguishes itself from siblings by specifying that it returns services for a specific venue when place_slug is provided, contrasting with the directory's own services when omitted.
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 guidance: use place_slug from search_places to get venue services (recommended for booking), and explains that omitting it yields directory services (rarely useful). It also advises checking bookableViaMcp to determine if the service can be booked via create_booking.
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?
No annotations are provided, so the description carries the full burden. It discloses the return content (full taxonomy, localized labels, schema.org types, live place counts) and implies a read-only operation. This is sufficient for a parameterless, likely idempotent 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 a single, front-loaded sentence that conveys all necessary information without wasted words. Every part ('full category taxonomy', 'top-level groups', 'subcategories', 'localized labels', 'schema.org types', 'live place counts') adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description fully explains what the tool does and returns. It covers all relevant aspects for an agent to correctly invoke the tool, 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 input schema has 0 parameters, so the description inherently provides all parameter-related meaning. According to guidelines, baseline is 4 for zero parameters, and the description adds value by explaining what the tool returns without needing parameter details.
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 with specific details (top-level groups, subcategories, localized labels, schema.org types, live place counts). It distinguishes itself from sibling tools like list_products or list_events, as no other sibling focuses on categories.
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 category taxonomy but does not provide explicit guidance on when to use this tool over alternatives or when not to use it. There is no mention of prerequisites or exclusions, making the guidance minimal.
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 mentions that events within 7 days include a weatherForecast and that the 'agora' filter is resolved live, which adds behavioral context. However, it does not state whether the tool is read-only, auth requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the main purpose ('List upcoming events...'), then adding key behavioral details. Every sentence contributes 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 no output schema, the description covers output fields (date, venue, price, URL) and special case (weatherForecast for next 7 days). It explains filter values but does not mention pagination or default limit. Overall, it provides sufficient context for a list 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 description coverage is 100%, so baseline is 3. The description adds meaning for the `filter` parameter beyond the enum list, explaining 'agora' as 'on stage at this exact moment' and contrasting with cached pages. The other parameters (limit, upcoming_only) are not elaborated, but the added context for one param elevates the score.
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 resource ('upcoming events in this neighborhood'), and specifies the returned fields (date, venue, price, URL). This differentiates it from sibling tools like list_movies or list_blog_posts 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 provides guidance on using the filter parameter (e.g., 'filter: "agora"' answers 'what can I go to right now'), but does not explicitly compare this tool to alternatives or state when not to use it. The context is implied but not made explicit.
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?
Description fully discloses behavior: returns all FAQs, grouped by category. No annotations, but the description alone provides sufficient transparency for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. Front-loads the core purpose and adds context for usage. No redundant or extraneous 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 absence of parameters, annotations, and output schema, the description fully covers what the tool does and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds no parameter info but is not needed. Baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves all FAQ questions and answers for the site, grouped by category. Distinguishes from sibling list tools by specifying the content type and use case.
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 recommends using this tool to answer common site questions like hours and policies. No explicit when-not-to-use, but the simplicity of the tool makes that acceptable.
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?
With no annotations, the description discloses return values (name, ID, field definitions) and implies read-only behavior. It doesn't mention rate limits or permissions, but for a simple list 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?
Two sentences, front-loaded with purpose. Efficient but slightly dense; could be split for readability, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete: explains what it does, what it returns, and when to use it in relation to a sibling 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?
There are zero parameters, so schema coverage is 100%. Baseline is 4 as per instructions; description adds no extra param info, but none needed.
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 contact/signup forms on Wix Forms, specifying the verb 'List' and resource 'forms'. It distinguishes itself from sibling 'submit_form' by indicating it's a preparatory step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool before 'submit_form' to discover fields to fill, providing clear context and alternative.
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?
With no annotations, description carries full burden. It states guides are 'ranked' and have 'editorial notes' but provides no details on ordering criteria, pagination behavior, or access requirements.
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: one states action/resource, the second adds usage context. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter. Description explains what is returned but lacks details on sorting criteria or pagination beyond the limit parameter. Adequate but could be improved.
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 the single parameter (limit) with default and max values. Description does not add extra semantics beyond schema, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List', resource 'guides', and specifies it is for curated editorial guides with editorial notes, differentiating it from sibling tools like list_blog_posts or list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is the 'best source for best X in this neighborhood questions,' guiding when to use it. Does not mention 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.
list_offersAInspectList 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 are provided, so the description bears full responsibility. It describes the return fields and the FLASH offer nuance, but does not disclose whether the operation is read-only, destructive, or any side effects. The behavior is implied but not explicit.
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, front-loaded with the core purpose, then details return fields, and highlights a special case. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return fields well and mentions active offers and FLASH specifics. It lacks details on pagination, sorting, or default behavior, but for a simple list tool this is sufficient.
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 both parameters having descriptions. The description adds context for the 'kind' parameter by explaining FLASH offers have a countdown deadline, but this adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists active promotions and deals in a neighborhood directory, and specifies the returned fields (discount label, promo code, etc.). This distinguishes it clearly from sibling tools like list_events 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 implies usage for browsing deals but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The context is adequate but lacks direct comparison.
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, but the description clearly indicates it's a read operation (lists plans) and details the return fields (name, description, price, billing cycle, perks, checkout URL). Lacks mention of authentication or rate limits, but those are reasonable omissions for a listing 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?
Concise single paragraph. First sentence states purpose, then parameter guidance, then return fields. No unnecessary words, front-loaded, every sentence serves a 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?
For a simple listing tool with one optional parameter, the description fully covers what the tool does, when to use it, and what it returns. No output schema is provided, but the description lists return fields, compensating adequately.
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 one parameter, place_slug, is well-described in both schema and description. The description adds context: strongly recommended, explains the consequence of omission, and mentions its source. Adds significant value 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 specifically states it lists membership or subscription plans (Wix Pricing Plans), distinguishes between listing for a specific venue vs the directory's own plans, and differentiates from sibling tools which are not about pricing 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?
Explicitly says when to use place_slug (for venue plans, which is almost always) and when not to (directory's own plans, rare). Provides source for place_slug (search_places). No ambiguity.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions returned fields but lacks detail on pagination, ordering, side effects, or authentication requirements. For a read-only list, this is adequate but not 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?
Two concise sentences with the verb 'List' upfront. Every word adds value; no redundancy or irrelevant 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, the description should explain return values, which it does partially. However, it omits pagination behavior, default limit, and ordering, leaving some gaps for a list 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 both parameters described. The description does not add new semantics beyond the schema, so a 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 lists products in a Wix Stores context, specifying returned fields (name, price, stock status, product type). It distinguishes from sibling list tools by resource type.
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 listing products but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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 are provided, so the description carries the full burden. It discloses the return fields (name, profile URL, category, metadata) and the kind of profiles listed, but it does not mention pagination, ordering, idempotency, or authentication requirements. More behavioral context would be beneficial.
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-loaded with the tool's purpose, and contains zero fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a single optional parameter and no output schema, the description adequately specifies the return fields and the scope. It could mention if the list is exhaustive or paginated, but overall it provides sufficient context for a simple query.
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% (the only parameter 'limit' is described in the schema). The description adds no additional meaning beyond what the schema already provides, so a 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 lists solo service-provider profiles, specifically those without a fixed physical location, with examples (dog walkers, tutors). This verb+resource pairing is precise and distinguishes it from sibling tools like list_places 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 implies the tool is for solo providers without a fixed location but does not explicitly state when to use it over alternatives or mention any exclusions. No direct comparison to siblings is provided; the context must be inferred.
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 provided, so description carries full burden. It clearly states the restaurant is not notified until email confirmation, link expires in 24h, and the link is not returned to the assistant. All behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded. Every sentence is necessary and informative. No fluff or 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 7 parameters, no output schema, and no annotations, the description fully explains the workflow, email process, and return behavior. It is complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds meaning: specifies email is the guest's own for confirmation, and reinforces request nature. This adds value 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 states 'Request a table at a restaurant' with clear verb+resource. It explicitly distinguishes from a confirmed booking, differentiating 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 when-to-use guidance: informs the agent to tell the user to check their inbox, use a real address, and explains the request is not a confirmed booking. It implies alternatives like 'create_booking' for immediate confirmation.
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 carries the full burden. It discloses that the hold is temporary, that tickets are not reserved until checkout is completed via the URL, and that the hold expires automatically. It also states the maximum number of tickets and ticket types. No contradictory information.
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 main purpose and return value. Every sentence adds essential information: the temporary hold, no payment, expiration, limits, and when not to use. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clarifies the return value (checkout URL) and explains the next step (human completes checkout). It addresses constraints (direct-sold events, max limits) and alternative tools for external events. The tool is simple with 2 params, and the description fully covers its 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 baseline is 3. The description adds value by explaining the max limits on the 'tickets' parameter (max 10 tickets and 10 ticket types) and specifying that 'ticketDefinitionId' comes from get_event_tickets. This provides context beyond the schema's property 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 the tool holds tickets temporarily and returns a checkout URL. It specifies the verb 'hold', the resource 'tickets for an event', and the return value. It distinguishes from siblings like create_checkout and get_event_tickets by explaining the hold is separate from checkout and providing alternatives for external 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 explicitly tells when to use this tool (for events sold directly through this site) and when not to (for external events from Sympla, Ingresse, Sesc, which should use their own ticketUrl). It also highlights that the hold is temporary and nothing is paid, guiding the agent on the expected behavior.
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?
With no annotations, the description discloses all critical behaviors: no one on guest list, confirmation email, click-to-confirm, 24-hour expiry, and that the confirmation link is not returned to the caller. This is 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?
Two sentences, front-loaded with the action, then critical workflow details. Every word is necessary; 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 no output schema and four parameters, the description covers the behavioral context well (what happens after calling). It explains the asynchronous confirmation process, but does not mention return values (though likely success/failure is implied). Still, it is sufficient for an agent to understand and use the 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%, so baseline is 3. The description adds value by explaining 'email' is the guest's own (where confirmation is sent) and 'event_slug' comes from list_events. This clarifies usage 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?
Clearly states 'RSVP to a free event on this site (Wix Events)'. Distinguishes from siblings like reserve_event_tickets by specifying free events and the unique confirmation email workflow.
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?
Describes the full RSVP workflow (email confirmation, 24-hour expiry) and instructs the user to check their inbox and use a real address. Does not explicitly list when not to use, but the context implies for paid tickets use reserve_event_tickets.
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?
Describes that the search spans all restaurants, groups by dish, and returns price, description, dietary labels, and place URL. Since no annotations exist, the description carries full burden and does so well, though it doesn't mention rate limits or authentication (likely standard).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: first states purpose, second provides details, behavior, and usage. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description explains return fields and both parameter behaviors. It covers the main use case completely, with no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds examples for query, explains that omitting it lists top dishes, and clarifies that results are grouped by dish—adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds which restaurants serve a dish, with a specific verb ('find', 'search') and resource ('dishes on menus across all restaurants'). It distinguishes from sibling tools like get_restaurant_menus by covering all restaurants site-wide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for any "where can I eat X" question' and explains behavior when query is omitted. Could be improved by mentioning alternatives (e.g., get_restaurant_menus for a specific restaurant), but current guidance is clear for the main use.
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 provided, the description carries full burden and thoroughly discloses behavior: accent-insensitive and typo-tolerant matching, relevance ranking, server-side open_now computation, attribute matching (all must match), and detailed result structure including precomputed fields and delivery links.
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 fairly long but well-structured: purpose first, then matching behavior, filter composition, result format, and amenity slugs. Every sentence adds information, though minor trimming could improve conciseness.
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 tool has 6 parameters, no output schema, but the description thoroughly explains all parameters and the result format. It also covers edge cases like typo-tolerance and multi-condition filtering, making it complete for a search 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 description coverage is 100% (baseline 3), but the description adds substantial value: explains q's typo-tolerance with examples, clarifies open_now filter behavior, details attribute matching logic and common slugs, and specifies substring matching for category and neighborhood. This goes well 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 clearly states the tool searches for places (restaurants, cafes, shops) in a neighborhood, using a specific verb and resource. It distinguishes from siblings like search_dishes and get_place by focusing on general place search with multiple filters.
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 multi-condition queries and lists filters, but does not explicitly exclude alternatives or provide when-not guidance. The context is clear, but no comparisons to similar search tools are given.
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?
No annotations provided, so the description carries the full burden. It discloses that the tool submits a form (write operation), requires prior data, and returns a submissionId. It lacks details on error handling, idempotency, or permissions, which would enhance 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 extremely concise with two sentences, no unnecessary words. It front-loads the purpose and efficiently provides essential 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?
Given the tool has 2 parameters and no output schema, the description adequately covers input requirements, preparation steps, and expected outcome. It could mention potential failure modes, but overall it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds value by specifying the return value (submissionId) and the prerequisite of list_forms, which is not in the schema. This slightly exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Submit a form on behalf of the user (Wix Forms)', using a specific verb and resource. It distinguishes from sibling tools by being uniquely associated with Wix Forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call list_forms first to get the formId and field keys', providing a clear prerequisite. However, it does not mention when not to use this tool or any alternatives, though the specific context suffices.
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!