Vila Madalena

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

With no annotations provided, the description discloses critical behaviors: booking isn't final until payment, returns a checkout URL, server-side slot re-validation, and email not verified. This fully informs the agent of important side effects and 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 concise, front-loading the purpose and critical warning. Every sentence adds necessary information without redundancy. It efficiently conveys the workflow and constraints.

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 complexity (6 params, nested object, no output schema), the description covers all essential aspects: pre-requisite call, return value, behavior, and validation. It provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that contact fields are required by the venue, that startDate/endDate must match get_availability output, and the source of serviceId and place_slug. This enhances understanding 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 'Book an appointment slot at a venue (Wix Bookings)' and emphasizes the non-final nature of the booking. It distinguishes the tool from siblings by specifying that it returns a checkout URL and must be preceded by get_availability.

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

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

The description explicitly instructs to 'Call get_availability immediately before this' and informs the user they must open the checkout link. It notes that the slot is re-validated and contact email not verified. While it doesn't mention alternatives, the guidance is clear and actionable.

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 that the tool generates a URL for user payment, but does not specify side effects, permissions, or return structure. No annotations present to compensate.

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

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

Two sentences, no wasted words, front-loaded with the core 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?

No output schema, so description should explain the return value. Implies a URL is returned but does not explicitly state it. Lacks behavioral details given no annotations.

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 only adds 'one or more store products' and payment context, not adding significant meaning beyond the schema.

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

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

Clearly specifies the verb 'create' and resource 'checkout URL' for Wix Stores. Distinguishes itself from sibling tools like list_products and create_booking by focusing on payment checkout.

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

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

States 'no login required on the AI agent side' which guides authentication expectations. However, lacks explicit when-not-to-use or alternatives.

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

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

No annotations provided, but the description discloses behavioral traits: returns slot times in the venue's timezone, dependent on list_booking_services for serviceId and place_slug. Could add more on failure cases, but sufficient.

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

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

Two well-structured sentences, all information relevant. Slightly dense but clear and efficient.

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

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

For a simple query tool with good schema coverage and no output schema, the description covers purpose, parameter usage, and an important timezone nuance. Complete for its complexity.

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

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

Schema description coverage is 100%, so the schema already defines parameters. The description adds context about source of serviceId and timezone for place_slug, but does not add significant new meaning beyond schema.

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

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

The description clearly states 'Get available time slots for a bookable service on a given date' with a specific verb and resource, and it naturally distinguishes from sibling tools like create_booking and list_booking_services.

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

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

Explicitly tells when to use (to get time slots), instructs to pass serviceId from list_booking_services, date format YYYY-MM-DD, reuse place_slug from list_booking_services, and notes timezone behavior. Provides clear context and precondition.

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?

No annotations are provided, so the description takes full responsibility. It mentions returning ticket names, prices, sale status, and quantity left, indicating a safe read operation. It does not mention authorization or side effects, but the read nature 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 sentences, first for purpose, second for usage and return value. No wasted words, front-loaded with key 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, the description fully explains the return data. Single parameter is well-documented. The tool is simple and completely described.

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 single parameter description. The description reinforces the schema but adds no new semantics beyond 'from list_events'. 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 gets ticket types and prices for a specific event, using 'get' and specifying the resource. It distinguishes from siblings like 'reserve_event_tickets' by focusing on reading data.

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

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

It instructs to pass the event slug from list_events, providing a prerequisite. It does not explicitly exclude alternatives or give when-not-to-use advice, but the context is clear.

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

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

With no annotations, the description effectively discloses the read-only nature and the specific data returned. It does not cover potential missing data scenarios or authorization needs, but for a zero-parameter getter, the transparency is sufficient.

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

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

The description is a single, well-structured sentence that front-loads the action ('Get') and efficiently conveys the purpose and return values without unnecessary words.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers the essential return fields. It could mention potential absence of loyalty program, but overall it provides enough context for an agent to use the tool correctly.

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

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

