tickadoo-mcp

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds the 'legacy-compatible' context, indicating potential differences in behavior (e.g., caching or output format). However, no additional behavioral traits (rate limits, auth requirements) are disclosed, and the description does not contradict annotations.

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

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

The description is two concise sentences. The first sentence front-loads the usage scenario, and the second provides context (legacy-compatible). No extraneous information; every word serves a purpose.

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 5 parameters, 2 required, 23 sibling tools, and no output schema, the description is moderately complete. It covers the main use case but does not describe the response structure or differentiate from the sibling 'get_availability'. The note 'legacy-compatible' hints at differences, but more detail would help.

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 is not required to explain parameters. The description summarizes the tool's purpose (availability, cost, booking link) which aligns with parameters (date, party_size, slug) but adds no new semantic detail beyond the schema's own descriptions.

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

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

The description clearly states the tool checks availability, costs, and provides a booking link for a specific experience on a single date. It uses specific verbs ('check', 'costs', 'wants') and distinguishes itself as the 'legacy-compatible date-specific' interface, implicitly differentiating from siblings like '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 says to use when the user has picked a specific experience and asks about availability for one date, cost, or booking link. However, it does not mention when not to use (e.g., for multiple dates or general search) or explicitly name alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond this: it specifies the output format (comparison table plus per-axis winners) and the required input pattern ('Pass the slug for each'). This is valuable additional information that aligns with the annotations.

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

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

The description is extremely concise: two sentences that immediately convey the tool's purpose, input, and output. Every sentence earns its place with no redundancy or filler.

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

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

The tool has no output schema, so the description must explain the return value, which it does: 'Returns a comparison table plus per-axis winners'. It also covers the required input constraints (2-5 specific products, slugs). Given the tool's simplicity (3 parameters, no nested objects), the description is complete and informative.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides for each parameter. It mentions passing slugs and the output structure, but these are not parameter-specific details. Therefore, the description adds no substantial semantic value beyond the schema.

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

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

The description clearly states the tool's purpose: side-by-side comparison of 2-5 specific products. It specifies the action (compare), the input (product slugs), and the output (comparison table with per-axis winners). This distinguishes it from sibling tools like search_experiences or get_experience_details.

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

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

The description explicitly says 'Use this when the user wants a side-by-side comparison of 2-5 specific products.' This provides a clear condition for use. While it doesn't explicitly list contraindications or alternatives, the specificity of the condition is sufficient for an agent to decide when to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so no destructiveness or side effects. The description adds client-context (non-ChatGPT vs ChatGPT) but no additional behavioral traits like rate limits or response format beyond what annotations imply. It does not contradict annotations.

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

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

Two sentences exactly: first defines core function and condition, second identifies the alternative. No wasted words, front-loaded with critical information.

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

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

For a 7-parameter tool with no output schema, the description covers purpose and usage guidelines well, but does not mention return format or error handling. However, annotations and parameter defaults partially compensate. Slightly incomplete due to missing output description, but still adequate for most use cases.

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 86%, so the baseline is 3. The description does not elaborate on individual parameters; it merely frames the overall purpose. The schema itself provides adequate parameter details (e.g., defaults, bounds). The description adds marginal semantic value 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 finds experiences near a given coordinate (latitude/longitude). It distinguishes itself from the sibling tool `search_local_experiences` by specifying the client type (non-ChatGPT vs ChatGPT) and input precision (exact coordinates vs coarse place hints).

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 provides when to use (non-ChatGPT client with exact lat/lng) and when not to (ChatGPT clients should use `search_local_experiences`). Names the alternative directly, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds that this is a 'live supplier-check' implying external dependencies, but does not detail caching behavior (though the 'fresh' parameter description does), rate limits, or the delta-only response for as_of. The description adds moderate value beyond annotations.

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

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

Two sentences with zero wasted words. The first sentence sets the exact use case, the second provides the essential input guidance. Highly efficient.

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

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

