Filipe Coffee

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

No annotations are provided, so the description carries full burden. It thoroughly discloses that the booking is not complete until payment, returns a checkout URL, stays off the calendar until payment, and that contact email is not verified at this step. This is excellent transparency.

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

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

The description is three sentences with no filler. It front-loads the core purpose and immediately follows with critical behavioral warnings. Every sentence earns its place, making it highly efficient.

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

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

Given the complexity (6 params, nested object, no output schema), the description covers the critical behavioral aspects and input requirements. However, it lacks details about the return value format beyond mentioning a checkout URL. The agent may need to infer the response structure, but the user instruction partially compensates.

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 all parameters are described in the schema. The description does not add parameter-specific semantics but provides context on the overall flow (e.g., using exact startDate/endDate from get_availability). Baseline 3 is appropriate.

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

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

The description clearly states the action ('Book an appointment slot at a venue (Wix Bookings)') and distinguishes it from siblings by emphasizing the payment flow and the need to call get_availability beforehand. It is specific about the resource (venue slot) and the outcome (checkout URL).

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

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

Explicitly instructs to call get_availability immediately before, warns that the slot is re-validated server-side and a taken slot is rejected, and tells the agent to inform the user to open the checkout link. Provides clear context on when to use and what to expect, though alternatives are not explicitly named.

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 burden. It discloses the output (checkout URL) and the payment flow, but doesn't detail response structure, potential side effects (e.g., cart creation), rate limits, or error conditions. Some transparency, but gaps remain.

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 action and purpose. Excellent conciseness.

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

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

For a tool with one input parameter and no output schema, the description adequately explains the output (checkout URL) and flow. It mentions the store domain. Could be more complete by explicitly stating the URL is returned in the response, but overall sufficient.

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

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

Schema coverage is 100%, so the schema documents the `items` parameter with properties. The description only adds context ('one or more store products') beyond the schema's 'Products to add to cart.' Minimal added value, 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 creates a direct checkout URL for store products, distinguishing it from sibling tools like create_booking or list_products. It specifies the domain (Wix Stores) and the action (complete payment by clicking URL).

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

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

The description explains that no login is required on the AI side, providing clear usage context. However, it does not explicitly state when to avoid this tool or mention alternatives, which prevents a perfect score.

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 behavioral disclosure burden. It reveals that slot times are returned in the venue's timezone, which is a non-obvious behavior. However, it does not mention whether the operation is read-only or if there are any side effects, which is a minor gap for a data retrieval tool.

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

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

The description is extremely concise at two sentences, with no superfluous words. The first sentence states the purpose and domain, while the second provides key usage instructions. Every clause earns its place, making it easy for the agent to parse quickly.

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 mentions 'available time slots' and timezone behavior, but without an output schema, it does not detail the return structure (e.g., whether slots include start/end times, availability count, or formatting). Given the tool's complexity (3 parameters, no output schema), the description could be more complete about what the agent can expect in the response.

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 each parameter described. The description goes beyond the schema by emphasizing the need to use the serviceId from list_booking_services and to reuse the same place_slug, adding cross-tool dependency context. This provides value beyond the parameter descriptions alone.

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 available time slots for a bookable service on a given date, specifying the Wix Bookings domain. It includes the verb 'Get' and the resource 'available time slots', and provides necessary context about serviceId, date, and place_slug, making it distinct from sibling tools like get_showtimes or create_booking.

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

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

The description explicitly instructs the agent to pass serviceId from list_booking_services, use the same place_slug, and provide a date in YYYY-MM-DD format. While it does not explicitly state when not to use this tool versus alternatives, the context provided is sufficient for proper invocation, and the reference to sibling tool list_booking_services serves as a prerequisite.

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?

Describes return values (names, prices, status, count) but does not disclose additional behavioral details like rate limits or side effects. With no annotations, the description is adequate but not rich.

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

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

Two sentences, front-loaded with the action, no extraneous information, efficiently communicates purpose and usage.

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?