The tool has no parameters, and schema coverage is trivially 100%. The description correctly adds no parameter details, as none exist. Baseline for zero parameters 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 retrieves loyalty/rewards program details for the site, specifying the exact information returned (program name, points currency, tier structure). It distinguishes itself from sibling tools like get_site_info or get_place by focusing on a specific domain.

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

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

The description implies usage context (when needing loyalty details) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. Given the tool's simplicity, this is adequate but not exemplary.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns opening hours, ratings, address, and neighborhood, indicating a read-only operation. However, it does not mention error handling (e.g., invalid slug) or any side effects, but for a simple get operation, this is acceptable.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and then lists key details. No wasted words.

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

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

For a simple get-by-slug tool with one parameter and no output schema, the description is fairly complete. It specifies the input (slug) and the output fields. It could mention error behavior (e.g., 404 on missing slug), but this is not critical for a basic read tool.

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

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

Schema description coverage is 100%, so the schema already documents the slug parameter with an example. The description reiterates 'by its URL slug' but adds no new semantics beyond reinforcing the parameter's purpose. Baseline 3 is appropriate.

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

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

The description explicitly states it gets full details for a specific place by URL slug, listing specific fields (opening hours, ratings, address, neighborhood). This clearly distinguishes it from sibling tools like search_places or 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?

The description implies usage when you have a specific URL slug and want full details. It distinguishes from search_places (which is for searching) but lacks explicit when-not-to-use or alternative guidance. The context from sibling names helps, but the description itself could be more explicit.

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?

No annotations are provided, so the description carries the full burden. It states that menus are returned with specified details, implying a read-only operation. While it doesn't explicitly disclose read-only or other behaviors, the description is not misleading and gives a clear idea of what the tool does.

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

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

The description is two sentences long, each serving a clear purpose: the first states the function and return value, the second gives usage guidance. There is no redundant information.

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

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

Given the tool has one required parameter and no output schema or annotations, the description adequately covers what the tool does and how to use it. It explains the return content and prerequisite steps, which is sufficient for a straightforward retrieval tool. Minor omission of error handling is acceptable.

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

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

The schema already describes the place_slug parameter, but the description adds an example ('bar-do-ze') and clarifies the source (from search_places or a place URL), providing additional context that helps an agent correctly invoke the tool.

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 the food menu for a specific restaurant, including sections, dishes, descriptions, prices, and dietary labels. This specific verb+resource combination effectively distinguishes it from siblings like search_dishes or get_place.

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 use search_places or list_categories first to obtain the place_slug, providing clear prerequisite and usage context. It implies when to use this tool without needing exclusions.

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?

No annotations exist, so the description must convey behavioral traits. It only mentions returning specific fields and implies a read operation, but does not explicitly state read-only nature, authentication needs, rate limits, or whether unpublished reviews are included.

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

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

Two efficient sentences: first defines the action and resource, second lists output fields. No filler, every sentence adds value.

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

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

As a simple list tool with one parameter and no output schema, the description covers purpose and return fields. However, missing behavioral context (e.g., ordering, filtering, pagination) and lacks any mention of read-only safety or usage limitations.

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

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

The single parameter 'limit' is fully documented in the schema (coverage 100%). The description adds meaning by specifying the returned fields, which provides context for how the parameter affects results.

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

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

Clearly states the action 'Get' and resource 'published reviews for this site', listing exact return fields (reviewer name, rating, title, content). Differentiates from sibling tools that handle bookings, events, products, etc.

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

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

While the purpose is clear, the description provides no guidance on when to use this tool versus alternatives (e.g., list_products) or any prerequisites. Only implied use case from the tool name.

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 no annotations provided, the description fully informs about the tool's behavior: it returns cinema details with session times, format, and language. It also notes a prerequisite (movies_enabled), which is a behavioral constraint. No contradictions.

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

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

Two sentences efficiently convey purpose, scope, and prerequisite. No redundant or vague wording; every detail 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?