For a tool with 10 parameters, no output schema, and caching/idempotency behavior, the description is adequate but not rich. It does not explain return values or the response format (delta vs full), leaving the agent to infer from parameter names. Could benefit from mentioning cache bypass, rate limits, or that as_of returns delta only.

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?

Despite 100% schema coverage (baseline 3), the description adds meaningful guidance on parameter relationships: 'pass product_id from search or slug plus city_slug' clarifies how to choose between parameter combinations, which is beyond what the schema provides.

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

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

The description clearly states the tool checks live bookable dates, times, prices, and remaining spaces for one selected product. It distinguishes itself as a 'live supplier-check tool' from potentially cached or static data sources, and provides concrete input guidance (product_id or slug+city_slug).

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 ('when the user is ready to check live bookable...') and how to supply parameters (product_id from search or slug plus city_slug). However, it does not explicitly exclude alternatives or compare to siblings like check_availability, which may overlap.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description supplements this by detailing the return content, offering behavioral context beyond what annotations provide.

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 sets usage context, second lists return items. No filler words, efficient and front-loaded.

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

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

No output schema, but description lists key return elements. For a simple, read-only tool with clear sibling context, this is 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 description doesn't need to add much parameter detail. It names parameters indirectly but doesn't elaborate beyond schema. 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 returns a city orientation overview for trip planning, listing specific content like highlights, categories, price band, etc. It distinguishes itself from sibling tools that focus on specific experiences or tips.

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

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

The description explicitly says 'Use this when the user wants an orientation overview of a city for trip planning,' providing clear context. It does not explicitly state when not to use it, but the sibling list helps differentiate.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds behavioral details beyond annotations: it filters out family-rated and high-physical-level venues, implying curation for romance, and describes the return structure.

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 plus a final line. Every sentence adds value, front-loaded with the use case. 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 output schema, the description sufficiently explains what is returned. Parameters are fully documented in schema. The tool is simple and non-destructive, so no further details are needed.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds minimal additional meaning; e.g., budget bands are already explained in schema. 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 returns an evening plan for two with specific components (pre-dinner activity, dinner area, evening show, post-show tip, cost). It distinguishes itself from siblings like get_family_day by filtering out family-rated venues.

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?

Starts with 'Use this when the user wants an evening plan for two,' providing explicit usage context. It doesn't explicitly mention when not to use it or alternatives, but the distinction from siblings is implicit in the description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds that the tool returns richer fields and accepts two identifier types, but does not disclose behavior when both are provided or error handling. This is adequate given the annotation coverage.

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 usage instruction, no redundant information. Every sentence serves a purpose.

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 (4 optional parameters, no output schema, read-only), the description is mostly complete. It covers the trigger, inputs, and response shapes. It could be more specific about the fields returned, but the format parameter and search context compensate.

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 by clarifying that identifiers come from previous search results and explaining the format parameter's two response shapes (json vs text). The language parameter's purpose is also reinforced.

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 richer details for a specific experience from search results, using product_id or slug. It distinguishes from sibling tools like search_experiences by specifying the post-search usage 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 explicitly instructs when to use (when user selects a specific experience from search results) and what identifiers to use. It does not provide exclusions or compare to alternatives like get_related_experiences, 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?

Annotations already declare readOnlyHint true, idempotentHint true, etc. The description adds that it uses age-aware filters and clusters venues by walking distance, providing valuable behavioral context beyond annotations.

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

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

Two sentences, front-loaded with usage guidance, then concise enumeration of return structure and key features. 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 6 parameters and no output schema, the description explains the overall return structure. It could mention the format parameter's effect on output, but the schema covers it. 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 extra meaning by explaining the output structure and algorithmic details (age-aware filters, walking distance clustering) that are not in the schema.

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

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

