Agenda SP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavior that no annotation could convey: the booking is not on the venue's calendar until payment completes, the slot is re-validated server-side and can be rejected as taken, and the contact email is unverified at this step. This directly shapes how an agent must present the result to a user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the critical 'NOTHING IS BOOKED UNTIL THE CUSTOMER PAYS' caveat, followed by prerequisites and the user-facing instruction. Every sentence carries information an agent would otherwise get wrong.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return value (checkout URL), the pre-call prerequisite, the post-call human action, and the failure mode (slot taken). It is complete enough to call correctly and to explain the result without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds meaning by explaining that startDate/endDate are re-validated against availability and that contact email is not treated as verified here. It does not explain the optional resourceId path, which keeps it below the top of the scale.

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?

States a specific verb and resource — booking an appointment slot at a venue (Wix Bookings) — and immediately clarifies the outcome (a checkout URL, not a confirmed booking). This distinguishes it from create_checkout and request_reservation rather than restating the name.

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?

Gives an explicit ordering prerequisite ('Call get_availability immediately before this') and a mandatory human follow-up ('Tell the user they must open the link'). It does not compare against alternatives such as request_reservation or create_checkout, so the routing guidance is strong but not complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive behavior, so safety is covered. The description adds a genuinely useful trait beyond that: slot times are returned in the VENUE's timezone, which is not necessarily the directory's — a non-obvious behavior an agent would likely get wrong.

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 short sentences, front-loaded with the purpose, then prerequisites, then the timezone caveat. No filler sentences and nothing redundant with structured 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?

With no output schema, the description carries return-value burden and does address the key return detail (slot times plus their timezone). It does not describe the shape of the slot list or behavior when no slots exist, which is a minor gap for an otherwise complete definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it names the source of serviceId (list_booking_services) and explains that place_slug must match the earlier call because it governs the returned timezone. That links a parameter to an observable output behavior rather than just restating 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?

States a specific verb and resource — 'Get available time slots for a bookable service on a given date' — and scopes it to Wix Bookings. This clearly separates it from list_booking_services, get_event_tickets, and the booking-creation 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 routes the agent to call list_booking_services first and reuse its serviceId and place_slug, which conveys the intended call sequence. It stops short of stating exclusions (e.g. what to do for multi-day ranges or unavailable dates), so it's clear but not fully exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare this as safe, read-only, idempotent, and non-destructive. The description adds useful return-value context by naming ticket names, prices, sale status, and remaining counts, though it does not discuss authorization or edge-case behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly written sentences with the action and scope front-loaded. Every phrase adds either workflow context or expected return information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, the description covers the required input source and summarizes the returned fields. Annotations already cover safety, so an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description repeats the schema's guidance that event_slug comes from list_events. It does not add format, validation, or example details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: get ticket types and prices for a specific event. It also names the return fields, making clear this is an information-retrieval tool rather than a booking or RSVP action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives the prerequisite that the event slug comes from list_events, which implies the workflow context. However, it does not explicitly say when to use this versus related siblings like reserve_event_tickets or get_availability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing the shape of the payload (program name, points currency name, tier structure with required points per tier), which is not in any structured field since there is no output schema. It stops short of covering auth requirements or behavior when loyalty is disabled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and scope, followed by the return fields. Nothing is redundant with the name and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining returns and it does so adequately by listing the three field groups. A minor gap remains around edge cases (e.g., site without a loyalty program), but for a zero-param read tool this is close to sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No spurious parameter talk clutters the definition.

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?

States a specific verb and resource ('Get the loyalty/rewards program details for this site') and names the backing product (Wix Loyalty). No sibling tool covers loyalty, so there is no ambiguity to resolve, and the description even enumerates the returned fields.

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?

Usage is only implied: an agent can infer it should call this when it needs loyalty program configuration. There is no explicit when-to-use/when-not framing, no mention of what to do if the program is not enabled, and no alternative named — but with zero parameters and one obvious purpose, little guidance is genuinely needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is settled. The description goes further with genuinely non-obvious behavior: `open_now` is precomputed (not raw hours the agent must reason over), `attributes` are slugs requiring resolution, and `delivery` deep-links match search_places output. It omits error behavior for an unknown slug, which keeps it off a 5.

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?