The description covers the tool's main function, parameters, and output fields (cinema, times, format, language). Without an output schema, it adequately explains the return structure. Minor omissions like error handling or timezone are acceptable for a simple tool.

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

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

Schema description coverage is 100%, but the description adds valuable context: movie_slug comes from list_movies, date defaults to today (BRT). It also enriches understanding by describing the output (format, language) not present 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 uses specific verb 'Get' and resource 'showtimes', clearly distinguishing it from siblings like list_movies (which lists movies) and get_event_tickets (different domain). It explicitly states the scope: for a specific movie, cinemas in this neighborhood, and a given date.

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 after obtaining a movie slug from list_movies, but does not explicitly state when to use versus alternatives or when not to use. It mentions a prerequisite ('Requires movies_enabled on this site') but lacks exclusions or alternatives.

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?

No annotations provided, so description carries full burden. It enumerates returned fields but does not disclose any non-obvious behaviors (e.g., caching, rate limits, idempotency). For a simple read operation, transparency is adequate but not exceptional.

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

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

Two sentences, no waste. First sentence lists outputs, second gives usage guidance. 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?

No output schema, but description lists key return fields. Could be more precise about format or structure (e.g., weather object shape), but sufficient for a simple info retrieval 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?

No parameters (0), so schema coverage is 100%. Baseline is 4 per rubric. Description adds value by detailing the response fields, compensating for lack of output schema.

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

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

The description clearly states it returns basic information about the neighborhood directory, listing specific items (name, locale, domain, description, canonical URLs, local time, current weather). It is distinct from sibling tools which focus on bookings, events, etc.

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

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

Explicitly specifies use cases: 'for any 'what time is it there' or 'what's the weather like' context.' While it doesn't give when-not or alternatives, the context is clear and helpful for an agent.

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?

No annotations provided, so description carries full burden. It notes 'recent' and 'published' but lacks details on sorting, pagination, or authentication needs.

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

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

Single sentence efficiently conveys purpose and return fields with 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?

Returns fields are listed, constraints noted, but missing sorting order and pagination behavior. Still adequate for a simple list tool with optional params.

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

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

Schema coverage is 100% with clear descriptions for limit and category. The description adds no extra parameter meaning beyond the schema.

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

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

Description clearly states the tool lists recent published blog posts for the Wix Blog site and specifies the return fields, distinguishing it from sibling tools.

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

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

The description implies usage for retrieving blog posts, but no explicit when or when-not guidance. Given no overlapping siblings, it is reasonably clear.

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 no annotations, the description provides comprehensive behavioral details: services are listed for EVERY venue (even those without online booking), the bookableViaMcp flag indicates bookability, and when false, id is null and create_booking cannot be used. This goes beyond basic input/output.

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 moderately long but every sentence conveys important information. It is front-loaded with the main purpose and then explains parameter usage and behavior. Minor redundancy could be trimmed.

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 single parameter and no output schema, the description fully covers parameter semantics, return fields, edge cases (non-bookable venues), and actionable guidance. Sibling tools are listed but not referenced, but the description is self-contained.

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

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

The input schema has one parameter with description. The description adds context: place_slug should come from search_places, it specifies what listing a venue's services vs. directory services means, and that the parameter is strongly recommended. This adds value beyond the schema's description.

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

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

The description clearly states the tool lists a venue's services with price and duration. It distinguishes between listing services for a specific venue (with place_slug) vs. the directory's own services (without), and mentions returned fields. This is specific and 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 gives explicit guidance: use place_slug from search_places in almost every case, and if omitted it lists directory services which most sites don't have. It also directs the user to point to bookingUrl or venue page when bookableViaMcp is false. However, it does not explicitly compare with sibling tools like get_place 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?