The description clearly states it provides a full-day family plan with specific components (morning activity, lunch, afternoon, evening), and the sibling includes 'get_date_night' and 'get_city_guide', differentiating it.

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

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

Explicitly says 'Use this when the user wants a full-day plan for a family in one city.' It does not explicitly mention when not to use or suggest alternative tools, 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?

Adds significant detail beyond annotations: describes filtering logic (HiddenGem tag, high ratings, low review counts) and explicit exclusions. Annotations indicate safe read-only operation, and description confirms no destructive behavior.

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

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

Two concise sentences: first gives usage guideline, second describes output and exclusions. 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?

Completeness is high: covers purpose, usage, return criteria, and format parameter. With no output schema, the description adequately explains what results look like.

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. Description does not add new meaning to parameters beyond what schema provides. It explains the tool's logic but not parameter details.

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 less-popular, local-favored experiences, explicitly excluding specific categories. It distinguishes from siblings like search_experiences by focusing on hidden gems rather than bestsellers.

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?

Begins with 'Use this when the user wants less-popular experiences locals favour,' providing a clear use case. Does not explicitly mention alternatives but implies differentiation from mainstream searches.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds behavior: returns specific fields sorted by soonest first. This provides context beyond annotations, such as the hint about 'seats_remaining', indicating partial availability info. No contradictions with annotations.

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

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

Two sentences with no wasted words. The first sentence states the usage condition, the second describes the return shape and ordering. It is front-loaded with the most critical information for tool selection.

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 6 parameters, no output schema, but 100% schema coverage and read-only annotations, the description provides essential context: the time window, returned fields, and sorting. It could mention that latitude/longitude are for biasing, but the schema covers that. Overall, it is sufficient for an agent to use the tool effectively.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not elaborate on parameters; it only states the tool's purpose. The schema already describes each parameter (city, hours, format, language, latitude, longitude) with defaults and constraints. Thus, the description adds no new semantic meaning beyond what the schema provides.

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

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

The description explicitly states the tool is for experiences starting within the next few hours, using clear verb and resource. It differentiates from siblings like 'whats_on_tonight' by specifying a time window of 'next few hours' rather than just tonight. The return format (rows with start_time, countdown_text, seats_remaining, sorted by soonest) is precise.

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 first sentence provides a clear when-to-use: 'when the user wants experiences starting within the next few hours.' It does not explicitly state when not to use, but the condition implies exclusion of events far in the future. Alternative sibling tools exist, but no explicit mention; however, the usage context is sufficiently clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that results are 'cached graph and semantic related products for trio-style widgets', which is valuable context beyond annotations. 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?

The description is two sentences, front-loaded with the main purpose and usage context. Every sentence adds value without redundancy. It is highly concise and well-structured.

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 5 parameters, no output schema, and moderate complexity, the description provides the core purpose and usage but lacks details on the return value structure (e.g., shape of 'cached graph' results). While sufficient for basic use, it could be more complete.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add any parameter-specific information beyond what the schema provides, so a 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 returns related experiences for a given product_id, specifying four relationship types (pair, after, nearby, similar). It distinguishes from sibling tools by targeting non-ChatGPT widgets and mentioning cached results. The verb 'get' and resource 'related experiences' are explicit.

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

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

The description explicitly says 'Use this when a non-ChatGPT widget or client has a selected product_id and needs related products', providing clear scenarios. It indirectly excludes other uses by specifying the context, but does not explicitly list when not to use or alternatives. However, the sibling tools complement this.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it returns returns estimates with durations, costs, and directions, which is beyond the structured annotations. It does not mention side effects or auth needs; for a read-only tool, this 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, front-loaded sentence that covers purpose, usage context, and output without any filler. 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 explains the return value (estimates with durations, costs, directions) and covers the supported modes and use case. It does not mention pagination or result limits, but the output is likely small. Given no output schema, this 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?