Fully explains what the tool returns (ticket names, prices, sale status, quantity left) without requiring an output schema. Sufficient for a simple 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?

Schema coverage is 100% and the description echoes the schema's parameter description without adding new meaning, so 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?

Clearly states it retrieves ticket types and prices for a specific event, distinguishing it from action-oriented siblings like reserve_event_tickets and rsvp_event.

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

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

Explicitly instructs to pass the event slug from list_events, providing clear prerequisite context. Does not mention when to avoid or compare with reserve_event_tickets.

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 burden for behavioral disclosure. It mentions the return data but does not explicitly state that the operation is read-only, has no side effects, or what authentication is needed. The verb 'Get' implicitly suggests read behavior, but more explicit transparency would be beneficial.

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

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

The description is concise with two sentences: the first states the action and context, the second details what is returned. Every word is informative, and there is no redundancy or verbosity.

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 covers the essential information: what the tool returns. However, it lacks any mention of error conditions, prerequisites, or typical use context, which would have made it more complete.

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

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

The tool has zero parameters, and the description correctly does not attempt to describe them. Baseline for no parameters is 4, as there is no need for additional parameter clarification.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource: 'loyalty/rewards program details for this site (Wix Loyalty)'. It also lists the return elements (program name, points currency, tier structure), making the purpose unambiguous. No sibling tool covers loyalty, so it is well-distinguished.

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 loyalty program details for the current site, but does not explicitly state when to use or when-not-to-use. Since no sibling tool provides similar functionality, the context is clear enough. However, the lack of explicit guidance prevents a top score.

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 (opening hours, ratings, address, neighborhood) but lacks behavioral details such as rate limits, required permissions, or idempotency. The 'Get' verb implies read-only, but not explicitly stated.

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

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

The description is a single sentence of 18 words, front-loaded with the purpose. It is efficient 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?

For a simple 1-parameter tool with no output schema, the description lists key return fields (opening hours, ratings, address, neighborhood). However, it could specify whether additional fields like photos are included, but overall is fairly complete.

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

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

The sole parameter 'slug' has schema coverage of 100%, so baseline is 3. The description adds minimal value beyond the schema, only providing an example ('cafe-example'). No additional semantic meaning is added.

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

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

The description clearly states the verb 'Get', the resource 'full details for a specific place', and the method 'by its URL slug'. It distinguishes from sibling tools like search_places by specifying it's for a specific 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 implies usage when you have a slug and need full details, but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, though sibling tools exist like search_places.

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. Description does not disclose read-only nature, side effects, or auth requirements. List of returned items is present but lacks depth on behavior beyond 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: main action with output details, then prerequisite guidance. No redundant phrases.

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 covers returned fields (menus, sections, dishes, prices, dietary labels). Provides prerequisite. Missing pagination or limits, but acceptable for simple menu retrieval.

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?

Parameter place_slug is 100% described in schema with example and source hint. Description adds context on where to get the slug, but does not significantly enhance schema info.

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

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

Description clearly states it gets food menus for a specific restaurant, listing returned content (sections, dishes, prices, dietary labels). Distinguishes from siblings like get_place or search_dishes.

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

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

Explicitly states prerequisite: use search_places or list_categories first to obtain place_slug. Does not mention when to avoid, but adequate for a retrieval 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?

No annotations provided, so description carries the burden. It indicates the tool is read-only and returns specific fields, but does not disclose pagination behavior, sorting, or any limitations beyond the implicit limit parameter.

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

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

Description is two sentences, front-loaded with the tool's purpose, and contains no extraneous information. Every word adds value.

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

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

The tool is simple with one optional parameter and no output schema. The description lists return fields, but lacks details on pagination, ordering, or any default behavior beyond the implicit limit. It is minimally sufficient but not comprehensive.

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

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

Schema coverage is 100% for the single 'limit' parameter, which is well-documented in the schema. The description does not add any additional context about the parameter beyond what the schema already provides.

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

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