One sentence, front-loaded with verb + resource + identifying key before the field enumeration, so an agent can stop reading early if that's all it needs. The return-field list is dense but each item is a distinct piece of information rather than 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?

With one parameter, rich annotations, and no output schema, the description carries the return-shape burden and does so by enumerating the notable fields. What's missing is edge behavior (invalid/unknown slug) and any hint about cost or rate limits, but nothing essential to calling it correctly is absent.

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% — the single `slug` parameter has both a description ('URL slug of the place.') and an example. The description adds only the word 'URL slug' in prose, no format, casing, or sourcing guidance beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource ('Get full details for a specific place by its URL slug') followed by an explicit inventory of what the response contains. The mention that the `delivery` array is 'the same ... search_places returns' anchors it against the sibling list tool, so an agent can tell a single-record detail fetch from a search without opening the schema.

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?

Usage is only implied: the phrase 'by its URL slug' tells the agent it needs a slug, which signals a follow-up call after search_places. There is no explicit when-to-use / when-not statement and no named alternative for the detail-lookup case (search_places is referenced only as a format comparison, not as a routing alternative).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value by enumerating returned fields and implying a publication-status filter, but says nothing about pagination, ordering, or what happens when a site has no reviews.

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 short sentences with zero filler: the first defines scope and source, the second defines the payload. Nothing is buried or repeated.

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 one optional parameter, full schema coverage, annotations covering safety, and no output schema, the description supplies the missing return-shape information. Only the 'published' filter semantics and ordering behavior remain unstated.

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%: the single `limit` parameter documents its default (10) and maximum (50). The description adds no additional meaning about limit, so the schema carries the full burden and baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get published reviews for this site) plus the source system (Wix Reviews), so the agent knows exactly what it retrieves. It does not name any sibling for contrast, but no sibling in the list covers reviews, so confusion risk is low.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use framing, no prerequisites, and no exclusions. The only implicit guidance is the word 'published', which hints that unpublished/draft reviews are excluded but never states it outright.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, closed-world and non-destructive, so the safety bar is lower. The description still adds genuine value by disclosing the return shape (cinemas with session times, format, language) in the absence of an output schema, plus the movies_enabled dependency and a written-language detail (Dublado/Legendado).

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 short sentences: scope first, then return shape, then prerequisite. Every clause carries information and nothing is buried or repeated.

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 2-parameter read with no output schema, the description supplies the two things an agent cannot infer: what comes back and the site-level feature gate. Minor residual gaps (behaviour when movies_enabled is off, how 'this neighborhood' is resolved) keep it from a 5.

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 both parameters and the YYYY-MM-DD / today-BRT default are already documented. The description restates 'for a given date' and 'a specific movie' without adding format or edge-case semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (get showtimes) with scope: one movie, cinemas in this neighborhood, a given date. That makes the tool's job unmistakable. It does not name a sibling or contrast itself with a near-neighbour like get_availability, so it falls short of a 5.

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 prerequisite 'Requires movies_enabled on this site' is a real usage condition, and 'for a specific movie' implies a slug sourced elsewhere (list_movies appears only in the schema). There is no explicit when-not-to-use or alternative routing, so guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds useful payload disclosure: that time and weather are live/current values computed at call time rather than cached directory metadata, which is a behavioral trait the annotations do not convey. It doesn't mention freshness window or caching, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary return payload and finished with the concrete use cases. No filler and no repetition of the name.

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 parameters, no output schema, and annotations covering the safety profile, the description's job is to tell the agent what it will get — and it enumerates the returned fields including the two dynamic values an agent might not expect. Nothing needed to invoke it correctly is missing.

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?

Zero parameters, so per the baseline this sits at 4. The description correctly signals a no-argument call and adds nothing misleading about inputs.

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?

A specific verb (returns) plus a clearly bounded resource (basic site/neighborhood info), with an explicit enumeration of what comes back: name, locale, domain, description, canonical URLs, plus local time and current weather. No sibling tool overlaps this surface, so differentiation is unnecessary.

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 closing sentence gives concrete trigger conditions ("what time is it there", "what's the weather like"), which is stronger than a vague context hint. It stops short of stating when not to use it or naming an alternative, but no sibling actually competes for this job.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds substantial context beyond that: returned fields, the bookableViaMcp flag, the fact that services exist even for non-bookable venues, and what id=null means for create_booking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then layers in the critical parameter distinction and return-value caveat. It is somewhat dense and repeats the venue-vs-directory distinction, but every major sentence carries useful operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple annotations, the description covers the purpose, the key parameter behavior, return fields, and the booking limitation caused by bookableViaMcp=false. Nothing essential for correct invocation is missing.

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?