With no annotations, the description carries full responsibility for behavioral disclosure. It only describes output content and does not mention read-only status, authentication needs, rate limits, or potential 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 a single, direct sentence that front-loads the main purpose. Every word is informative 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 no parameters, no annotations, and no output schema, the description adequately covers the output content but lacks details on format, pagination, or computation of counts. It meets minimum viability but leaves room for improvement.

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 (schema coverage 100%), so the description adds significant value by detailing the output structure (top-level groups, subcategories, labels, types, counts). This is a strong addition beyond the empty 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 returns the full category taxonomy, specifying details like top-level groups, subcategories, localized labels, schema.org types, and live place counts. This distinguishes it from sibling list tools that target different resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context such as whether this is the primary tool for browsing categories.

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?

No annotations are provided, so the description carries the full burden. It transparently discloses that events within 7 days include a weather forecast and that the `'agora'` filter is resolved live, not from cache. This adds valuable behavioral details beyond basic functionality.

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

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

The description is concise and front-loaded, starting with the core purpose. Every sentence adds value without redundancy. It efficiently conveys all necessary information in a few lines.

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

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

The description covers the output fields, special weather forecast, and filter behavior. It lacks explicit details on pagination or ordering, but given the parameter descriptions in the schema and the tool's straightforward nature, it is reasonably complete.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning beyond the schema by explaining the effect of the `filter` parameter with concrete examples and clarifying special cases like `'agora'` excluding season-based sources. It also hints at output structure with weather forecast.

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 that the tool lists upcoming events with specific fields (date, venue, price, URL) and highlights a special weather forecast feature for events within 7 days. It distinguishes from sibling tools like reservation or ticket tools by focusing on listing rather than 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 on using the `filter` parameter to narrow by time or price, with examples like `'agora'` for current events. It explains that `'agora'` is resolved live, which is a key usage tip, but does not explicitly discuss when to use this tool vs. alternatives.

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 no annotations provided, the description must carry the full burden of behavioral disclosure. It correctly indicates a read-only operation returning all FAQs grouped by category, but does not mention any potential pagination, rate limits, or authentication requirements. For a simple list tool this is adequate 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 two sentences long, front-loads the core purpose, and contains no filler. Every sentence adds value: first sentence defines the resource and grouping, second sentence gives usage context.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers all necessary aspects: what it does, how results are organized (grouped by category), and when to use it. No gaps are apparent.

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

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

The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter details. According to guidelines, the baseline for high coverage is 3, and the description adds no parameter semantics beyond what the schema already implies.

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

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

The description uses a specific verb (Get) and resource (FAQ questions and answers), explicitly notes grouping by category, and gives concrete usage examples (opening hours, parking, policies). This clearly distinguishes it from sibling tools like get_site_info or list_blog_posts.

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

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

The description clearly states when to use the tool: 'Use this to answer common questions about the site'. However, it does not explicitly mention when not to use it or provide alternatives among the many sibling tools, which would improve clarity.

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 description discloses that the tool returns form metadata (name, ID, field definitions) and implies a read-only operation. No annotations are provided, but the description fully carries the burden by stating what the tool does and does not do (e.g., no destructive actions). It is transparent and sufficient.

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

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

The description is two sentences long with no redundant words. It front-loads the purpose and then provides essential context about usage and return value. 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?

Given the tool's simplicity (no parameters, no output schema), the description covers all necessary information: what the tool returns, its relation to a sibling tool, and the platform. It is complete for an agent to correctly invoke and interpret the tool.

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

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

The input schema has zero parameters, so schema coverage is trivially 100%. Per guidelines, baseline is 4 when no parameters exist. The description does not need to add parameter semantics, and it provides no extra detail beyond the schema, 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?

The description clearly states the tool lists available contact/signup forms, specifies the platform (Wix Forms), and enumerates what it returns. The verb 'list' combined with 'forms' makes the purpose unambiguous, and it is distinct from sibling tools which focus on other entities.

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

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

Explicitly instructs the user to use this tool 'before submit_form to discover which fields to fill.' This provides clear when-to-use context and directly guides the agent to the appropriate preceding action, fully addressing usage guidelines.

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?

