Vila Madalena — 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 28 of 28 tools scored. Lowest: 3.3/5.
Each tool targets a distinct resource or action: search, get, list, create, submit, etc. Potential overlaps like create_booking vs request_reservation vs reserve_event_tickets are clarified by descriptions distinguishing appointment booking, restaurant table requests, and event ticket holds.
All tool names follow a consistent verb_noun pattern with underscores (e.g., list_services, get_place, create_booking). No mixing of styles, and verbs accurately describe the operation.
28 tools is slightly above typical range but well-justified given the breadth of the site (places, events, movies, food, booking, forms, etc.). Each tool serves a clear purpose without feeling bloated.
Covers major read and action scenarios for a neighborhood directory. Missing update/delete operations for places and bookings, but those are likely not exposed via this API. Minor gaps like canceling reservations are handled externally.
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 are provided, so the description must cover behavioral traits. It discloses that the tool returns a checkout URL, that the booking is not confirmed until payment, that email is not verified, and that slot re-validation occurs server-side. This is substantial context, though it could mention whether the operation is idempotent or any side effects beyond the checkout flow.
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 (3 sentences) yet packed with essential information. It front-loads the main purpose and immediately highlights the key behavioral caveat (payment required). Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters including a nested object, no output schema), the description fully covers the return value (checkout URL), prerequisites (get_availability), and behavioral caveats (no booking until payment, email not verified). It leaves no major gaps for a safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds critical nuance: email is not verified and that startDate/endDate must exactly match get_availability output. This goes beyond the schema's basic descriptions. The note about phone formatting ('Any formatting is accepted') is also helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Book an appointment slot'), resource ('appointment slot at a venue'), and context ('Wix Bookings'). It distinguishes itself by emphasizing that nothing is booked until payment, contrasting with potential sibling tools like create_checkout.
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: call get_availability immediately before, and informs the agent to tell the user about the checkout URL. However, it does not explicitly state when not to use this tool or list direct alternatives, though it implicitly suggests that get_availability is a prerequisite.
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?
With no annotations provided, the description carries the full burden. It adds the useful behavioral context that no AI agent login is required and that the user completes payment on the site. However, it does not disclose potential side effects like order creation or URL expiration.
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, consisting of two sentences with no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no other structured data, the description is fairly complete. It explains the tool's purpose, user experience, and agent involvement. It could mention the output (the URL) or prerequisites, but the sibling list_products fills the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'items', so the schema already documents it well. The description adds minimal value beyond the schema, merely echoing 'one or more store products'.
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 ('Create a direct checkout URL') and the resource ('one or more store products (Wix Stores)'). It distinguishes from siblings like list_products (which lists products) and create_booking (which handles bookings).
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 user flow ('The user clicks the URL to complete payment on the site') and a key constraint ('no login required on the AI agent side'). It implies when to use (to initiate a purchase for store products) but does not explicitly state when not to use or compare to alternatives.
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?
Discloses a key behavioral trait: returned slot times are in the venue's timezone, not necessarily the directory's. No annotations provided, so description carries full burden. 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 sentences, front-loaded with purpose, followed by critical usage details. 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?
Covers usage and a behavioral nuance, but does not describe the return structure of available time slots. Given moderate complexity (3 params, no output schema), the description is adequate but incomplete.
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?
Parameters are fully described in schema (100% coverage). Description adds value by clarifying the cross-tool dependency (serviceId from list_booking_services) and format hint for date (YYYY-MM-DD).
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 retrieves available time slots for a Wix Bookings service on a given date. Specifies the source of serviceId (list_booking_services), which distinguishes 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?
Provides clear usage instructions: need serviceId, date in YYYY-MM-DD, and same place_slug. Warns about timezone behavior. Does not explicitly state when not to use or alternatives, but context is implied.
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?
Describes return data but no behavioral details like error handling or rate limits; adequate for a read-only tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, 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?
Complete for a simple tool: input, output, and linkage to prerequisite tool are all covered.
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 already documents parameter; description adds value by specifying parameter origin (list_events).
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 gets ticket types and prices for a specific event, referencing the sibling tool list_events and specifying the data returned.
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 pass the event slug from list_events, guiding the agent on prerequisite usage.
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 states the tool returns program details, implying a read operation, but does not disclose data freshness, authorization requirements, or side effects. Adequate but could add more behavioral context.
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, front-loaded with the action and resource, and includes specific return details. 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?
No output schema is provided, so the description must describe return values. It lists program name, points currency name, and tier structure, which is sufficient for a simple info tool. Could mention whether data is site-wide or per-user, but still 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?
There are no parameters, so the baseline is 4. The description adds value by specifying what is returned, compensating for the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves loyalty/rewards program details for the site, listing specific return fields (program name, points currency name, tier structure). This distinguishes it from sibling tools which focus on other domains like bookings and 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 sibling tools are unrelated, so an agent can infer it's for loyalty info, but there is no mention of prerequisites or context like site type or user role.
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, so description carries full burden. It discloses the tool returns detailed place info without side effects or auth requirements, which is adequate. However, it does not mention rate limits or error 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?
The description is one sentence that efficiently lists the returned fields. It is reasonably concise, though slightly verbose in enumerating all fields.
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 one parameter and no output schema, the description provides sufficient context about the return value. Lacks mention of error cases, but for a simple get tool this is acceptable.
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 the slug parameter. The tool description does not add additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details for a specific place by URL slug, listing included fields (opening hours, open_now, attributes, delivery, ratings, address, neighborhood). This distinguishes it from search_places and other siblings.
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 implicitly indicates when to use (when you have a slug and need detailed info) but does not explicitly state when not to use or mention alternatives like search_places.
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 are provided, and the description only states 'Get published reviews' with no additional behavioral context (e.g., read-only nature, pagination, authorization needs). The limit parameter is documented in the schema but not elaborated in the description.
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, front-loading the purpose. However, it could be improved by adding a brief note on ordering or filtering without sacrificing 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?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is adequate but minimal. It lacks information about ordering, default behavior, and any site-specific context that could help the agent use it effectively.
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% for the single parameter 'limit', which already includes default and max values. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('published reviews'), and specifies the fields returned ('reviewer name, rating, title, and content'). It distinguishes itself from sibling tools by focusing specifically on reviews.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The name and description imply it is for fetching reviews, but no when-not or alternative tools are cited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_showtimesAInspectGet showtimes for a specific movie at cinemas in this neighborhood, for a given date. Returns each cinema with session times, format (e.g. "Laser", "3D"), and language (Dublado/Legendado). Requires movies_enabled on this site.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format. Defaults to today (BRT). | |
| movie_slug | Yes | Movie slug from list_movies (e.g. "o-corvo-1016084"). |
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 return details (cinemas, session times, format, language) and the prerequisite, but does not describe error conditions or response structure.
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: first clearly states purpose, second adds return details and a prerequisite. No redundant information, front-loaded with key actions.
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 tool with 2 parameters and no output schema, the description covers purpose, parameter context, and prerequisite. It lacks details on response limits or examples, but is still fairly 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%, but the description adds value by clarifying the date format and default (BRT) and specifying that movie_slug comes from list_movies, which is 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 'Get showtimes for a specific movie at cinemas in this neighborhood, for a given date.' It specifies the verb, resource, and key constraints, distinguishing it from sibling tools like list_movies.
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 mentions the prerequisite 'Requires movies_enabled on this site' and implicitly indicates usage for querying showtimes, but does not explicitly state when to use versus 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_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 conveys the tool is a read-only operation by stating it returns information, and adds context that the data includes real-time elements (local time and weather), implying safe, idempotent behavior. However, it does not explicitly discuss authentication or rate limits, keeping it from a top score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, each serving a distinct purpose: the first enumerates the returned information, the second gives concrete use cases. There is no redundancy, and the key points are front-loaded. Every word 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?
Given no output schema and zero parameters, the description must fully explain the tool's return value. It lists all evident fields (name, locale, domain, description, canonical URLs, local time, weather) and provides usage guidance. This is complete information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (vacuously). The description adds value by detailing what the output contains, which for a parameterless tool is essential context. According to guidelines, 0 parameters yields a baseline of 4, and the description meets that expectation.
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 basic information about a neighborhood directory, listing specific content (name, locale, domain, description, canonical URLs, local time, weather). The verb 'returns' and detailed resource make the purpose precise and distinguishable from siblings like get_place or get_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool for 'what time is it there' or 'what's the weather like' contexts, providing clear usage guidance. While it doesn't mention when not to use it, the context is sufficiently specific to avoid misuse.
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?
With no annotations provided, the description carries the full burden. It indicates the tool is read-only and returns specific fields, which is helpful. However, it does not mention any behavioral traits like authentication requirements, rate limits, or edge cases (e.g., empty results). The description is accurate but minimally transparent beyond the return format.
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: two sentences. The first sentence states the purpose, and the second lists the return fields. There is no redundant or extraneous text. 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 the tool's simplicity (2 optional parameters, no output schema), the description provides sufficient context: it specifies the return fields and implies sorting by recency. It lacks explicit mention of default order or pagination behavior, but the limit parameter addresses quantity. Overall, it is complete enough for an agent to use 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 already has 100% coverage with descriptions for both parameters (limit and category). The tool description adds no further semantic information about the parameters, so it does not improve upon 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 action (list) and resource (recent published blog posts for this site, Wix Blog). It specifies exactly what the tool does and implicitly distinguishes it from sibling tools like list_events or list_products, which target different content types.
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 when to use this tool (to list blog posts) but provides no explicit guidance on when not to use it or how it compares to alternative tools like search_dishes or list_products. The context is clear but lacks exclusionary or comparative direction.
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 provided, the description fully covers behavioral traits: it reveals that services are listed for all venues, including those without online booking, explains the bookableViaMcp flag meaning, and states that when false, id is null and booking is not possible via create_booking. This provides actionable guidance beyond the schema.
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 thorough and well-structured, with the core purpose upfront. Each sentence adds value, though it could be slightly more concise. No fluff, but the length is justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains what returns: name, description, price, duration, bookableViaMcp. It also covers edge cases (non-bookable venues) and provides alternative actions. The tool's two modes and integration with create_booking are well contextualized.
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 parameter place_slug. The description adds significant context: it explains the two behaviors (with/without place_slug), the source of place_slug from search_places, and the practical implications for booking. This goes well beyond the schema's brief 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 distinguishes between listing services for a specific venue (with place_slug) and the directory's own services (without), which sets it apart from sibling listing 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 explicitly states when to use each mode: pass place_slug from search_places for venue services (almost always), omit for directory services (rarely available). It also notes that only venue services work with create_booking, and explains how to handle non-bookable services by directing 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 carries the burden of transparency. It states the tool returns data, indicating a read operation, but does not disclose any behavioral traits such as caching, freshness guarantees, or side effects. The description is adequate but minimal.
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 is concise and well-structured. It packs all relevant information (full taxonomy, key elements) without any fluff or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is fully complete. It explains what the tool returns (full category taxonomy with specific components), leaving no ambiguity about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to describe. Baseline for zero parameters is 4, as the description adds no value beyond the schema but is not required to. The description does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: returning the full category taxonomy of the directory site. It specifies the exact contents (top-level groups, subcategories, localized labels, schema.org types, live place counts), which distinguishes it from sibling list_* tools that return different entities.
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 the full category taxonomy, but it does not explicitly state when to use this tool versus alternatives like other list_* tools or when not to use it. As a simple list tool, the implied usage is clear, but explicit guidance is absent.
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 provided, so description carries the full burden. It discloses that events within 7 days include weatherForecast and that 'agora' filter is resolved live. For a read-only list tool, this is good transparency, though it omits mention of rate limits or authentication.
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 core purpose. Every sentence adds unique value, no filler. Efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, description covers main behavior (listing events, weather forecast, live filter). Lacks details on pagination, error handling, or empty results, but still reasonably complete 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%, so baseline is 3. Description adds significant value by explaining the special behavior of 'filter: agora' and the weather forecast condition, which are not fully captured in 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?
Description uses specific verb 'List upcoming events' and specifies resource 'neighborhood'. It includes additional context (weather forecast for events within 7 days) that makes the tool's purpose very clear. While it does not explicitly distinguish from siblings, the domain is distinct enough.
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 provides guidance on using the 'filter' parameter, especially 'agora' for real-time results, but does not compare to sibling tools or state when to use this tool vs alternatives. No explicit 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_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, description implies read-only behavior via 'Get'. Discloses grouping and scope (all FAQs). Lacks explicit safety info but sufficient for a simple 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: first states action and result, second gives usage guidance. Front-loaded, 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?
Tool is simple (no params, no output schema, no annotations). Description fully covers what it does, what it returns, and when to use it.
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, baseline 4 per rule. Description adds no param info but also unnecessary since schema is trivial.
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?
Specific verb 'Get' with resource 'all FAQ questions and answers' and grouping detail 'Grouped by category'. Clearly distinguishes from siblings which are for other resources like events, products, 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?
Explicitly states when to use: 'Use this to answer common questions about the site — opening hours, parking, policies, etc.' Provides clear context, though does not mention when not to use or alternative tools.
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 must disclose behavioral traits. It states the tool 'List available forms' and describes the return, implying a read-only operation. However, it lacks details on permissions, side effects, or whether forms are site-wide, resulting in adequate but minimal 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?
Two sentences: first defines purpose and return, second gives usage guidance. No extraneous words or repetition. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description sufficiently explains what is returned (form name, ID, field definitions). It could mention whether forms are site-wide or per-page, but overall it's complete enough for effective 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?
The input schema has no parameters, and schema description coverage is 100%. With zero parameters, the baseline is 4, and the description doesn't need to add param info. It correctly focuses on the output and usage.
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 available contact/signup forms on this site (Wix Forms)', identifying the verb (list), resource (forms), and context. It also specifies the returned data (name, ID, field definitions) and distinguishes 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?
The description explicitly advises 'Use before submit_form to discover which fields to fill', providing clear usage context. While it doesn't list when not to use, the instruction is sufficiently clear for a simple tool.
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 are provided, so the description bears full responsibility. It states the tool lists guides but does not disclose whether it is read-only, requires authentication, or any other behavioral traits. It 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?
The description is two sentences with no waste. The first sentence defines the tool and the second provides a use case, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers purpose, context, and use case. It could mention potential errors or scope but is largely 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% since the only parameter 'limit' is fully described in the schema. The description adds no additional parameter information beyond the schema, 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 explicitly states 'List curated editorial guides' and clarifies they are 'best of' lists with editorial notes. This clearly distinguishes from sibling tools like list_blog_posts 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?
The description provides a concrete use case: 'best source for 'best X in this neighborhood' questions.' However, it does not explicitly state when to avoid this tool or name alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_moviesAInspectList movies available in this neighborhood (only on sites with movies_enabled). Returns now-showing films (with actual showtimes at local cinemas), coming-soon films, and streaming availability. Includes title, genres, TMDB rating, runtime, and detail URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max movies to return (default 20, max 100). | |
| status | No | Filter by status. "now_showing" = films with upcoming showtimes at local cinemas. "coming_soon" = unreleased or not yet playing locally. "streaming" = available on streaming services in Brazil. "all" = full catalog (default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains return data (title, genres, rating, runtime, URL) and categories, but does not disclose behavior like ordering or pagination. It 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?
The description is two sentences, front-loaded with the main action and constraints. Every word adds value, with no wasted text.
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 lists return fields and categories. It is mostly complete for a list tool, though ordering and pagination beyond limit are not specified.
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 clear parameter descriptions. The description adds context about the environment ('only on sites with movies_enabled') and clarifies that now-showing includes actual showtimes, which goes 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 it lists movies available in the neighborhood, specifying categories (now-showing, coming-soon, streaming) and return fields. However, it does not explicitly differentiate from sibling tools like get_showtimes 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?
The description mentions the tool works only on sites with movies_enabled but provides no guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 carries full burden. It discloses that the tool returns certain fields and that FLASH offers have a countdown, but does not clarify behavioral traits (e.g., read-only, idempotent, potential side effects, authentication needs). It focuses on output structure rather than 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?
Two sentences, front-loaded with action and scope. No redundant words; every sentence adds value by explaining return fields and special FLASH behavior.
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 two optional params, the description covers the core functionality well. However, it omits mention of pagination, sorting, or default limits (though schema mentions default 20, max 60). Missing these minor details prevents a higher score.
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 well-documented in the schema. The description adds marginal value by explaining FLASH offers have a countdown, but this is already implied by the enum description. No additional semantics 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?
The description clearly states the tool lists active promotions and deals, specifies the returned fields (discount label, promo code, CTA link, validity window, business), and distinguishes FLASH offers with a countdown. This is a specific verb+resource that differentiates from siblings 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 the tool is for listing active offers, but does not provide explicit guidance on when to use it vs alternatives (e.g., get_loyalty_info may overlap). No when-not-to-use or alternative tool references are given.
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 are provided, but the description fully discloses behavior: it describes the two modes, the typical use case, and the returned fields (name, description, price, billing cycle, perks, checkout URL). 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?
Three sentences are concise and front-loaded: first sentence states purpose, second gives usage guidance, third describes output. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, no output schema, and no annotations, the description is fully complete, covering parameter usage, return fields, and behavioral nuances.
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% and the description adds value beyond the schema by explaining why `place_slug` is strongly recommended and what happens without it, though the schema already includes a similar note.
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 membership or subscription plans (Wix Pricing Plans) and distinguishes between listing venue-specific plans vs. the directory's own plans, differentiating 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?
Explicitly advises using `place_slug` (from search_places) for venue plans in almost every case, and explains the alternative when omitted, providing clear guidance on when to use each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsBInspectList 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 provided, so description must cover behavior. It does not mention read-only nature, side effects, pagination details (though limit is in schema), or authentication requirements. Returns fields are listed but no default sort order or error conditions.
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 clear front-loading of action and resource. Efficient and no wasted words, though slightly lacking in structure (e.g., no bullet points for returned fields).
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 (two optional params, no output schema), the description adequately covers what the tool does and what it returns. No missing evident details.
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 both parameters with descriptions. The tool description adds no additional meaning beyond schema. Baseline of 3 is appropriate as schema does the heavy lifting.
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 products in this site's store (Wix Stores)' and specifies returned fields: name, price, stock status, and product type. It effectively distinguishes from sibling tools like list_blog_posts and list_booking_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No explicit prerequisites, limitations, or context for invocation.
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 full burden. It discloses returns fields but does not mention any side effects, authentication requirements, or rate limits. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no filler. 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, the description explains return fields (name, URL, category, metadata). It does not mention pagination or ordering, but the limit parameter partially addresses pagination. Overall, fairly complete 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%, and the description adds no extra meaning beyond the schema's 'limit' parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'solo service-provider profiles' and distinguishes from sibling list tools (e.g., list_booking_services, list_categories) by specifying the type of 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 when to use this tool (to fetch profiles of mobile businesses) but does not explicitly state when not to use it or mention alternatives. However, the context from sibling tool names makes the purpose clear.
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 discloses that the restaurant is not notified, confirmation email sent, link expires, and it's 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?
Concise and well-structured: first sentence states purpose, then critical behavioral caveats, then usage instructions. No superfluous text.
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?
Despite no output schema, the description fully explains the request lifecycle and what to expect, making it complete for agent usage.
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 behavioral nuance for email (ensure real address, link not returned to caller) beyond schema, justifying a 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 clearly states it requests a table, explicitly contrasts with a confirmed booking, and distinguishes 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?
Provides clear context: tell user to check inbox, use real address, link expires. Lacks explicit alternatives but context implies it.
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?
No annotations provided, so description carries full burden. Discloses that the hold is temporary, nothing is paid, hold expires automatically, and max limits. Lacks details on authentication or error behavior, but sufficient for a reservation 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?
Four sentences with no fluff. Front-loaded with purpose. Behavioral note in caps for emphasis. Limits and exclusions clearly stated. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers purpose, behavior, constraints, and exclusions. No missing critical information for an agent to use it 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?
Schema coverage is 100%, but description adds value by stating the max limits (10 tickets, 10 types) which are not in schema. Also clarifies that ticketDefinitionId comes from get_event_tickets and event_slug from list_events.
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?
Uses specific verb 'Hold' and resource 'tickets for an event sold through this site (Wix Events)'. Clearly distinguishes from siblings by noting it only works for direct events and mentions alternative 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?
Explicitly states when to use (events sold through this site) and when not to (external events, use the event's own ticketUrl). Provides max limits (10 tickets, 10 types). However, does not mention other sibling tools like create_booking or rsvp_event.
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 fully discloses the RSVP flow: a confirmation email is sent, link expires in 24 hours, the confirmation link is not returned, and the guest list starts empty. This covers all critical behavioral traits.
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: purpose, then critical usage notes. No fluff. Each sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 required params, no output schema), the description covers the key context: async RSVP, email usage, and user instruction. It doesn't detail return values, but the flow is clear enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with basic descriptions. The description adds value by explaining the email's role (confirmation sent there) and referencing list_events for the slug. It reinforces using a real address, going 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?
The description clearly states 'RSVP to a free event on this site (Wix Events)', using specific verb and resource. It distinguishes itself from siblings like reserve_event_tickets by focusing on free events and the confirmation email process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'NOBODY IS ON THE GUEST LIST YET', 'Tell the user to check their inbox', 'Use a real address...'. It implies when to use (free events) and what to expect, but does not explicitly mention alternatives among siblings.
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 every menu item, groups by dish, and returns price, description, dietary labels, and place URL. It also covers the omission case. Could mention ordering or pagination, but schema covers limit.
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 fluff, front-loaded with the core purpose. Every sentence adds necessary context. Excellent efficiency.
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 annotations and no output schema, the description is largely complete. It explains input, output (as example), and special cases. Small gap: doesn't mention default/max limit values, but those are in schema. Overall 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 descriptions for both parameters. The description adds value by explaining the omission behavior and providing a concrete example, which clarifies semantics 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 verb (search/find), the resource (dishes), and the scope (neighborhood restaurants). It distinguishes from siblings by explicitly targeting 'where can I eat X' queries, which sets it apart from search_places or get_restaurant_menus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use for 'where can I eat X' questions. It also explains the behavior when query is omitted (list top dishes). However, it does not explicitly state when not to use or mention alternative tools.
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?
No annotations provided, so the description carries full burden. It discloses accent-insensitive and typo-tolerant matching, ranking by relevance, and output details like precomputed 'open_now', 'attributes', and 'delivery' arrays. Missing mention of pagination or auth, but sufficient.
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 adequately sized, front-loaded with purpose, and every sentence provides useful information. It is well-structured but could be slightly more concise without losing detail.
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 no annotations, the description covers input behavior, filter usage, and output fields (including examples of amenity slugs). It does not cover error handling or defaults, but is fairly 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?
All 6 parameters have schema descriptions (100% coverage), but the description adds value beyond schema: it explains how 'q' matching works, that 'attributes' requires ALL matches, and that 'open_now' checks current local time.
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 specifies the action 'Search for places' and the resource (places like restaurants, cafes, shops). It distinguishes from sibling tools like 'get_place' (specific place) and 'search_dishes' (dishes 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 explains when to use this tool (for searching with free-text and filters) and provides details on composing filters. It does not explicitly state when not to use or compare to siblings, 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.
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; description minimally covers behavior (submission, returns submissionId). Does not disclose authentication needs, side effects beyond submission, or rate limits, but is adequate for a straightforward mutation.
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: first states action and scope, second gives prerequisite and return value. No wasted words, 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?
With 2 parameters fully described in schema and no output schema, the description covers usage flow and return. Lacks error scenarios or duplicate handling, but sufficient 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 description adds value by explaining how to obtain parameter values (list_forms). Also gives an example format for fields in schema description, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a form on behalf of the user (Wix Forms)') and specifies the resource. It distinguishes from siblings like list_forms by implying a write operation and mentioning return of submissionId.
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 prerequisite instruction ('Call list_forms first to get the formId and field keys'). Does not mention when not to use or alternatives, but context shows no direct sibling conflict.
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!