With one parameter and 100% schema description coverage, the baseline is 3. The description meaningfully expands on the schema by explaining that place_slug selects a venue rather than the directory site and that only this form's serviceId works with create_booking.

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?

States a specific verb and resource: listing a venue's services with price and duration. It clearly distinguishes the venue-specific form from the directory-site fallback, so an agent can immediately understand what this tool returns.

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 names search_places as the source for place_slug, says this is what you want in almost every case, and explains why omitting it usually returns unwanted directory-site services. It also ties the venue-specific serviceId to create_booking, giving clear guidance on when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them: events within 7 days carry a weatherForecast with condition and min/max temperature, and `agora` is resolved live per call rather than from a cached page. It does not discuss result freshness trade-offs or rate behavior, keeping it at 4.

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?

Front-loaded with the core action and returned fields, then usage and the weather-forecast detail. Mostly efficient, though the closing clause 'which no cached page can do' is mildly promotional rather than 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?

There is no output schema, so the description must carry the return shape — it does by naming date, venue, price, URL, and the weatherForecast structure. With only three optional parameters and full schema coverage, this is nearly complete; a brief note on ordering or result count behavior would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, filter enum values, and upcoming_only in detail. The description restates the `filter` purpose and the live-resolution behavior of `agora`, which adds some intent but largely overlaps the enum descriptions — 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?

States a specific verb and resource ('List upcoming events in this neighborhood') and enumerates the returned fields (date, venue, price, URL, plus weatherForecast), so an agent can distinguish it from ticket-oriented siblings like get_event_tickets or reserve_event_tickets without opening a schema.

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?

Gives concrete usage context: pass `filter` to narrow by time or price, and `filter: "agora"` is framed around the specific question 'what can I go to right now'. It does not explicitly name sibling alternatives (get_event_tickets, rsvp_event) or state when not to use this tool, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safe, idempotent, closed-world read profile, so the description only needed to add context. It does so by disclosing that the full set is returned ('all') and that results come grouped by category — return-shape information the annotations do not provide. Absent any note on result size or pagination, it stops short of 5.

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 short sentences with zero padding: scope and return grouping first, intended use second. Every clause carries information the agent needs.

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 parameters and no output schema, the description adequately covers what the call returns (Q&A pairs, grouped by category) and why to call it. The only omitted detail is rough result volume or whether large sites paginate.

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 takes zero parameters, so the baseline is 4. The description correctly implies no filtering input is needed by framing the call as fetching the whole FAQ set for the site.

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?

States a specific verb and resource: 'Get all FAQ questions and answers for this site (Wix FAQ)'. No sibling tool covers FAQs, so the agent can distinguish it without opening the schema, though it does not explicitly contrast with any list_* sibling.

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?

'Use this to answer common questions about the site — opening hours, parking, policies, etc.' gives a concrete use case with examples, which is stronger than implied usage. It stops short of naming exclusions or alternatives, but no plausible alternative exists among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and non-destructive behavior, so safety is covered. The description earns credit by disclosing what the call actually returns (form name, ID, field definitions with label/type/required), which matters since there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences and no wasted words. The purpose is front-loaded, and the return contents and the submit_form handoff follow immediately.

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?

There is no output schema, so the description has to carry the return shape, which it does (name, ID, field definitions with label/type/required). Notes on permissions or pagination are missing, but for a simple read-only enumeration that is not a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is an empty object, so there is nothing to disambiguate. The description correctly implies no input is required and adds the useful note that field definitions come back in the response.

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?

States a specific verb (List) plus resource (contact/signup forms) and scopes it to this site, naming the underlying product (Wix Forms). This clearly distinguishes it from siblings like list_profiles or list_categories because it says exactly what kind of forms are returned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final clause gives explicit sequencing guidance: call this before submit_form to learn which fields to fill. That is a concrete when-to-use rule tied to a named sibling, though no when-not-to-use condition is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive behavior, so the description focuses on what is returned: now-showing films with local showtimes, coming-soon films, streaming availability, and key metadata fields. It adds the site feature-gate constraint but does not describe pagination or ordering behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three compact sentences: scope is front-loaded, followed by return categories and included fields. Every sentence contributes useful information without repetition 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?