Schema description coverage is 100%, with each parameter clearly described (e.g., city lists supported values, format explains response types). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states exactly what the tool does: returns transfer guidance from an airport, station, or port to a hotel coordinate, listing specific modes (taxi, metro, bus, train) and outputs (durations, costs, directions). This clearly distinguishes it from siblings like check_availability or get_experience_details.

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

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

The description explicitly says 'Use this when the user is arriving in a supported city and needs transfer guidance...' and lists the seven supported cities. It does not provide when-not-to-use or alternatives, but no sibling tool duplicates this functionality, so the guidance 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?

Annotations already indicate readOnly=true, idempotent=true, destructive=false. Description adds that it returns grouped tips plus emergency numbers and phrases, enhancing transparency beyond annotations.

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

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

Two sentences, no fluff, front-loaded with when-to-use and what-returns. 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?

No output schema, but description explains return content (grouped tips, emergency numbers, phrases). Covers enough for agent to understand what to expect.

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

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

Schema covers all 4 parameters with descriptions (100% coverage). Description mentions topic filter and grouped tips but does not add significant 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 the verb ('Returns') and resource ('practical logistics questions about a city'), and distinguishes from siblings like get_city_guide by focusing on logistics tips.

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: when the user asks practical logistics questions. No explicit when-not or alternatives, but context with sibling tools makes it 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?

The description adds value beyond annotations by detailing the fixed 7-day window, daily structure (morning/afternoon/evening picks), and inclusion of a daily highlight. Annotations only indicate readOnlyHint and non-destructive nature, so the description enriches the behavioral understanding.

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 totaling 35 words, extremely concise with no redundant information. It front-loads the purpose and immediately follows with output details. 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?

The tool has three parameters (one required), no output schema, and straightforward annotations. The description sufficiently explains the output shape (7 days, daily segments, highlight). It could optionally mention relationship to 'whats_on_tonight', but current level is adequate for a low-complexity 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 baseline is 3. The description does not add new parameter semantics beyond the schema. The schema already explains city slug, format enum, and language code. No additional insight is needed.

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

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

The description clearly states the tool returns a day-by-day weekly calendar for a city, specifying the exact output structure (morning, afternoon, evening picks, daily highlight). This distinguishes it from siblings like 'whats_on_tonight' which returns only tonight's 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 starts with 'Use this when the user wants a day-by-day weekly calendar for a city,' which explicitly states when to use it. However, it does not mention when not to use it or provide alternatives among the 22 siblings, which would improve 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that this is a browsing tool with a specific return structure, enhancing transparency beyond the annotations.

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

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

The description is two sentences, front-loaded with the usage directive, and every piece of information is relevant. No wasted words.

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

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

Given the absence of an output schema, the description lists the returned fields but does not explain the effect of the format or language parameters on the output. It adequately conveys the tool's purpose but lacks some behavioral details that would help an agent fully understand the response variants.

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 four parameters are fully described in the input schema (100% coverage). The tool description does not add additional parameter-specific meaning beyond the overall purpose, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool lists supported cities for browsing before searching, and specifies the return fields (city names, slugs, country codes, product counts). It distinguishes itself from sibling search tools by the 'before searching' 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 explicitly says 'Use this when the user wants to browse supported cities before searching', providing clear usage context. It does not list alternative tools but implies that for actual search, other tools like search_experiences should be used.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read-only operation. Description adds behavioral details: returns per-day slots, geographic clustering, category diversity, running total cost. 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: first states use case and output, second adds features. No fluff or repetition. 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 8 parameters and no output schema, the description covers purpose, output structure, and key features (clustering, diversity, cost). Mentions format param for json/text. Could elaborate on exact return content but sufficient for selection.

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 baseline is 3. The description does not add new information about parameter meanings beyond what the schema already provides. It mentions 'multi-day plan for a single city' which relates to city and days, but that's already clear from schema.

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

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