Description clearly states the action ('Get') and resource ('published reviews for this site'). It specifies the returned fields (reviewer name, rating, title, content), making it distinct from sibling tools which cover different domains like bookings, events, etc.

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

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

No guidance on when to use this tool vs alternatives. There is no mention of prerequisites, exclusions, or scenarios where other tools would be more appropriate.

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. 'Get' implies read-only, and description details return format and language, but does not explicitly state non-destructive nature 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, concise and front-loaded with purpose. No unnecessary words.

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

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

No output schema, but description explains return values (cinema, times, format, language). Includes prerequisite. Could mention pagination or limits, but adequate for 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 coverage is 100%, so baseline 3. Description adds context that movie_slug comes from list_movies, but does not significantly enhance parameter 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 it gets showtimes for a specific movie at cinemas in a neighborhood for a given date, and specifies return fields (cinema, times, format, language). Distinguishes from siblings by focusing on movie showtimes specifically.

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?

Mentions prerequisite 'Requires movies_enabled on this site,' but does not explicitly state when to use vs. alternatives or provide exclusions. Context is clear but lacks explicit 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?

With no annotations, the description discloses return values including weather and time, implying no side effects. It is transparent about what the tool does, though it could mention that data is read-only and requires no parameters.

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: first lists outputs, second provides usage context. No wasted words; front-loaded with key information.

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

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

Despite no output schema, the description enumerates key returned fields (name, locale, domain, description, canonical URLs, local time, weather). Sufficient for a simple parameterless tool, though could mention data source or update frequency.

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 0 parameters with 100% coverage, so baseline is 4. The description adds no parameter info (none needed), which 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 what the tool returns: basic neighborhood directory info plus local time and weather. It distinguishes itself from siblings by specifying unique outputs like weather, which no other sibling tool mentions.

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 recommends use for 'what time is it there' or 'what's the weather like' context, giving clear guidance. It does not exclude other uses, but the guidance is practical and helpful.

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, and the description does not disclose behavioral traits like authentication needs, rate limits, or whether the tool is read-only. The mention of 'recent' and 'published' hints at filtering but lacks full transparency.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and output. It could be improved with structured formatting (e.g., bullets) but is not verbose.

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 lists return fields but lacks details on ordering, pagination, error conditions, or output schema. It is adequate for a simple list tool but could be more complete given the absence of an output schema.

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

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

Schema description coverage is 100% and already documents the parameters. The description adds value by listing return fields but does not further clarify parameter syntax or behavior 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 lists recent published blog posts for a specific site (Wix Blog) and enumerates the return fields. This distinguishes it from sibling list tools like list_products or list_events.

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

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

No guidance is provided on when to use this tool versus alternatives such as list_events or list_products. The description only implies usage for blog posts, but explicit context is missing.

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 bears full burden. It discloses that services are listed for every venue, including those without online booking. It explains the bookableViaMcp field and that when false, id is null and create_booking cannot be used. It also specifies return fields: name, description, price, duration in minutes, and bookableViaMcp.

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 well-structured and front-loaded with the core purpose. It then adds parameter guidance, edge cases, and return details. While slightly lengthy, every sentence adds value. It could be slightly more concise, but it remains 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?

Given the tool's complexity (two modes, dependency on booking ability, integration with create_booking), the description covers all necessary aspects: how to use, what outputs, how to handle non-bookable venues, and relationship to sibling tools. It is complete without an output schema.

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

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

The input schema already has a description for place_slug, but the description adds significant context: it explains the two modes, that place_slug is strongly recommended, and ties it to search_places. This goes beyond the schema's explanation and helps the agent understand the parameter's role and consequences of omission.

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: 'List a venue's services — what it offers, with price and duration.' It distinguishes the tool from siblings by linking to create_booking and specifying that it works with venue-specific services. The verb 'list' and resource 'services' are specific, and it differentiates from other list tools like list_products or list_offers.

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

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