With no output schema, the description appropriately explains the return composition and included fields. Combined with fully documented parameters and safety annotations, it is nearly complete, though it omits details like result ordering or pagination behavior beyond the limit parameter.

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 both parameters are already fully documented in the input schema. The description mentions the return categories that correspond loosely to the status enum but does not add syntax, defaults, or other meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('List movies') and clearly scopes it to a neighborhood and sites with movies_enabled. It does not explicitly differentiate from siblings such as get_showtimes, though the catalog-focused framing is reasonably 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?

The site prerequisite ('only on sites with movies_enabled') is useful context, and the return categories imply when to use the tool. However, it does not state when to use this instead of get_showtimes or other sibling tools, leaving alternatives implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations by explaining the data-scope effect of omitting `place_slug` and by listing the returned fields such as billing cycle and checkout URL.

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 tightly structured sentences: purpose first, then parameter guidance, then return contents. There is no filler, and the most important usage constraint is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single optional-parameter, read-only list tool, the description covers purpose, usage condition, omission behavior, and return fields. With annotations handling safety and no output schema needed, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already calls `place_slug` strongly recommended. The description adds meaning by tying it to `search_places`, giving venue examples, and emphasizing that omitting it returns the directory's own plans rather than a venue's.

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?

States a specific verb and resource ('List membership or subscription plans') and clarifies the Wix Pricing Plans context. It also distinguishes the two possible scopes — venue plans vs. directory-site plans — so an agent can tell exactly what this tool returns.

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 to pass `place_slug` from `search_places` and that this is 'what you want in almost every case.' It also names the fallback behavior when the parameter is omitted, giving clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the full two-phase flow: the restaurant is not notified until the guest clicks the emailed link, the link expires in 24 hours, and the link is deliberately withheld from the agent. These are critical behavioral facts not derivable from the annotations, and they are consistent with readOnlyHint=false and destructiveHint=false.

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?

Front-loaded with the core action and the most surprising fact (no notification yet), followed by operational instructions. The "request, not a confirmed booking" sentence partially restates the opening caps-lock warning, a small redundancy, but every other sentence carries non-obvious information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation with no output schema, the description covers the critical gaps: side effects, the out-of-band confirmation, link expiry, and why no confirmation handle is returned. It does not say what the tool actually returns on success (e.g. request id or pending status), leaving that to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds meaning by constraining email to "a real address belonging to the person you are acting for" and explaining that the confirmation link goes there and is not returned to the caller. It adds nothing about place_slug, requestedAt, or partySize 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?

Opens with a specific verb+resource ("Request a table at a restaurant") and immediately scopes it against the confirmed-booking sibling by stating "This is a request, not a confirmed booking." An agent can distinguish it from create_booking without opening either schema.

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?

Gives clear operating context: use the acting user's real email, tell them to check their inbox, link expires in 24 hours, and the restaurant confirms out of band. It never names create_booking explicitly as the alternative for a confirmed booking, so the routing is implied rather than spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the critical semantic that the hold is temporary, nothing is paid, the tickets are not the user's until a human completes checkout, and the hold auto-expires. That is exactly the behavior an agent needs beyond the structured hints.

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?

Front-loads the action and the single most consequential caveat (temporary, unpaid hold), then limits, then the out-of-scope fallback. No filler sentences; capitalization is used deliberately for the risk that matters most.

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, yet the description tells the agent the call returns a checkout URL — the one return value that matters. Combined with the hold semantics, scope limits, and the per-item ID sourcing from get_event_tickets in the schema, an agent has everything needed to 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 description coverage is already 100%, so the baseline is 3. The description adds a real constraint not present in the schema — the 10 ticket / 10 ticket-type cap per reservation — which meaningfully shapes how the tickets array must be populated.

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?