No annotations are provided, so the description must fully cover behavioral traits. It mentions that guides are 'ranked places with editorial notes' suggesting a read-only listing, but lacks details on ordering, pagination beyond the limit parameter, authentication needs, or potential 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 two sentences: the first explains the tool's functionality, the second provides a concrete use case. Every word earns its place 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?

Considering the tool is a simple listing with one optional parameter and no output schema, the description adequately covers what the tool returns (guides with editorial notes) and its primary use case. It could mention whether guides are filterable by location or category, but overall it is nearly complete.

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

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

The input schema covers the single parameter 'limit' with its default and max, achieving 100% schema coverage. The description does not add extra semantic information about the parameter beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states it lists curated editorial guides ('best of' lists) with ranked places and editorial notes, distinguishing it from sibling list_* tools like list_blog_posts or list_events. It also specifies the use case for neighborhood recommendations.

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 context: 'the best source for best X in this neighborhood questions'. However, it does not explicitly exclude alternatives or state when not to use this tool compared to search_places or other list tools.

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?

No annotations provided, but description adequately discloses functionality (listing movies, filters, returned data) and a constraint (only on sites with movies_enabled). Lacks mention of pagination/ordering, but 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 concise sentences with no redundancy. Front-loaded with purpose and key details.

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

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

Given no output schema, the description lists return fields. Covers main use cases and the important constraint. Complete for a list operation with simple parameters.

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

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

Schema coverage is 100% with good parameter descriptions. The tool description adds context by explaining the meaning of status values in more detail, exceeding the baseline.

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

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

The description clearly states the tool lists movies with specific categories (now-showing, coming-soon, streaming) and includes return fields. It distinguishes from sibling tools by focusing on movie listings.

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?

Implied usage: use when wanting to browse available movies. No explicit when-not-to or alternatives, but context is clear given sibling tools like get_showtimes.

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?

No annotations are provided, so the description carries the full burden. It discloses return fields and FLASH deadlines, but lacks details on pagination, ordering, or whether inactive offers are excluded (though 'active' is mentioned). It adds some value beyond the schema but is not comprehensive.

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

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

The description is three sentences, front-loaded with purpose, then return fields, then a notable feature (FLASH countdown). Every sentence earns its place with no wasted words.

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

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

Given 2 optional parameters, no output schema, and no annotations, the description is fairly complete: it tells what the tool returns, that offers are active, and the filtering option by kind. However, it does not mention ordering, default sort, or any required location context.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; it only mentions FLASH in context, but the schema already describes the kind enum. No extra value is provided for the limit 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 tool lists 'active promotions and deals' in a neighborhood directory, with specific return fields (discount label, promo code, CTA link, validity window, business/place). It also explains the special FLASH offer type, which distinguishes it from sibling tools like list_products or list_events.

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

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

The description implies usage for browsing offers but does not explicitly state when to use vs. alternatives like list_products or get_loyalty_info. No 'when not to use' guidance is provided, leaving the agent to infer from context.

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?

No annotations are provided, so the description carries the burden. It explains it returns plan details and a checkout URL, which is helpful, but does not disclose if there are any limitations, caching behavior, or if the list is filtered (e.g., only active plans).

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. It front-loads the purpose ('List membership or subscription plans') and provides essential return information concisely with no wasted words.

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

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

Given no output schema and no parameters, the description adequately covers what the tool does and what it returns. It could be improved by noting whether the list is exhaustive or if pagination applies, but it is mostly complete for a simple list operation.

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

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

There are zero parameters and schema coverage is 100%. The description adds value by listing the specific fields returned (name, price, billing cycle, perks, checkout URL), which helps agents understand the output beyond the empty schema.

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

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

The description clearly states the tool lists membership/subscription plans, specifying the resource ('pricing plans') and the verb ('list'). It distinguishes from sibling tools like 'list_products' or 'list_booking_services' by focusing on pricing plans.

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

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

The description implies usage when one needs to retrieve pricing plans but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer from sibling tool names.

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 no annotations, the description carries full behavioral disclosure burden. It states the tool returns specific fields, which is helpful. However, it does not explicitly confirm it is read-only, mention pagination behavior beyond the limit parameter, or disclose any edge cases (e.g., empty store). Still, the core behavior is transparent for a simple list operation.

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

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