The description provides explicit guidance: when to use place_slug ('almost every case'), when not (omitting gives directory's own services, which most sites don't have). It also advises on venues without online booking, directing users to bookingUrl or venue page. It references search_places for obtaining the slug.

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 disclose behavioral traits. It only describes the return value without mentioning side effects, permissions, rate limits, or idempotency. For a read-only operation, minimal behavioral context is given.

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

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

The description is a single, well-structured sentence that front-loads the purpose. It is concise 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?

Given no parameters, no output schema, and no annotations, the description provides a good overview of the returned taxonomy. However, it lacks details on error handling, performance, or data limits.

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%. Per guidelines, 0 parameters baseline is 4. The description adds value by explaining the output content, which is more than 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 clearly states it returns the full category taxonomy with specific details (top-level groups, subcategories, localized labels, schema.org types, live place counts). It distinguishes itself from sibling tools that list other entities like blog posts, events, etc.

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

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

The description implies the tool is used when needing category taxonomy, but it does not explicitly state when to use it versus alternatives or provide any exclusions 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?

With no annotations provided, the description carries the full transparency burden. It discloses that events within 7 days include a weather forecast, that the 'agora' filter is resolved live, and the return fields (date, venue, price, URL). No contradictory information is present.

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

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

The description is front-loaded with the core purpose and includes essential details without excessive verbosity. It is structured as two sentences: the first defines the return content, the second elaborates on special features. Could be slightly more concise, but it is efficient.

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

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

Given no output schema, the description adequately explains return content and parameter effects. It covers the weather feature, filter semantics, and default behaviors. It lacks pagination or error details, but for a list tool of moderate complexity this is acceptable.

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

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

Schema coverage is 100%, but the description adds meaningful detail beyond the schema, especially for the filter parameter: it explains each enum value's intent (e.g., 'agora' excludes season runs and day-granular sources) and confirms defaults (limit 20, upcoming_only true).

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

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

The description clearly states the verb 'list' and resource 'events' with specific fields (date, venue, price, URL) and additional weather forecast detail for upcoming events. It distinguishes itself from sibling tools like get_event_tickets and reserve_event_tickets by focusing on browsing instead of single event details or bookings.

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

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

The description provides clear usage context, recommending use of filter options like 'agora' for live events and noting its live resolution advantage over cache. It does not explicitly mention when not to use or compare to all siblings, but the context is sufficient for an agent to decide.

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 present, so the description must carry the entire burden of behavioral disclosure. It indicates a read operation with 'Get all', and mentions grouping by category. However, it does not disclose potential traits like authentication, rate limits, or pagination. For a simple read-only tool with no parameters, this is adequate but minimal.

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

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

The description is extremely concise with two sentences. It wastes no words and includes all necessary information: the output content, grouping, and example use cases.

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

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

Given the simplicity of the tool (no parameters, no output schema), the description is complete. It specifies what the tool returns (FAQ questions and answers, grouped by category) and gives concrete examples. No further information is needed for an agent to use it correctly.

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

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

There are no parameters (schema coverage 100%), so baseline is 3. The description adds value by explaining that results are grouped by category and providing usage examples (opening hours, parking, policies), which goes 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's purpose: 'Get all FAQ questions and answers for this site (Wix FAQ). Grouped by category.' It uses a specific verb-resource combination and distinguishes itself from sibling tools like get_site_info, list_products, etc., by focusing on FAQ content.

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

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

The description provides explicit guidance: 'Use this to answer common questions about the site — opening hours, parking, policies, etc.' This tells the agent when to use the tool. It does not list when not to use or alternative tools, but the context is clear for an FAQ 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?

With no annotations, the description carries full burden. It discloses that it's a read-only list operation and what data is returned, but does not mention potential limitations like pagination or rate limits. For a simple tool, this is mostly 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, front-loaded with the purpose and no wasted words. Every sentence adds value.

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

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