States a specific verb+resource ('Hold tickets for an event sold through this site') plus the return value (a checkout URL), and names the platform (Wix Events). It is clearly distinguishable from siblings like rsvp_event, create_checkout, or get_event_tickets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly defines the boundary condition: works only for events this site sells directly, and directs the agent to the event's own ticketUrl for events sold elsewhere (Sympla, Ingresse, Sesc). It also states the hard limits (max 10 tickets / 10 ticket types), so the agent knows when not to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the full non-obvious mechanic that annotations cannot convey: nobody is on the guest list, a confirmation email is sent, the RSVP only commits after the recipient clicks, the link expires in 24 hours, and the link is deliberately not returned. This is exactly the behavioral context an agent needs to avoid telling a user the RSVP succeeded.

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 critical warning is front-loaded and every sentence carries an instruction (flow, expiry, inbox prompt, email constraint). The all-caps emphasis and the slightly redundant 'Tell the user to check their inbox' cost it a little polish but not clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation with no output schema, the description covers the whole commitment flow and the key caveat that the confirmation link is not returned. It leaves open what the call itself returns (presumably a pending/unconfirmed status), which would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, and the description adds a real constraint beyond the schema: the email must belong to the person being acted for, and it is where the confirmation link goes. It does not elaborate on event_slug beyond the schema's 'from list_events' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('RSVP to a free event on this site (Wix Events)') and scopes it to free events, which implicitly separates it from paid-ticket siblings. It never names reserve_event_tickets or request_reservation explicitly, so an agent must infer the boundary itself.

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?

Gives concrete operational guidance: use a real address belonging to the person you act for, tell the user to check their inbox, and note the 24-hour expiry. It lacks an explicit 'use this instead of X when Y' comparison against the sibling reservation tools, which keeps it off a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already covering the safety profile (readOnly, idempotent, closed-world), the description still adds substantial behavior: accent-insensitive and typo-tolerant matching with worked examples, relevance ranking, and the ALL-must-match semantics for attributes. It also discloses the full result shape — precomputed open_now, attributes array, curated delivery deep-links per platform, rating, and Google Maps-style hours with day/time encoding — which is critical since no output schema exists.

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?

Front-loaded with purpose, then match semantics, then filter composition, then return shape — a sensible progression. The closing sentence is dense (six distinct return fields in one breath) but every clause carries information an agent needs given the absent output schema.

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?

Six optional parameters with no output schema, so the description must carry the return-value burden — and it does, enumerating open_now, attributes, delivery links, rating, and hours structure. Combined with filter-composition guidance, nothing an agent needs to call this correctly is missing.

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 every parameter is already documented in structured form, and the description largely restates it (open_now = open at this exact moment, attributes = ALL must match, accent/typo tolerance for q). The one addition — that amenity slugs are listed on the attributes parameter — is marginal. 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?

Opens with a specific verb+resource+scope: 'Search for places (restaurants, cafes, shops, etc.) in this neighborhood.' The parenthetical examples and neighborhood scoping make the domain unmistakable. It never names the adjacent siblings (get_place for a single place, search_dishes for menu items), so it falls short of a 5.

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?

Offers one genuine usage cue — 'Compose filters for multi-condition queries' — which tells the agent how to combine parameters. But there is no when-to-use/when-not guidance and no mention of get_place or search_dishes as alternatives, so the agent must infer the routing itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare non-read-only, non-idempotent, non-destructive behavior, so the safety profile is covered. The description adds that it acts on the user's behalf and that a submissionId is returned, but says nothing about side effects (notifications, email confirmations) or what happens with unknown field keys — context that matters for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the prerequisite, then the return value. No filler and nothing repeated from the title or schema.

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 two-parameter tool with a nested object and full schema coverage, the definition covers action, prerequisite, and return value. It could still clarify failure behavior (malformed/unknown field keys) and whether submissions are visible elsewhere, but the essentials are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both formId and fields are documented in the schema, including an example of the key-value shape. The description only restates that formId and field keys come from list_forms, adding no syntax or validation detail 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?

States a specific verb (Submit) and resource (a form, Wix Forms) and scopes it as acting on behalf of the user. It also names the prerequisite discovery tool (list_forms), which separates it from the many read/list siblings in this toolset.

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?

"Call list_forms first to get the formId and field keys" gives an explicit ordering constraint and names the alternative to use for discovery. It stops short of saying when NOT to use this (e.g., previewing a form, editing an existing submission), so it is not a full when/when-not pair.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.