Clearly states the tool is for multi-day plans for a single city, with output structure (morning, afternoon, evening). Distinguishes from sibling tools like get_date_night or get_city_guide by emphasizing multi-day and per-day slots.

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 starts with 'Use this when the user wants a multi-day plan for a single city.' Does not explicitly say when not to use or provide alternatives, but the context of sibling tools implies alternatives (e.g., get_date_night for single evening).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds that the tool parses natural language and returns scored recommendations, but does not disclose any behavioral traits beyond what annotations provide.

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-loaded with the primary use case, and contains no redundant information. Every sentence is meaningful 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 7 parameters are fully documented in the schema and there is no output schema, the description covers the tool's behavior comprehensively. It explains input handling and output structure (scored recommendations with reason), leaving no critical 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 all 7 parameters. The description adds context that the query is parsed for specific attributes, but this is already hinted in the example. No significant additional meaning beyond the schema.

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

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

The description clearly states the tool's purpose: to recommend experiences based on natural language queries. It specifies what it parses (audience, mood, constraints, occasion, time of day) and that it returns scored recommendations with a reason field. This differentiates it from sibling tools that are category-based (e.g., get_date_night, search_by_mood).

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

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

The description explicitly says when to use this tool: when the user describes what they want in natural language rather than naming a category. It implies when not to use it (when a category is named), though it could be more explicit about alternatives like search_by_mood or specific get_* 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations by specifying the tool's role as the sole visual renderer and telling the agent to pass only IDs. No contradictions, and it enhances understanding without needing to discuss destructive actions.

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 with the key instruction front-loaded. It efficiently communicates usage, constraints, and parameter semantics without redundancy. Slightly verbose but each sentence contributes meaningful guidance.

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

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

Given the complexity of 4 parameters (one nested) and no output schema, the description covers essential usage context: when to use, what to pass, and how to structure the render_context. It explains the role of intent_summary as the heading. Adequate for an agent to invoke 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 description coverage is 75%. The description adds value by explaining that experience_ids should be stable product IDs (t_ ids) and that render_context.intent_summary becomes the carousel heading. These details go beyond the schema's basic descriptions.

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

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

The description clearly states that the tool displays visual experience cards and is the only tool for that purpose. It explicitly distinguishes itself from sibling search/discovery tools by specifying it must be used after they return results.

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

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

Provides explicit when to use: 'immediately after ANY discovery or search tool returns results.' Also instructs to call it exactly once per result set, never re-list experiences as text, and pass only stable product IDs. This offers clear usage context and 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?

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: it requires a prior request_id, describes the action as a recorded row, and implies non-destructive logging. No contradiction with annotations. The metaphorical language ('turns the agent feedback loop...') is acceptable and adds understanding.

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 concise but includes a metaphorical second sentence that adds little practical value. The list of examples is helpful but slightly verbose. Front-loads the action, but could be tightened without losing meaning.

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 3 parameters and no output schema, the description is fairly complete. It explains the tool's role in the feedback loop, gives usage examples, and states the prerequisite. It does not explain return values, but that is less critical for a feedback tool. Sibling context shows this is unique, so no missing comparisons.

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

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

Schema description coverage is 100% with good descriptions for each parameter. The description repeats the requirement of notes for 'other' signal_type but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate since schema carries the load; the description does not enhance understanding of parameters.

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: to push a quality signal back about a prior experience/recommendation. It uses a specific verb ('push') and resource ('quality signal'), and distinguishes itself from sibling tools which are primarily retrieval-oriented (e.g., recommend_experiences, check_availability). The examples further clarify the scope.

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

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