Given zero parameters, no output schema, and the tool's simplicity, the description is complete. It explains purpose, return data, and usage context without missing elements.

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

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

The input schema has no parameters, so baseline score is 4. The description adds no parameter info, but none is needed.

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

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

The description clearly states the verb 'List' and the resource 'available contact/signup forms on this site (Wix Forms)'. It specifies return fields (name, ID, field definitions), distinguishing it from sibling tools like list_products 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 explicitly advises to use 'before submit_form to discover which fields to fill', providing precise when-to-use context and referencing a sibling tool. This guides the agent on appropriate usage.

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 describes the content but does not specify behavior like pagination, ordering, or whether the tool is read-only (though implied). Given the tool's simplicity, 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?

Two sentences with no wasted words. Every sentence provides value: the first defines the tool, the second gives a usage example. Front-loaded with the action and resource.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose and use case well. It does not explain the return format, but that is acceptable given the tool's straightforward nature.

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

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

The input schema has 100% coverage for the only parameter (limit), so the description adds little beyond stating it is for listing guides. Baseline 3 is appropriate as the schema already provides clear meaning.

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

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

The description clearly states the tool lists curated editorial guides with ranked places and editorial notes, which is distinct from sibling tools like list_blog_posts or list_products. The specific phrase 'best source for best X in this neighborhood questions' solidifies its purpose.

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 provides a clear use case: answering 'best X in this neighborhood' questions. While it doesn't list explicit alternatives or when-not-to-use, the context is sufficient for a simple list tool with limited 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?

With no annotations provided, the description must disclose behavioral traits. It implies a read operation and lists return fields, but it does not mention ordering, pagination, rate limits, or authorization requirements. The description is adequate but lacks detailed behavioral context.

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

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

The description is a single paragraph that front-loads the purpose and efficiently covers key aspects: scope, categories, and return fields. Every sentence provides necessary information without redundancy.

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

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

Given the absence of an output schema, the description sufficiently covers return fields and provides context for parameter usage. It explains the different statuses and the tool's scope. It is fairly complete for a list tool, though it could mention default ordering or pagination limits.

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

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

The input schema already covers both parameters with 100% description coverage, so the baseline is 3. The description adds value by clarifying the scope ('neighborhood', 'movies_enabled') and the meaning of 'now_showing' (films with upcoming showtimes). This additional context justifies a higher score.

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

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

The description clearly states it lists movies available in the neighborhood, specifies categories (now-showing, coming-soon, streaming), and lists returned fields (title, genres, TMDB rating, runtime, detail URL). This distinguishes it from sibling tools like get_showtimes and list_events, which operate on different domains.

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 includes a useful context note ('only on sites with movies_enabled') and explains the meaning of each status filter. However, it does not explicitly guide the agent on when to prefer this tool over alternatives such as get_showtimes or list_events, missing an opportunity for clearer differentiation.

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 burden for behavioral disclosure. It mentions that FLASH offers have a countdown deadline but omits other traits such as read-only status, pagination, authentication requirements, 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 extremely concise with two sentences, no redundant information, and clearly front-loaded with the tool's primary purpose. Every word earns its place.

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

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

The description covers return fields but lacks details on pagination, sorting, error cases, or behavior when no offers are available. Without an output schema, additional context would improve completeness for an agent.

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

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

Schema coverage is 100%, and the description adds value by explaining that FLASH offers are time-limited with a countdown, which directly relates to the 'kind' parameter. The 'limit' parameter is not elaborated beyond the schema, but the overall parameter meaning is enhanced.

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

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

The description clearly states it lists active promotions and deals in a neighborhood directory, specifying the returned fields. It distinguishes itself from other list tools by focusing on offers, but does not explicitly differentiate from similar sibling tools like list_events or list_products.

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

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

The description provides no guidance on when to use this tool vs alternatives, nor does it mention prerequisites, context, or limitations. An agent would not know when to prefer list_offers over 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. Description does not disclose read-only nature, auth requirements, or rate limits. However, for a simple list operation, the description is acceptable but minimal.

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

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