The description is two sentences, front-loading the action and context. Every word earns its place; there is no redundant or verbose phrasing. Excellent structure for quick parsing.

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

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

Given no output schema and no annotations, the description is reasonably complete for a list tool. It specifies return fields and store context. It could mention response format (e.g., array) or error handling, but the essential information is present for an agent to understand what the tool does and what 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?

Schema coverage is 100%, and both parameters are already described clearly in the schema. The description adds no new semantic meaning beyond repeating the schema's description for the 'q' parameter and omitting the 'limit' parameter entirely. 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 tool lists products in a Wix Stores site, naming specific return fields (name, price, stock status, product type). The verb 'List' and resource 'products' are explicit. The description distinguishes it from sibling list tools (e.g., list_blog_posts) by specifying the store context.

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 store products but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or scenarios where another tool (e.g., search_dishes) might be more appropriate, leaving the agent to infer.

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 return fields (name, URL, category, metadata) and nature of profiles, but omits pagination, ordering, or any side effects. No annotations provided.

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

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

Single sentence conveying core purpose and return data; 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?

Adequate for a simple list tool, but missing details like pagination, sorting, and error behavior given no output schema or annotations.

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

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

Schema covers the only parameter fully. Description adds no extra parameter insight beyond what 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?

Clearly specifies verb 'List', resource 'solo service-provider profiles', and distinguishes from siblings by defining the niche (businesses without fixed location).

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 contextual clues about when to use (listing specific profile type) but lacks explicit when-not or alternative tool references.

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 no annotations, the description fully discloses behavior: the restaurant is not notified immediately, a confirmation email is sent with a 24-hour expiry, the link is not returned, and the restaurant confirms out of band. This provides complete transparency beyond what any annotations would cover.

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

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

The description is concise: three to four sentences, each carrying essential information. It is front-loaded with the purpose and efficiently conveys the critical workflow and constraints 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 complexity (7 parameters, no output schema), the description covers the key workflow: it is a request, not a booking; email confirmation with expiration; and out-of-band confirmation by the restaurant. It could mention what happens if the email link expires or is not clicked, but the current information is nearly complete.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal extra meaning to parameters beyond the schema; for example, it reiterates that the email must be real and that the confirmation link is not returned, but these are behavioral rather than semantic parameter details. The schema already explains each parameter adequately.

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: 'Request a table at a restaurant.' It distinguishes this as a request, not a confirmed booking, and explains the workflow involving a confirmation email. This differentiates it from siblings like create_booking, which would imply a direct 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 clear guidance on when to use the tool: to request a table, and it emphasizes that it is not a confirmed booking. It instructs the user to use a real email address and to check their inbox. While it does not explicitly name alternative tools, the context implies that create_booking is for confirmed bookings.

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 no annotations, the description fully carries the transparency burden. It clearly states the hold is temporary, nothing is paid, the hold expires, and a checkout URL is returned. This provides sufficient behavioral context for an agent to understand the tool's side effects and lifecycle.

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

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

The description is two sentences with an important caveat in caps. It front-loads the main purpose, then adds constraints and alternatives. While not extremely terse, it is concise and easy to parse. No extra fluff.

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

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

Given the tool's complexity (2 required params, no output schema), the description covers the essential workflow: hold tickets, return URL, temporary nature, expiration, and exclusion of external events. It does not discuss error scenarios or auth, but for this purpose 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%, so baseline is 3. The description adds value by explaining the constraint 'Max 10 tickets and 10 ticket types per reservation' which applies to the 'tickets' parameter, as well as the workflow outcome (checkout URL). This goes beyond the schema's property descriptions.

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

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

The description starts with a clear verb-resource pair ('Hold tickets') and explicitly mentions the return value (checkout URL). It also distinguishes this tool from siblings by specifying it only works for events sold through this site, with an explicit alternative for external events.

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

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

