Jardins — 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.4/5.
Each tool targets a distinct action and resource, such as booking, checking availability, listing events, or searching dishes. No two tools appear to overlap in purpose, and descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern (e.g., create_booking, get_availability, list_events, search_places). The prefixes (create, get, list, search, request, reserve, rsvp, submit) are uniformly applied, and there is no mixing of cases or styles.
With 28 tools, the server covers a broad feature set for a neighborhood directory, including bookings, store, events, loyalty, menus, movies, and more. While slightly high, each tool serves a distinct purpose and is justifiable.
The tool surface appears complete for the domain: search, details, booking flows, store purchases, events, loyalty, reviews, blog, offers, profiles, forms, and FAQ are all covered. There are no obvious dead ends, and operations for CRUD or lifecycle are present where needed.
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?
With no annotations, the description fully discloses critical behaviors: nothing is booked until payment, returns a checkout URL, booking stays off calendar, contact email is not verified. This is comprehensive and prevents misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the core purpose and contains several sentences, each adding value. Could be slightly more concise, but clearly structured and informative 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?
Despite no output schema, the description explains the return type (checkout URL) and the asynchronous payment flow. It also mentions prerequisites, server-side validation, and user expectations, covering all essential context for a complex 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 schema descriptions are already detailed (e.g., phone format, contact fields). The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it books an appointment slot at a venue (Wix Bookings). It identifies the resource (appointment slot) and verb (book), distinguishing from sibling tools like get_availability or request_reservation by specifying the workflow and outcome.
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 this tool, warns that slots are re-validated and taken slots are rejected, and tells the user to open the checkout URL. This provides clear when-to-use and prerequisite 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?
No annotations provided, so the description must fully convey behavioral traits. It mentions 'no login required' but does not disclose side effects (e.g., temporary order creation), stock requirements, or error scenarios. 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?
The description is a single, clear sentence that immediately conveys the tool's purpose without fluff. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description provides enough to understand basic functionality. However, it lacks details on output format (the URL) and potential errors, making it adequate but not 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 descriptions for each parameter. 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 it creates a direct checkout URL for store products, specifying the resource (checkout URL) and verb (create). It also distinguishes from siblings like list_products by focusing on checkout creation.
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 'no login required on the AI agent side' providing some context, but lacks explicit guidance on when to use this tool versus alternatives like submit_form or other payment tools. No exclusions or when-not-to-use advice.
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. Reveals timezone behavior (returned in venue's timezone) but omits details like pagination, limits, or error scenarios.
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 redundant information. 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?
Adequate for a simple retrieval tool with few parameters and no output schema. Covers input sources and timezone behavior. Could mention any constraints (e.g., date range limits) 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% with descriptions for all 3 params. Description adds minor contextual guidance (source for serviceId, use same place_slug) but doesn't significantly extend schema meaning. 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?
Clearly states verb 'Get', resource 'available time slots', and context 'for a bookable service on a given date (Wix Bookings)'. Distinguishes from sibling tools like list_booking_services and 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 instructs to pass serviceId from list_booking_services and date in YYYY-MM-DD, with caveat about venue timezone. Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 exist, so the description carries the full burden. It discloses the return fields (ticket names, prices, sale status, quantity left) and uses 'Get' implying a read-only operation. While it doesn't explicitly state no side effects or mention authentication/rate limits, the description is fairly transparent for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the purpose and tool category, the second provides usage instructions and output details. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description provides complete context: what input is needed, where to get it, and what the output contains. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for event_slug. The description repeats the schema's guidance to use the slug from list_events, adding no new meaning beyond what the schema already 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 clearly states the action ('Get'), the resource ('ticket types and prices for a specific event'), and the scope ('Wix Events'). It distinguishes from sibling tools like list_events and reserve_event_tickets by specifying the input source (event slug from list_events) and the output type (ticket info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the user to pass the event slug from list_events, providing a clear usage step. While it doesn't explicitly state when not to use, the context implies this is for viewing ticket details before booking, effectively guiding the AI agent.
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 bears full responsibility. It accurately implies a read-only operation ('get') but does not explicitly state safety, authentication requirements, or potential side effects. The simple nature of the tool makes vagueness tolerable but not exemplary.
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 immediately states the verb and resource. It is front-loaded, contains no superfluous words, and efficiently conveys the tool's function and 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?
For a zero-parameter tool with no output schema or annotations, the description sufficiently explains what the tool returns. It includes scope ('for this site') and details of the output (program name, currency, tiers), providing a complete understanding of the tool's capability.
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% (vacuously). Per guidelines, baseline is 4. The description adds value by describing the output, which indirectly clarifies that no parameters are 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 uses a specific verb 'Get' and clearly identifies the resource as 'loyalty/rewards program details for this site (Wix Loyalty)'. It lists exact return fields (program name, points currency name, tier structure), making the purpose unambiguous and distinct from sibling 'get_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or conditions for appropriate use. The usage is only implied from the purpose.
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 are provided, so the description carries full burden. It transparently lists all returned fields, but does not mention potential errors, rate limits, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists key return fields efficiently. Every part 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 thoroughly covers the return details. For a tool with one simple parameter, it is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the format of the slug and what the tool returns, though the parameter itself is well-described in 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 full details for a specific place by its URL slug, listing multiple fields. It distinguishes itself from sibling tools like search_places by focusing on a single place and providing specifics.
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 (for a specific place by slug), but does not explicitly state when not to use or provide alternatives. It is clear in context but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsAInspectGet 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?
With no annotations, the description carries full burden. It explicitly states the return fields (reviewer name, rating, title, content), which is transparent. However, it omits details like ordering (chronological?), idempotency, or auth requirements, but for a read-only tool this is fairly thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first fronts the purpose, second lists outputs. No filler words; every sentence earns its place. Exceptionally concise.
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 exists, but the description compensates with return field names. It could mention ordering (e.g., 'newest first') or pagination behavior, but for a simple list tool with one parameter, it 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% for the single parameter (limit), so baseline is 3. The description adds value by listing the return fields, which the schema omits. This indirectly clarifies the tool's output semantics beyond the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'published reviews for this site (Wix Reviews)', making the purpose unambiguous. No sibling tool appears to handle reviews, so differentiation is inherent.
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?
While the tool is unique among siblings (no other review tools), there is no explicit guidance on when to use it or context like 'Use to display customer feedback.' It meets minimum clarity but misses proactive usage context.
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?
With no annotations provided, the description discloses the behavioral constraint (movies_enabled requirement) and implies a read operation. It does not contradict anything, and the behavior is transparent for a simple retrieval 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 concise (two sentences) and well-structured: first sentence defines purpose and output, second sentence adds a critical prerequisite. 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 the low parameter count, no output schema, and no nested objects, the description sufficiently explains what the tool does and returns (cinema, times, format, language). The prerequisite adds necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by noting that date defaults to today (BRT) and that movie_slug comes from list_movies. This helps the agent understand parameter origins and defaults.
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 showtimes for a specific movie at local cinemas for a given date, specifying output details (cinema, times, format, language). It distinguishes itself from sibling tools like get_event_tickets or get_restaurant_menus, which are unrelated.
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 context by noting the prerequisite 'Requires movies_enabled on this site.' However, it does not explicitly mention when to use this tool over alternatives or exclusions, but the context is clear enough for a read-only lookup tool.
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 provided, but description fully discloses output includes time and weather. Since it's read-only and no side effects are expected, the description is adequate. Could mention data freshness or location assumptions but not required.
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. First sentence states purpose and data, second gives usage context. Perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple nature (0 params), description fully covers what the tool returns and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds value by listing returned fields beyond schema, such as specific sections and weather details. Baseline for 0 params is 4, but extra detail earns a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns basic site information including time and weather, using specific verb 'returns' and resource 'neighborhood directory'. Unambiguous and distinct from sibling tools (e.g., get_place, get_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?
Explicitly states use for 'what time is it there' or 'what's the weather like' context, but does not mention when not to use or alternative tools. Still, context is clear and sufficient given uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_blog_postsAInspectList recent published blog posts for this site (Wix Blog). Returns title, excerpt, author, published date, reading time, categories, and the post URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts to return (default 10, max 50). | |
| category | No | Filter by category label. Case-insensitive substring match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It implies read-only by saying 'returns', but doesn't disclose pagination, authentication, or rate limits. Acceptable 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 sentences, no filler, front-loaded with key info. 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 optional params and no output schema, description is nearly complete. Could mention default ordering (e.g., by date) but not essential for typical 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 covers both parameters with descriptions (100% coverage). Description adds value by listing return fields but does not elaborate further on parameters. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list', the resource 'recent published blog posts for this site (Wix Blog)', and lists returned fields differentiating it from sibling list tools like list_products or list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Purpose is clear and implicitly distinguishes from siblings, but no explicit guidance on when to use vs. alternatives or conditions like 'use this only for blog posts'.
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 exist, so description carries full burden. It discloses return fields (name, description, price, duration, bookableViaMcp), explains that services are listed for all venues including those without online booking, and clarifies when create_booking works (only with venue services).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with all critical information front-loaded. While slightly lengthy, every sentence adds value, and there is 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 simple parameter (1 optional, no nested objects) and no output schema, the description covers all relevant scenarios: parameter modes, return fields, handling non-bookable services, and integration with create_booking. No 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 significant context: explains the two modes, emphasizes that venue services are the primary use case, and ties to create_booking functionality, exceeding the schema's explanation.
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, distinguishing between services for a specific venue (using place_slug) and the directory's own services. It explicitly contrasts with sibling tools like search_places and create_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use place_slug for venue services (almost always what you want), omitting it gives directory services (most sites don't have). It also advises what to do when bookableViaMcp is false: point 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?
No annotations are provided, so the description carries the full burden. It describes the return content (full taxonomy, labels, types, counts) but does not mention any behavioral traits like whether it's cached, paginated, or rate-limited. For a zero-parameter read-only tool, this is adequate but not exhaustive.
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 key information. There is zero 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 and no parameters, the description provides sufficient context about what the tool returns. However, it could briefly note the return format (e.g., array) to further aid understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and input schema coverage is 100%. The description does not need to explain parameters. Per guidelines, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full category taxonomy with specific details (groups, subcategories, labels, types, counts). It uses a specific verb 'returns' and a specific resource, and it distinguishes from sibling list_* tools by focusing exclusively on categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention usage context, exclusions, or when not to use it. With many sibling tools, explicit guidance would help.
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 present; description covers behavioral aspects like weatherForecast inclusion and live resolution of 'agora' filter. Doesn't mention side effects or rate limits, but as a listing tool, read-only behavior is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with key information front-loaded. Second sentence is slightly long but valuable. 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?
No output schema, but description lists return fields (date, venue, price, URL, weatherForecast) adequately. For a list tool, it covers what users need to know about the 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?
Schema coverage is 100%, so baseline 3. Description adds significant meaning: explains filter enum values in detail (e.g., 'agora' excludes season runs, 'gratis' includes externally-ticketed events at price 0), and notes limit default/max beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists upcoming events with specific fields (date, venue, price, URL) and distinctive weatherForecast feature. Differentiates from siblings by mentioning filter 'agora' for live events, which is unique among 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?
Provides explicit guidance on using filter values like 'agora' and explains live resolution. Lacks explicit when-not-to-use or direct sibling comparison, but gives context for typical use cases.
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 provided, so description carries full burden. It describes the tool as fetching and grouping data, implying a safe read operation, but does not explicitly state no side effects, auth requirements, or rate limits. 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?
Two sentences: first states purpose and grouping, second gives usage examples. Every sentence is valuable, no redundancy, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description mentions grouping by category and provides examples of content (opening hours, parking, policies). It gives enough context for the agent to understand the tool's role, though return field names 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?
Input schema has no parameters (0 params), and schema coverage is 100% by default. Baseline is 4, and description does not need to add parameter info. It does not provide any parameter semantics, which is acceptable.
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 states a specific verb 'Get' and resource 'FAQ questions and answers', and mentions grouping by category. It is clearly distinct from sibling tools like list_blog_posts 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?
Explicitly says 'Use this to answer common questions about the site — opening hours, parking, policies, etc.' This provides clear context for when to use, but 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?
No annotations are provided, so the description carries the full burden. It discloses the return format (name, ID, field definitions) and that it lists forms. For a read-only list tool with no destructive behavior, this is adequate, though it could mention if there are any limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value: first defines purpose and output, second provides usage guidance. 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?
Given the tool has no parameters, no output schema, and a simple purpose, the description is fully adequate. It explains the tool's role in the workflow and what data it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter information because none 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 the tool lists available contact/signup forms, specifies the platform (Wix Forms), and details the return fields (name, ID, field definitions). It distinguishes itself from sibling tool 'submit_form' by recommending usage before it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use before 'submit_form' to discover fields, providing a clear when-to-use and an alternative tool. This meets the 5-level criteria of 'explicit when/when-not/alternatives'.
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 carries the burden. It mentions that guides are ranked and include editorial notes, but lacks details on authentication, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, each serving a clear purpose: stating the function and providing a use case.
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 parameter and no output schema, the description adequately explains what the tool returns and its purpose, though it could mention ordering or pagination beyond limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter 'limit'. The description adds no additional semantics 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?
The description explicitly states the tool lists curated editorial guides and distinguishes them from other list-type tools by specifying 'best of' lists with editorial notes.
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 context by stating it is 'the best source for best X in this neighborhood questions', guiding when to use it, but does not explicitly mention when not to use it or alternatives.
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?
With no annotations, the description carries full burden. It explains the scope (neighborhood, movies_enabled) and return items (now-showing, coming-soon, streaming, and details). Does not disclose rate limits or authentication needs, but for a read-only list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, 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?
Complete for a list tool: describes returned fields (title, genres, TMDB rating, runtime, detail URL) and scope. No output schema needed.
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 meaningful context: e.g., 'now_showing' described as 'films with upcoming showtimes at local cinemas' which clarifies enum options 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?
Description clearly states 'List movies available in this neighborhood' with a specific verb and resource, and distinguishes it from sibling list tools (e.g., list_events, list_products) by mentioning movies and movie-specific attributes.
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 context about when to use ('only on sites with movies_enabled') and implicitly differentiates from sibling tools by focusing on movies. 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.
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?
With no annotations provided, the description carries the behavioral transparency burden. It discloses that the tool returns specific fields (discount label, promo code, etc.) and notes that FLASH offers have a countdown deadline, which are valuable behavioral details. However, it does not explicitly state that the operation is read-only or discuss any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short sentences that front-load the core purpose and return fields. 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 the tool has only two parameters and no output schema, the description is nearly complete: it explains the returned fields, mentions the special FLASH behavior, and covers the limit parameter implicitly. It lacks details on pagination beyond 'max 60' and error cases, but these are minor 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?
The input schema has 100% coverage with descriptions for both parameters (kind and limit). The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active promotions and deals, specifying the verb, resource, and scope. It distinguishes FLASH offers from standard ones, and the resource ('promotions and deals') differentiates it from siblings like list_products or list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing offers but provides no explicit guidance on when to use this tool versus alternatives like list_products or list_events. No when-not-to-use scenarios or alternative tool mentions 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, but description fully explains read-only listing behavior, return fields, and two operational paths. Lacks mention of authentication or pagination, but not required for a simple list.
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 purpose and key instruction, second explains alternative. Every word earns its place, front-loaded, 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?
Simple tool with one optional parameter and no output schema; description covers resource, behavior, parameter guidance, and return fields. Complete for agent decision-making.
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 parameter 100%, but description adds crucial context: strongly recommended, purpose, and source (search_places). Significantly enriches meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List membership or subscription plans' with specific resource and distinguishes between two modes (with and without place_slug). Returns explicit fields. No confusion with 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?
Explicitly instructs to pass place_slug from search_places to get venue plans, and warns that omitting it yields directory's own plans (rare). Provides clear when-to-use and alternatives.
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?
With no annotations, the description must disclose behavioral traits. It confirms the operation is a list (read) and specifies return fields, but does not mention whether it is safe (e.g., no side effects), pagination behavior, or any restrictions beyond default and max values in 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 two sentences, concise and front-loaded with the main purpose. Every piece of text adds value, but it could be slightly more structured (e.g., bullet points for 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?
Given the tool's simplicity (two optional params, no output schema), the description with the schema is minimally complete. However, it lacks details on default behavior, sorting, or how results are ordered, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters (q and limit) beyond what the schema already provides, which is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists products in the Wix Stores store, with specific return fields (name, price, stock status, product type). The verb 'list' and resource 'products' are unambiguous, and among numerous sibling tools of different resources, this tool is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when not to use it. The existence of sibling listing tools for other resources is not addressed.
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 the return fields (name, profile URL, category, metadata) and that it lists profiles of businesses without fixed location. It implies read-only behavior but could mention lack of side effects or pagination.
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 filler, front-loaded with purpose, examples, and return values. 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 low complexity, the description covers what the tool does and returns. It mentions the scope (solo service-providers) and example return fields. Could specify lack of other filters or pagination details, 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?
Schema coverage is 100% for the single optional parameter 'limit', whose description already explains 'Max profiles to return (default 50)'. The description adds no further 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 'List solo service-provider profiles on this site' with specific verb and resource. It distinguishes from siblings by specifying 'solo service-provider' and 'businesses without a fixed physical location', with examples (dog walkers, tutors).
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 solo provider profiles but does not explicitly state when to use it versus alternatives (e.g., list_products, list_categories). No comparison or exclusion criteria are given.
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 behavioral traits: the request is held, a confirmation email is sent, the link expires in 24 hours, and the confirmation link is not returned to the agent. This transparency helps the agent understand side effects and constraints.
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-4 sentences), front-loaded with the main purpose, and every sentence provides essential information. 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 the complexity of 7 parameters (5 required), no output schema, and no annotations, the description is remarkably complete. It explains the overall flow, user-facing steps, constraints on email and time, and what to tell the user.
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 meaningful context beyond the schema. It explicitly states that the email must be the guest's own, that phone is optional, and that requestedAt must be an ISO instant in the future. It also explains place_slug's origin from search_places. Slightly more detail on phone format could push it to 5.
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 requests a table at a restaurant, using a specific verb and resource. It distinguishes itself from siblings like 'create_booking' by emphasizing this is a request, not a confirmed booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use when requesting a table, inform the user to check email, warn about link expiry, and stress using a real address. It also clarifies the restaurant is not notified until the link is clicked, setting correct expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reserve_event_ticketsAInspectHold tickets for an event sold through this site (Wix Events) and return a checkout URL. THE HOLD IS TEMPORARY AND NOTHING IS PAID: the tickets are not the user's until a human opens the URL and completes checkout, and the hold expires on its own if they don't. Max 10 tickets and 10 ticket types per reservation. Only works for events this site sells directly — for events sold elsewhere (Sympla, Ingresse, Sesc), use the event's own ticketUrl instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tickets | Yes | Ticket types and quantities to hold. | |
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully clarifies the tool's behavior: the hold is temporary, nothing is paid, a checkout URL is returned, and the hold expires if not completed. It also states restrictions on event source and limits on tickets.
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: first sentence states the main action and return value, second details the temporary nature, third adds limits and alternative tool usage. Every sentence adds necessary information 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) and full schema coverage, the description covers all necessary aspects: purpose, constraints, alternative scenarios, and what the user gets (checkout URL). No gaps for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. The description adds value beyond the schema by stating constraints (max 10 tickets and 10 ticket types) and clarifying the purpose of the tickets array as 'Ticket types and quantities to hold.' This provides context that the schema alone does not give.
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: 'Hold tickets for an event sold through this site (Wix Events) and return a checkout URL.' It specifies the resource (event tickets) and the verb (hold and return URL), and distinguishes it from siblings like 'create_booking' and 'rsvp_event' by focusing on temporary holds, not final 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?
Explicitly tells when to use this tool ('Only works for events this site sells directly') and when not to ('for events sold elsewhere... use the event's own ticketUrl instead'). Also covers constraints: max 10 tickets and 10 ticket types, hold is temporary and expires.
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 key behaviors: RSVP is not immediate, sends a confirmation email with a 24-hour expiry, the link is not returned to the caller, and a real email must be used. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of about 80 words, front-loading the core action and then providing critical guidelines. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the essential behavioral flow (email confirmation, expiry, user notification). It does not mention error handling or edge cases, but for a straightforward RSVP tool, 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% with good descriptions. The description adds value by emphasizing the email parameter's behavioral context (confirmation link sent there, must be real, not returned), going beyond the schema's static description. This extra semantic context earns a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'RSVP to a free event on this site (Wix Events).' It specifies the action (RSVP) and resource (free events), and implicitly distinguishes from siblings like reserve_event_tickets by emphasizing free events and the confirmation email flow.
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: 'NOBODY IS ON THE GUEST LIST YET... Tell the user to check their inbox. Use a real address... the confirmation link is deliberately not returned to you.' This tells the agent when to use it, what to communicate, and important caveats.
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 must fully disclose behavior. It explains that the tool searches every menu item across all restaurants, groups by dish, and returns price, description, dietary labels, and place URL. It also notes the effect of omitting the query. However, it does not address authentication, rate limits, or how 'neighborhood' is determined, leaving some 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 exceptionally concise—two sentences with no wasted words. The first sentence states the core purpose, and the second explains how it works with a concrete example. It is front-loaded and easy to scan.
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 explains the return content (price, description, dietary labels, place URL) and the effect of omitting the query. Minor missing details like sorting order or result limits (beyond the 'limit' parameter) are acceptable given the tool's straightforward nature.
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 describes both parameters (limit, query) with 100% coverage. The description adds practical context: it explains that 'query' can be a dish name or part thereof, gives an example ('feijoada'), and clarifies that omitting it lists top dishes. This adds meaningful usage guidance 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's purpose: 'Find which restaurants serve a dish in this neighborhood.' It specifies the verb (find), resource (restaurants serving a dish), and scope (across all restaurants, grouped by dish). The example 'feijoada' and distinction from sibling tools like 'get_restaurant_menus' and 'search_places' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use the tool: 'Use this for any "where can I eat X" question.' It also explains the behavior when 'query' is omitted (list most-served dishes). However, it does not explicitly state when not to use it or mention alternative tools, though the context of sibling tools provides some differentiation.
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 bears the burden. It discloses the typo-tolerant/accent-insensitive matching, ranking by relevance, the server-side open_now computation, the ALL-must-match constraint for attributes, and the exact structure of results (open_now boolean, attributes array, delivery array with platform/url, rating, hours in Google Maps periods).
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 each sentence adds value. It is well-structured: purpose first, then q behavior, filter usage, result details. Slight reduction in wordiness could improve conciseness, but it remains focused and informative.
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 6 parameters, no output schema, and no annotations, the description covers all key behaviors and result details. It misses explicit mention of the limit parameter (described in schema only) and could clarify the neighborhood context, but overall it is quite 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 significant meaning beyond parameter names: it explains the q matching behavior (accent-insensitive, typo-tolerant), the open_now filter semantics (computed server-side), the attributes filter logic (ALL must match), and the result structure details (delivery array format, hours format, amenity slugs).
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 searches for places (restaurants, cafes, shops, etc.) in a neighborhood. It uses a specific verb ('Search') and resource ('places'), and distinguishes from sibling tools like get_place (singular) or search_dishes (specific to dishes).
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 search behavior and filter usage (category, neighborhood, open_now, attributes). It implies when to use this tool (generic place search) vs siblings (e.g., get_place for specific place, search_dishes for dishes), but does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_formAInspectSubmit a form on behalf of the user (Wix Forms). Call list_forms first to get the formId and field keys. Returns a submissionId on success.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Key-value pairs matching the field keys from list_forms. Example: { "field_1": "João", "field_2": "joao@email.com" } | |
| formId | Yes | Form ID from list_forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It states the tool is a submission (write operation) and returns a submissionId on success, but does not disclose potential side effects, authorization needs, or error handling. Basic transparency is present.
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, followed by prerequisite and output. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 required parameters and no output schema, the description adequately covers how to obtain inputs and what the return value is. No missing critical information.
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 both parameters described. The main description adds no additional semantic value beyond what the schema already provides (e.g., the example in 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 identifies the action ('submit a form'), the resource ('Wix Forms'), and the scope ('on behalf of the user'). It distinguishes itself from sibling tools like list_forms by stating the prerequisite call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'call list_forms first to get the formId and field keys', providing clear usage context. It does not specify when not to use, but the context is clear enough for a specific action.
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!