Moema — 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.3/5 across 28 of 28 tools scored. Lowest: 3.6/5.
Each tool targets a distinct resource and action (e.g., create_booking, create_checkout, request_reservation, reserve_event_tickets, rsvp_event all differ in purpose). Even similar-sounding tools like search_places and list_categories serve complementary roles (search vs taxonomy). No ambiguity.
All 28 tool names follow a consistent verb_noun pattern in snake_case (e.g., create_booking, get_availability, list_blog_posts). No mixing of conventions or vague verbs.
28 tools is above the typical 3-15 range but appropriate for the comprehensive scope of a neighborhood directory covering multiple Wix integrations (bookings, events, store, restaurants, etc.). Slightly heavy but well-scoped.
The tool surface covers the full lifecycle of a neighborhood directory: search, details, reviews, menus, booking, events, movies, offers, forms, FAQs, loyalty, etc. No obvious gaps; each domain has create/read/update/delete where applicable.
create_bookingAInspectBook an appointment slot at a venue (Wix Bookings). NOTHING IS BOOKED UNTIL THE CUSTOMER PAYS: this returns a checkout URL, and the booking stays off the venue's calendar until a human opens that URL and completes payment on the venue's own site. Tell the user they must open the link. Call get_availability immediately before this — the slot is re-validated server-side and a taken slot is rejected. The contact email is NOT verified at this step; the checkout is what confirms it.
| Name | Required | Description | Default |
|---|---|---|---|
| contact | Yes | Who the booking is for. All three are required by the venue to confirm or reschedule. | |
| endDate | Yes | Slot end as an ISO instant, exactly as returned by get_availability. | |
| serviceId | Yes | Service ID from list_booking_services (called with the same place_slug). | |
| startDate | Yes | Slot start as an ISO instant, exactly as returned by get_availability. | |
| place_slug | Yes | Venue place slug from search_places. | |
| resourceId | No | Optional staff/resource ID from the slot, when the user picked a specific professional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behaviors: booking stays off calendar until payment, slot re-validation, email not verified. Compensates fully for missing 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?
Single substantive paragraph with no redundancy. Every sentence adds essential 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?
Explains return behavior (checkout URL) despite no output schema. Could mention error handling, but overall complete for a booking 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%, but description adds value by explaining server-side re-validation and email verification context. Slight improvement over baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it books an appointment slot at a venue via Wix Bookings. Distinguishes from siblings by emphasizing the checkout flow and payment requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call get_availability immediately before, and explains that the booking is not confirmed until payment. Provides clear prerequisites and user guidance.
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?
Describes the user flow and login requirement, but does not disclose the exact behavior (e.g., returns a URL string) or any side effects. No annotations provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information, front-loading the core action and key context.
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?
Adequately explains purpose, user interaction, and a prerequisite (product ID from list_products), but could mention the output format (URL) for full clarity.
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 additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates a checkout URL for store products, specifying the domain (Wix Stores) and distinguishing it from siblings like list_products or 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?
Explicitly states when to use (create checkout URL for products) and implies no login needed, but lacks explicit when-not-to-use or 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?
No annotations provided, so description carries full burden. Discloses that slot times are returned in the venue's timezone (not necessarily directory's). Also hints at dependency on list_booking_services for serviceId and place_slug.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with purpose, followed by parameter usage and a key behavioral note.
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, description adequately covers purpose, parameters, and behavior (timezone). Lacks details on return format (e.g., array of time slots), but is sufficient 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?
Schema coverage is 100%, baseline 3. Description adds value by specifying 'from list_booking_services' for serviceId, confirming YYYY-MM-DD format for date, and emphasizing to use the same place_slug and noting its effect on timezone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get available time slots for a bookable service on a given date', specifying the verb (get), resource (available time slots), and context (Wix Bookings). It distinguishes from sibling tools like create_booking by focusing on availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions to pass serviceId from list_booking_services and date in YYYY-MM-DD. Advises using the same place_slug and notes timezone behavior. Does not explicitly state when not to use, but context implies it is for checking availability before creating a booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_ticketsAInspectGet ticket types and prices for a specific event (Wix Events). Pass the event slug from list_events. Returns ticket names, prices, sale status, and how many are left.
| Name | Required | Description | Default |
|---|---|---|---|
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description sufficiently discloses the read-only nature and what the response includes (ticket names, prices, sale status, count), adding behavioral context 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?
Two efficient sentences: first states purpose, second gives input guidance and output summary. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers input origin and output details completely, making it self-contained.
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 schema description already states 'Event slug from list_events.' The description repeats this, adding no new semantic value beyond reinforcing the prerequisite.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ticket types and prices for a specific event, with specific output fields, distinguishing it from related siblings like list_events and reserve_event_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to pass the event slug from list_events, providing a clear prerequisite. However, it does not explicitly mention when not to use this tool or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_loyalty_infoAInspectGet the loyalty/rewards program details for this site (Wix Loyalty). Returns program name, points currency name, and tier structure with required points per tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions return values but does not explicitly state it is read-only or idempotent. For a GET operation, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence front-loading the purpose and 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?
Given no output schema, the description explains return values adequately. For a simple read with no parameters, it is complete but could mention fallback behavior if loyalty is not configured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves loyalty/rewards program details for a site, specifying return fields (program name, points currency, tier structure). It distinguishes from siblings like get_site_info by focusing on loyalty-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. Although no parameters suggest it's always safe, there is no explicit guidance on context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_placeAInspectGet full details for a specific place by its URL slug, including opening hours, a precomputed open_now boolean, amenity attributes (slugs), a delivery array of curated delivery-app deep-links (ifood, rappi, uber-eats — each { platform, url }), ratings, address, and neighborhood.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug of the place, e.g. "cafe-example". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes what data is returned, implying a read-only operation, but does not explicitly state it is non-destructive, rate limits, or error handling (e.g., what if slug not found). The description adds value beyond no annotations but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs significant detail about return fields. While slightly dense, it is efficient and front-loads the tool's purpose and key output.
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 lack of an output schema, the description compensates by listing all returned fields and even details the delivery array structure. It adequately covers the tool's output, but omits error scenarios and performance notes. Still, for a simple getter, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (slug described as URL slug). The description repeats this context (by its URL slug) but does not add new semantics beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('get full details') and resource ('place by its URL slug'), enumerating exact fields returned (opening hours, open_now, attributes, delivery, ratings, address, neighborhood), which clearly distinguishes it from sibling tools like search_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving detailed info on a known slug, but does not explicitly state when not to use it or mention alternatives like search_places. However, the context of siblings and the specific slug parameter make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsBInspectGet published reviews for this site (Wix Reviews). Returns reviewer name, rating, title, and content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reviews to return (default 10, max 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields but lacks details on side effects, authentication, rate limits, or pagination. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (1 optional param, no output schema). Description explains returned fields but lacks details on ordering, filtering, or default behavior. Adequate but could be more 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% with one parameter ('limit') fully described. Description adds no additional meaning beyond 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 clearly states the verb 'Get', the resource 'reviews', and specifies 'published reviews for this site (Wix Reviews)'. It also lists returned fields, making purpose clear. However, it does not differentiate from sibling read 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?
No guidance on when to use this tool vs alternatives (e.g., list_blog_posts, list_events). No hints about when not to use it or prerequisites.
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 full burden. It discloses that the tool is read-only and returns specific fields, and mentions a prerequisite. It does not address rate limits or authorization, but these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the main action and providing necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description adequately explains the return format and prerequisite, making it complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by noting that date defaults to today in BRT and that movie_slug comes from list_movies, which clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets showtimes for a specific movie and date, with specific output details (cinema, session times, format, language). It distinguishes from sibling list_movies which only lists 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 a prerequisite ('Requires movies_enabled on this site') and implies usage for retrieving showtimes, but does not explicitly state when not to use or list alternatives.
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?
Discloses the return values include current local time and weather. No annotations provided, so description carries full burden; it is transparent about the read-only nature and data returned.
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, concise and front-loaded with purpose and details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers all expected output: name, locale, domain, description, canonical URLs, local time, and weather. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The baseline is 4, and the description adds meaning by specifying what is returned, thus no deduction.
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 returns basic information about the neighborhood directory, listing specific items including local time and weather. Distinct from siblings like get_place 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?
Explicitly advises use for 'what time is it there' or 'what's the weather like' context. While it doesn't list when not to use, the context is clear given sibling tools.
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, the description provides behavioral context such as listing recent published posts and returning specific fields, but omits details on pagination, ordering, or the definition of 'recent', which are important for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the action and resource, with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description compensates by listing key return fields. However, it lacks details on pagination, ordering, and the time scope of 'recent', which are needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by listing returned fields, but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'recent published blog posts' for 'this site (Wix Blog)', distinguishing it from sibling tools which cover different domains like bookings, events, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving published posts, but lacks explicit guidance on when to use this tool versus alternatives. However, sibling tools are unrelated, making the purpose clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_booking_servicesAInspectList a venue's services — what it offers, with price and duration. Pass place_slug (from search_places) to list the services of a specific VENUE — a salon, clinic or studio listed in this directory; that is what you want in almost every case, and it is the only form whose serviceId works with create_booking. Omitting place_slug lists the directory site's own services instead, which most sites do not have. Returns name, description, price, duration in minutes, and bookableViaMcp. Services are listed for EVERY venue, including those with no online booking system — check bookableViaMcp: when it is false, id is null and you cannot book through create_booking, so point the user at bookingUrl or the venue's page instead.
| Name | Required | Description | Default |
|---|---|---|---|
| place_slug | No | Venue place slug from search_places. Strongly recommended — without it you get the directory's own services, not a venue's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that services are listed even for venues without online booking, and explains the meaning of bookableViaMcp and its implications for create_booking. Does not mention pagination or rate limits, but such details are not critical for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, starting with the main purpose. It is longer than necessary but every sentence adds value. Could be slightly more concise, but still effective.
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 only one optional parameter and no output schema, the description fully compensates by describing both the input behavior and the output fields (name, description, price, duration, bookableViaMcp). It also covers the edge case of non-bookable venues.
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 description for place_slug, but the description adds substantial value by explaining its origin (from search_places), its purpose (strongly recommended), and the behavioral difference between providing it and omitting it.
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 a venue's services' with specific details about what is included (price, duration, name, description, bookableViaMcp). It distinguishes this tool from sibling tools like search_places or create_booking by focusing on service listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to list services for a venue from search_places) and when to avoid (omitting place_slug gives directory's own services, which is rarely desired). Provides alternative advice for non-bookable venues.
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 handles behavioral transparency but only covers what is returned. It omits potential side effects, authorization needs, or performance characteristics (e.g., pagination, caching) that could affect agent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and resource, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully explains what is returned, making it contextually complete for a simple list operation.
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 (schema coverage 100%), so the description is not required to elaborate on parameters. It correctly avoids adding redundant information, aligning with the baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'returns' and identifies the resource as 'full category taxonomy' with detailed components (top-level groups, subcategories, localized labels, schema.org types, live place counts), clearly distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (retrieving category taxonomy) but does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria or prerequisites.
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, but description discloses key behaviors: default upcoming_only true, filter enum semantics, live resolution of 'agora', and conditional weatherForecast. Lacks mention of auth, rate limits, or side effects, but these are minimal for a read-only 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?
Three front-loaded sentences: purpose, weatherForecast detail, filter detail. No fluff; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully explains return fields and conditional behavior. Covers filter options and date-specific weather data, sufficient for 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?
Schema covers all 3 parameters fully (100% coverage). Description adds value by detailing filter 'agora' live resolution and weatherForecast condition, providing context beyond 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?
Clear verb 'List' with specific resource 'upcoming events' and output fields (date, venue, price, URL). Distinguishes from sibling list_* tools by focusing on events with unique features like weatherForecast and filter enum values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on filter usage, especially 'agora' for real-time events, and explains weatherForecast inclusion. Does not explicitly state when to use vs. alternatives, but context with siblings and filter descriptions makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_faqsAInspectGet all FAQ questions and answers for this site (Wix FAQ). Grouped by category. Use this to answer common questions about the site — opening hours, parking, policies, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets all FAQs' which implies a read-only operation, but it doesn't mention potential limitations like pagination or rate limits. For a simple zero-param tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. Every sentence adds value: the first states the action and grouping, the second provides usage context.
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 adequately covers what it does and when to use it. It could mention that it returns all FAQs at once (no pagination) but is otherwise 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?
There are no parameters, so the schema coverage is 100% automatically. The description adds meaning beyond the empty schema by explaining the output is grouped by category, but no param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all FAQ questions and answers' and specifies it's for the Wix site, grouped by category. It distinguishes from sibling tools like get_site_info or list_blog_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this to answer common questions about the site — opening hours, parking, policies, etc.' It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_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 carries full burden. It accurately describes the read-only nature of listing forms and the expected output, though it could explicitly state it is non-destructive or mention any authentication requirements. Overall, it is transparent for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence states the action and return values, and the second provides usage guidance. No extraneous information, perfectly 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 has no parameters, no output schema, and is straightforward, the description is complete. It explains what it does, what it returns, and how it fits into a workflow with the sibling 'submit_form'.
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 baseline is 4. The description does not need to add parameter-specific semantics, and it correctly conveys that no input is required.
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 the resource 'available contact/signup forms on this site (Wix Forms)'. It specifies the return values (form name, ID, field definitions) and distinguishes its discovery purpose from the sibling tool 'submit_form'.
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 before 'submit_form' to discover fields, providing clear context for when to use it. It does not include direct when-not-to-use statements, but the guidance is sufficient.
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 must fully disclose behavior. It correctly indicates a read-only list operation but lacks details on side effects, authentication, rate limits, or return format. The information is minimal but adequate for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. It front-loads the essential action and resource, then adds a use-case context. No redundant information is present.
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 only one optional parameter and no output schema, the description is largely complete. It explains the tool's purpose and when to use it. However, it could optionally hint at the response structure (e.g., array of guides) to fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage for the single parameter 'limit'. The tool description does not add any additional meaning beyond the schema's own documentation, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('curated editorial guides'), and elaborates on content ('ranked places with editorial notes'). It effectively distinguishes from sibling listing tools by specifying 'best of lists' and use case for neighborhood questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('best source for 'best X in this neighborhood' questions'), implying when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among the many sibling list tools.
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 must carry the full burden. It discloses the condition (movies_enabled) and the types of movies returned, but does not explicitly state that the operation is read-only, nor does it mention any authentication or rate limits. The described behavior is consistent with a read-only list, but transparency is adequate but not exceptional.
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 (three sentences) and front-loaded with the main purpose. Every sentence adds meaningful information, though it could be slightly more structured (e.g., bullet points for the return 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?
The description covers the return fields (title, genres, TMDB rating, runtime, detail URL) and the movies_enabled condition. However, it lacks information on pagination (how to get more than 'limit' results) and error handling if the site does not have movies_enabled. Given no output schema, the description provides sufficient but not comprehensive completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by explaining the enum values (e.g., 'now_showing' = films with upcoming showtimes at local cinemas) and the meaning of the status filter beyond the enum names. This enriches the parameter 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 tool lists movies available in the neighborhood, with specific categories (now-showing, coming-soon, streaming) and a condition (only on sites with movies_enabled). It is distinct from sibling tools like list_events or list_blog_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it over alternatives like list_events or search_places. Usage context is implied by the movie focus, but no when-not or exclusion criteria are stated.
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 provided, so description carries burden. States it returns active offers and notes FLASH have countdowns, but doesn't confirm read-only nature or disclose any side effects, rate limits, or response ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Efficiently presents needed info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists return fields sufficiently. Could mention if offers are sorted or paginated, but for a list tool with 2 optional params, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds minimal value beyond schema: mentions FLASH but doesn't elaborate on limit default or behavior 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?
Clearly states it lists active promotions and deals, specifies exact returned fields (discount label, promo code, etc.), and distinguishes FLASH offers. Differentiates from sibling list tools by focusing on offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when wanting to retrieve offers, but lacks explicit guidance on when to use vs other list tools (e.g., list_products, list_events). No when-not-to or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pricing_plansAInspectList membership or subscription plans (Wix Pricing Plans). Pass place_slug (from search_places) to list the plans of a specific VENUE — a gym, studio or clinic listed in this directory (e.g. its monthly/annual membership); that is what you want in almost every case. Omitting place_slug lists the directory site's own plans instead, which most sites do not have. Returns plan name, description, price, billing cycle, perks, and a direct checkout URL.
| Name | Required | Description | Default |
|---|---|---|---|
| place_slug | No | Venue place slug from search_places. Strongly recommended — without it you get the directory's own plans, not a venue's. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that omitting place_slug returns different results and describes the return fields (name, description, price, billing cycle, perks, checkout URL). However, it could mention that the operation is read-only and has no side effects, and it does not state any authorization requirements or rate limits. The disclosure 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?
Two sentences, no fluff. The first sentence states the primary purpose and the key parameter; the second explains the alternative. Information is front-loaded and every sentence earns its place. Ideal 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 tool has only one parameter, no required fields, no enums, and no output schema, the description covers the essential behavioral and usage aspects thoroughly. It explains the two contexts, what is returned, and how to get the venue slug (from search_places). No additional information is needed for an agent to use this 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?
Schema coverage is 100% (one parameter with a description). The description adds significant value beyond the schema by explaining the practical implications of providing or omitting place_slug, including a strong recommendation and the consequence of each choice. This helps the agent decide correctly.
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 using a specific verb ('List'), identifies the resource ('membership or subscription plans (Wix Pricing Plans)'), and distinguishes between two cases: venue-specific plans (with place_slug) and directory site's own plans (without). This differentiates it from sibling tools that handle bookings, 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 tells when to use each parameter: 'Pass place_slug (from search_places) to list the plans of a specific VENUE' and 'Omitting place_slug lists the directory site's own plans instead, which most sites do not have.' This provides clear context and a strong recommendation ('that is what you want in almost every case'). No exclusive alternatives are named, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAInspectList products in this site's store (Wix Stores). Returns name, price, stock status, and product type.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional search term matched against product name. | |
| limit | No | Max products to return (default 20, max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions return fields but does not disclose if it's read-only, required authentication, rate limits, or side effects. Missing behavioral context that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. Purpose and return info are 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 no output schema, description adequately lists returned fields. For a simple list tool with only two optional parameters, the information is sufficient. Could mention ordering or total count, but not critical.
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 description adds no extra meaning beyond the schema. Both parameters (q, limit) are fully described in the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists products in the site's store (Wix Stores) and specifies returned fields (name, price, stock status, product type). Distinguishes from siblings like list_blog_posts or list_events by specifying 'products' and 'Wix Stores'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing store product info, but no explicit guidance on when not to use or alternatives among the many sibling tools. Lacks context about prerequisites or scope.
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 must disclose behavioral traits. It mentions return fields (name, URL, category, metadata) but does not detail side effects, auth requirements, rate limits, or pagination behavior. The tool appears read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and resource, then data about what is returned. Every word adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists return fields. It covers the essential aspects of a list tool, though it omits details on pagination or result ordering. Slightly above adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'limit' parameter. The tool description adds no additional meaning beyond what the schema provides. 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 uses the specific verb 'list' and identifies the resource as 'solo service-provider profiles'. It distinguishes from sibling tools by defining 'businesses without a fixed physical location' and provides concrete examples (dog walkers, tutors). This clearly states the tool's purpose and scope.
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 clear context for when to use the tool (listing non-location-based service providers) and implicitly differentiates from other list tools by specifying the profile type. However, it does not explicitly state when not to use it or mention alternatives.
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?
With no annotations, the description fully discloses key behaviors: the restaurant is not notified yet, a confirmation email is sent, the link expires in 24 hours, and the confirmation link is not returned to the agent. This is highly transparent and sets correct expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the main action and then providing critical details in a logical order. Every sentence serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and absence of output schema, the description is complete. It covers the entire workflow: what the tool does, what the response triggers, and what the agent should tell the user. It also implicitly distinguishes from sibling tools like 'create_booking'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing usage context for the email parameter ('use a real address belonging to the person you are acting for') and explaining that the confirmation link is deliberately not returned, which clarifies the tool's flow 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 'Request a table at a restaurant' with a specific verb and resource. It distinguishes this tool from 'create_booking' by emphasizing that it is an unconfirmed request. The critical note about the restaurant not being notified immediately sets it apart from 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 explicitly tells when to use this tool (to request a table), what happens next (check email, link expires in 24 hours), and warns about using a real address. It also clarifies that this is not a confirmed booking, guiding the agent on when to use alternatives.
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 fully discloses behavior: hold is temporary, no payment, tickets not confirmed until checkout, hold expires, max limits (10 tickets and 10 ticket types). 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, each earning its place: first states purpose and output, second explains temporary nature, third adds limits and exclusions. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description mentions return of checkout URL. Covers all critical aspects: behavior, limits, exceptions. Could optionally describe output format but not necessary.
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 has 100% coverage with descriptions for both parameters. But description adds valuable limits (max 10 tickets and 10 ticket types) and clarifies that ticketDefinitionId comes from get_event_tickets, which is not in 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 'hold', the resource 'tickets for an event', and the output 'checkout URL'. It distinguishes from siblings like create_booking, create_checkout, and rsvp_event by focusing on holding temporary tickets.
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 (for events sold directly through this site) and when not (for events sold elsewhere like Sympla, Ingresse, Sesc), with an alternative suggestion (use event's own ticketUrl). Also clarifies that nothing is paid and the hold is temporary.
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?
Discloses key behaviors: confirmation email goes to provided address, RSVP only submitted when link clicked (24h expiry), link not returned to caller. No annotations, so description carries full burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then behavioral details. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, description fully covers what the tool does, its side effects (email, expiry), and usage instructions. No apparent gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: email is 'the guest's own email', event_slug comes from list_events. Provides context beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool RSVPs to a free event, distinguishing it from siblings like reserve_event_tickets (which likely involves payments). Uses specific verb+resource: 'RSVP to a free event'.
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 context: 'NOBODY IS ON THE GUEST LIST YET', instructs to tell user to check inbox, and to use a real address. Could mention when to use alternatives like reserve_event_tickets, 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.
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?
No annotations provided, so description carries full burden. Discloses search scope (all restaurants on site), grouping, and returned fields (price, description, dietary labels, URL). Lacks details on auth or rate limits, but these are less critical for a search 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, front-loaded with purpose, no wasted words. Efficient and clear.
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 search tool with two optional parameters. No output schema needed as description explains return format. All necessary info is present.
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. Description adds value beyond schema by explaining that omitting query lists top dishes, and re-iterates limit behavior. Provides context for typical 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?
Clearly states the verb 'find' and resource 'restaurants serving a dish in this neighborhood'. Distinguishes from siblings like search_places by specifying neighborhood scope and grouping by dish.
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: for 'where can I eat X' questions. Also explains behavior when query is omitted. Lacks explicit when-not-to-use, but context is sufficient.
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 are provided, so the description fully carries the transparency burden. It details search behavior (accent-insensitive, typo-tolerant), result fields (open_now, attributes, delivery, rating, hours), and common amenity slugs, providing comprehensive behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with front-loaded purpose and subsequent detail. Every sentence adds valuable information; however, it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description adequately covers all parameters and explains result fields. Some minor details like pagination for limit are present. No critical gaps identified.
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. The description adds meaningful context beyond schema: explains typo-tolerance for q, case-insensitive substring for category, server-side open_now computation, mandatory ALL for attributes, and neighborhood substring match. This enriches parameter 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 ('Search for places') and the resource ('restaurants, cafes, shops, etc.'). It distinguishes from sibling tools like search_dishes by focusing on general place search.
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 how to use filters but does not explicitly state when to use this tool versus alternatives like get_place or search_dishes. Usage context is implied but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_formAInspectSubmit a form on behalf of the user (Wix Forms). Call list_forms first to get the formId and field keys. Returns a submissionId on success.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Key-value pairs matching the field keys from list_forms. Example: { "field_1": "João", "field_2": "joao@email.com" } | |
| formId | Yes | Form ID from list_forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that the tool returns a submissionId on success, which is useful. However, it does not disclose potential side effects, authentication requirements, or whether submission is reversible. For a mutation tool, slightly more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states purpose, the second gives prerequisite and return value. 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 simple form submission tool without output schema, the description covers purpose, prerequisite, return value, and parameter context. It lacks behavioral details like idempotency but is otherwise complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing an example for the 'fields' parameter and clarifying that formId and field keys come from list_forms. This aids understanding of parameter relationships 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 'Submit', the resource 'form', and the domain 'Wix Forms'. It distinguishes from sibling tools by instructing to call list_forms first, implying this tool is for the submission step 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 provides explicit usage guidance: 'Call list_forms first to get the formId and field keys.' This tells the agent a necessary prerequisite. However, it does not specify when not to use this tool or mention alternative submission methods.
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!