The description provides explicit when-not-to-use guidance: for external events (Sympla, Ingresse, Sesc), use the event's own ticketUrl. It also states max limits (10 tickets, 10 ticket types) and clarifies the temporary nature. It does not directly compare to sibling tools like create_booking or request_reservation, but the context is clear enough.

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 no annotations, the description fully discloses key behaviors: the RSVP is not immediate, the confirmation link is not returned, and the user must tell the person to check their inbox. This covers all necessary behavioral traits.

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

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

The description is a single paragraph but efficiently packs essential information. It is front-loaded with the main purpose and could be more structured, but no wasted words.

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

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

Given no output schema, the description explains what does not happen (no link returned) and implies the return is minimal. It references sibling tool list_events for context, providing complete guidance for the tool's use.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description adds context like 'the guest's own email' and references list_events for event_slug, slightly enriching the semantics beyond the schema.

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

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

The description clearly states 'RSVP to a free event on this site (Wix Events)', specifying the action and resource, and distinguishes from siblings like reserve_event_tickets (likely for ticketed events).

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

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

The description explicitly explains the flow: a confirmation email is sent, the RSVP only completes when the link is clicked, and the link expires in 24 hours. It instructs the user to check their inbox and use a real address, providing 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?

The description details what the tool returns (price, description, dietary labels, place URL) and how it groups results. With no annotations, it adequately discloses the read-only search behavior, though it omits error handling or rate limits.

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) with a clear, front-loaded statement of purpose and an illustrative example. 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?

Given the absence of an output schema and the tool's simplicity, the description covers the return format and parameter semantics thoroughly. It is complete for a search tool.

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

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

Schema coverage is 100%, but the description adds value beyond the schema: it explains the 'query' parameter with an example and notes that omitting it lists top dishes, enhancing understanding.

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

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

The description clearly specifies the tool's purpose: finding restaurants serving a dish, with a concrete example. It distinguishes from sibling tools like search_places by focusing on menu items across restaurants.

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 states when to use (e.g., 'where can I eat X' questions) and provides guidance on omitting query to list top dishes. However, it does not explicitly mention when not to use this tool or suggest alternatives.

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 accent-insensitivity, typo-tolerance, relevance ranking, and opening hours format. No annotations provided, so description carries full burden—good coverage but missing response structure details beyond opening hours.

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 clear purpose, examples, and technical details (opening hours format). Efficient and well-structured, no wasted words.

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

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

No output schema, so description must explain return values. Describes opening hours format but omits other fields (name, address, rating, etc.). For a search tool with 4 optional params, more detail on response 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?

All 4 parameters have descriptions in schema (100% coverage). Description adds behavioral nuances: q is typo-tolerant, category/neighborhood are substring matches, limit defaults to 20 max 100. Adds meaning 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 'Search for places' with examples (restaurants, cafes, shops) and uses specific verb+resource. Distinguishes from sibling tools like get_place (specific place) and search_dishes (dishes only).

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

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

Implies usage when searching for places by text in a neighborhood, but no explicit when-to-use or when-not-to-use compared to alternatives like get_place or search_dishes. No exclusion criteria or prerequisites.

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

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

No annotations provided, so description must carry transparency. It discloses that it returns a submissionId on success, but lacks details on error handling, idempotency, 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?

Two sentences with no extraneous information: purpose, prerequisite, return value. Perfectly front-loaded.

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

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

For a simple submit tool with two parameters and no output schema, the description covers basic usage and return. However, it lacks details on failure modes, rate limits, or idempotency, which could help the agent handle errors.

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 a concrete example for fields and reiterates the source of formId, enhancing agent understanding beyond the schema.

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

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

The description clearly states it submits a form on behalf of the user, specifically for Wix Forms, and references a prerequisite (list_forms) which distinguishes it from sibling tools like create_booking or list_forms.

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

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

Explicitly instructs to call list_forms first to obtain formId and field keys, providing clear usage context. No explicit when-not-to-use, but the context is sufficient.

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