Single sentence, no wasted words. Front-loaded with action and resource. Perfectly concise.

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

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

Given zero parameters and no output schema, the description covers all needed info: target entity and return fields. Could benefit from mentioning if all plans are returned or if pagination applies, but not critical.

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

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

No parameters (baseline 4). Schema coverage is 100%, so description adds no extra param info, which is fine.

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

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

Clearly states it lists membership/subscription plans (Wix Pricing Plans). Specifies return fields: plan name, price, billing cycle, perks, checkout URL. Distinguishes from sibling list_* tools by targeting pricing plans specifically.

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

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

No explicit guidance on when to use vs alternatives. Agent must infer from name and return fields. Usage is implied but not 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?

With no annotations, the description should disclose behavioral traits. It indicates the tool returns a list with specific fields, which is helpful, but does not mention pagination, ordering, readonly behavior, or rate limits. The description is adequate but not thorough.

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

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

Two sentences cover purpose and return fields without any wasted words. The description is efficiently written and front-loaded.

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

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

The description explains what the tool returns, which is sufficient for a simple listing operation without an output schema. It could mention default limit and maximum, but that is covered in the schema. Slightly incomplete regarding pagination or ordering, but overall clear.

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 description adds no new meaning beyond the schema. Both parameters (q and limit) are described in the schema, and the description mentions them but with the same information. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists products from a specific store (Wix Stores) and identifies the returned fields (name, price, stock status, product type). This is specific and distinguishes it from sibling tools like list_blog_posts or list_events.

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

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

No guidance is given on when to use this tool vs alternatives such as search_dishes or list_pricing_plans. The description does not provide criteria for selection or mention limitations.

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 the description carries full burden. It discloses return fields (name, URL, category, metadata) but does not mention pagination, rate limits, or whether the operation is read-only. 'List' implies read-only, but more transparency would help.

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

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

Two sentences, no fluff, front-loaded with key information. 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?

For a simple list tool with one parameter, the description provides sufficient context: what is listed and what is returned. However, it could mention default sorting or pagination behavior for 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?

The input schema covers the single optional parameter (limit) with a clear description. The description adds no additional parameter info, but schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the action (List), resource (solo service-provider profiles), and scope (businesses without a fixed physical location). It provides examples and distinguishes from sibling tools like 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 when to use (listing solo service providers) and differentiates from other list tools via the specific type. However, it does not explicitly exclude other scenarios or name 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 are provided, so the description fully discloses behavior: the request is held pending email confirmation, the link expires in 24 hours, the confirmation link is not returned, and the restaurant confirms out of band. This is thorough and transparent.

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

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

Three sentences, each serving a clear purpose: stating the action, explaining the pending confirmation and user action, and clarifying it's not a confirmed booking. No wasted words; important details are front-loaded.

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

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

Given the 7 parameters, no output schema, and no annotations, the description completely covers the tool's behavior, constraints, and user guidance. It explains the workflow fully without needing additional fields.

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 extra context for the email parameter ('Use a real address belonging to the person you are acting for'), reinforcing its purpose beyond the schema description. This adds meaningful semantic value.

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

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

The description clearly states the tool requests a table at a restaurant, using the verb 'request a table' and resource 'restaurant'. It distinguishes from siblings like 'create_booking' by emphasizing this is an unconfirmed request, not 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 explicitly tells when to use it and what to communicate to the user: 'Tell the user to check their inbox — the link expires in 24 hours.' It also clarifies it's not a confirmed booking and provides guidance on using a real email address.

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, description fully discloses key behaviors: hold is temporary, nothing is paid, tickets not reserved until checkout completed via URL, hold expires automatically. Also mentions return of checkout URL. No hidden 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?

Four sentences, no fluff. Front-loaded with main action 'Hold tickets...' followed by critical caveats and limits. Every sentence earns its place. Efficient and clear.

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

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