The description explicitly states when to use this tool ('Use this to push a quality signal...'), provides concrete examples, and notes the prerequisite (requires the original request_id). It does not explicitly say when not to use, but the context among siblings makes the usage boundary clear. Missing explicit alternatives, but not needed due to uniqueness.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it 'maps the mood to preset search filters,' which provides some behavioral context but doesn't go beyond what annotations imply.

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 front-loaded usage instruction. No unnecessary words or repetition. 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 the schema covers all parameters and the description explains the overall purpose and usage context, the tool is fairly complete. It lacks mention of error handling or edge cases, but for a read-only search tool this is adequate.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds the high-level concept of 'mapping mood to preset filters,' but this doesn't significantly enhance understanding beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's purpose: search experiences by mood or vibe, contrasting with category-based queries. It lists example moods and explains the mapping to preset filters, making it easy to distinguish from sibling tools like search_experiences.

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

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

The description explicitly tells when to use this tool: when the user describes a feeling or vibe rather than a category. It provides a clear usage context with examples, though it doesn't explicitly mention when not to use or list alternative 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?

Despite annotations already declaring readOnly, idempotent, and non-destructive, the description adds rich behavioral context: explains the output fields, stable product_id, the destructive nature of restrict_to_top_rated, the deprecated popular_only, AND-combined tags, and the text format. This goes well beyond the annotations, earning a 5.

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

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

The description is extremely concise: four sentences that cover purpose, output, and integration. Every sentence adds value with no redundancy or filler. It is well-structured and front-loaded with the core use case.

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

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

For a tool with 13 parameters and no output schema, the description covers the main use case, output fields, integration with siblings, and important behavioral notes like the destructive filter. It is complete enough for an agent to select and invoke correctly.

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

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

With 100% schema coverage, the baseline is 3, but the description adds extra value by explaining the restrictive behavior of restrict_to_top_rated, the AND-combined logic for tags, and the deprecated alias. This enhances understanding beyond the schema, so it scores a 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 searches for bookable experiences based on city and filters, and returns a ranked list. It hints at integration with other tools but does not explicitly differentiate from siblings like search_by_mood or search_local_experiences. The purpose is specific and clear, earning a 4.

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

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

The description explicitly says when to use this tool ('when the user names a city plus a category, query, or filter set') and provides guidance on using results with render_experience_cards and get_experience_details. However, it doesn't mention when not to use it or contrast with siblings, so it gets a 4.

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

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

Annotations indicate read-only and idempotent, which the description complements by explaining the matching strategy (exact venue/neighbourhood first, then city centre fallback). No contradictions; adds useful behavioral context beyond annotations.

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

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

The description is highly concise: two sentences covering use case, examples, matching logic, and an alternative sibling. No verbose or redundant content; every phrase 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?

With 10 parameters, no output schema, and 1 required, the description provides enough context for an agent to decide when to use it and what it does. It covers the main scenario and disambiguation from siblings, though does not describe output shape or pagination.

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 70% and schema descriptions are already quite detailed (e.g., tags taxonomy, format enum). The tool description does not repeat or add new parameter information; it relies on the schema. Baseline 3 is appropriate as it neither detracts nor adds.

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: searching for local experiences when a place hint (e.g., landmark, neighbourhood) is given without exact coordinates. Examples clarify usage. Differentiates from search_experiences.

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

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

Explicitly states when to use (place hint without coordinates) and when not to (general city-wide search, directing to search_experiences). Also explains matching order and fallback logic.

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

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

Annotations cover read-only and non-destructive nature. Description adds sorting behavior (soonest first), filtering of started events, and inclusion of urgency hints, providing additional behavioral context beyond annotations.

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

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

Two sentences, front-loaded with usage guidance, then behavioral specifics. 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 tool with well-documented schema, description covers when, what, and how. Could briefly explain 'urgency hint' but not essential.

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. Description adds no additional meaning beyond what schema already provides for parameters.

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 verb ('what is bookable'), resource ('experiences'), and time scope ('tonight'). It distinguishes from siblings like 'get_whats_on_this_week' by specifying tonight-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?

Explicitly states when to use ('when the user asks what is bookable in a city tonight'). Does not explicitly mention when not to use or alternatives, but context and sibling names imply exclusions.

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