Given no output schema, description adequately covers return value (checkout URL), constraints, and edge cases (external events). Complexity is moderate but fully addressed. No gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds extra meaning by specifying limits (max 10 tickets/ticket types) not in schema, and context that event_slug comes from list_events. Some behavioral context (return checkout URL) but not additional param details 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 'Hold tickets for an event... and return a checkout URL.' It specifies the resource (tickets), verb (hold), and distinguishes from siblings like 'create_booking' by noting it's a temporary hold. Also clarifies it only works for Wix Events, not external platforms.

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 when to use (events sold through this site) and when not (events sold elsewhere like Sympla, Ingresse, Sesc) and directs to use the event's own ticketUrl. Also states max limits (10 tickets, 10 ticket types) and the temporary nature, providing clear 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?

With no annotations, the description fully discloses key behaviors: confirmation email sent, 24-hour expiry, user must check inbox, link not returned. This is 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 front-loaded with essential information and uses capitalization for emphasis. It is slightly verbose but every sentence adds value.

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

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

Given no output schema, the description adequately covers the outcome and user instructions, though it could mention what happens after confirmation.

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 value by explaining the email parameter's purpose and linking event_slug to list_events, going beyond schema descriptions.

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

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

The description explicitly states 'RSVP to a free event on this site (Wix Events)' with a specific verb and resource, clearly distinguishing it from siblings like create_booking or reserve_event_tickets.

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

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

The description provides clear guidance on when to use (free events, real email) and what to expect (confirmation email, not on guest list), though it does not explicitly compare to 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, the description fully covers behavior: searches all menus, groups by dish, returns price/description/labels/URL. No side effects or permissions are mentioned, but it's a read-only search.

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 paragraph: purpose first, then details and alternative usage. 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 2-parameter search tool with no output schema, the description sufficiently explains inputs and return data (price, description, labels, URL).

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?

Both parameters are described in the schema (100% coverage), and the description adds value by explaining the query's role, giving examples, and noting the effect of omitting it.

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

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

The description uses a specific verb and resource ('Find which restaurants serve a dish'), clearly distinguishing it from sibling tools like search_places or get_restaurant_menus.

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

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

It explicitly states the use case ('where can I eat X') and explains behavior with and without a query, but does not directly contrast with 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, the description discloses accent-insensitive and typo-tolerant matching, relevance ranking, and the structured opening hours format, which provide key behavioral context.

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

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

Three concise sentences front-load purpose, then detail matching behavior, then output format, 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?

The description covers input options, search behavior, and output format (structured hours). It lacks explicit mention of limit defaults or return structure beyond hours, but given no output schema, 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?

All parameters have schema descriptions, and the description adds context like accent-insensitivity and typo-tolerance for q, and the format of opening hours, going 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 searches for places (restaurants, cafes, shops) in a neighborhood, which distinguishes it from siblings like get_place (single place) or search_dishes (dishes).

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

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

The description explains what the tool does and its optional filters but does not provide explicit guidance on when to use it versus siblings or when not to use it.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only mentions returning a submissionId on success, but does not address side effects, idempotency, authorization requirements, or error handling, which is insufficient for a write operation.

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

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

Two sentences: first states purpose, second gives prerequisite and return value. No unnecessary words, front-loaded with key information, highly efficient.

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

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers prerequisites and return value. However, it lacks details on error responses, required permissions, or potential failures, making it adequate but not complete.

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

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

Schema coverage is 100% (both parameters described). The description adds an example value for the 'fields' parameter, providing concrete guidance beyond the schema, though the schema already explains the key-value pairing.

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

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

The description clearly states the verb 'Submit' and resource 'form' (Wix Forms), distinguishing it from sibling tools like list_forms. The purpose 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?

It explicitly instructs to call list_forms first to obtain formId and field keys, providing a clear prerequisite. It does not explicitly state when not to use the tool, but the context is well implied.

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