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

The readOnlyHint annotation already establishes the operation is read-only, and the description aligns with that by saying 'Get details'. The description adds useful context about location types and the use of a numeric ID, but does not disclose return shape, possible errors, or scope limitations beyond that, which is acceptable 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?

A single, concise sentence that is front-loaded with the action and resource. Every phrase earns its place: it specifies the object types and the lookup mechanism 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?

For a simple get-by-id tool with a readOnlyHint and a fully described schema, the description is sufficiently complete. It could theoretically mention the output shape, but with no output schema and a straightforward resource, the current text gives enough for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents locationId and language. The description reinforces that locationId is numeric, matching the schema's integer type, but adds no meaning beyond the 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 a specific action ('Get details'), the resource (GetYourGuide location), and the scope (city, POI, or region) with the identifying mechanism (numeric ID). This distinguishes it from sibling tools like gyg_list_location_tours, which focus on listing rather than fetching a single location.

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

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

The description implies usage when you have a numeric location ID and need details, but it does not explicitly contrast with alternatives such as gyg_list_location_tours or gyg_get_tour. No when-not-to-use guidance is provided, leaving some inference needed.

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

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

The description discloses a key behavioral trait: 'Image URLs are stripped by default; pass view:"full" to keep them.' This goes beyond the readOnlyHint annotation by explaining a default transformation. It also clarifies the difference between compact and full response shapes, which is useful behavioral context. However, it doesn't mention rate limits or other potential side effects, but for a read-only tool with annotations, this is adequate.

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

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

Two sentences with no waste. The core purpose is front-loaded, and the critical behavioral note about image URLs is included efficiently. 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?

For a read-only single-record fetch with 100% schema coverage and a readOnlyHint annotation, the description is nearly complete. It explains the default behavior (image stripping) and the view parameter's role. It doesn't describe the return format in detail, but the schema's view parameter description covers that. The only minor gap is not explicitly stating that this is the tool to use when you have a specific ID, but that's implied by the name and description.

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 four parameters. The description adds the crucial detail about image URL stripping and the view parameter's effect, which is not fully captured in the schema's enum description. However, the description doesn't add much beyond that; the schema already explains currency, language, and tourId. 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's function: 'Get the full GetYourGuide record for one tour/activity by its numeric ID.' It specifies the resource (tour/activity), the action (get full record), and the identifier (numeric ID). It also distinguishes itself from sibling tools like gyg_search_tours by focusing on a single tour by ID rather than searching.

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 this tool: when you have a numeric tour ID and need the full record. It doesn't explicitly state when not to use it or name alternatives, but the context of siblings (search, options, availability, reviews) makes the use case clear. The view parameter guidance adds usage context.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing what the response contains (participant categories, addons, dates with ranges) and characterizing the operation as lighter than the options endpoint. It does not address pagination or rate limits, but that is not a major gap for a simple read-only availability check.

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 core purpose and returned data are front-loaded, and the comparison with gyg_get_tour_options is placed at the end as a concise differentiator.

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

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

For a two-parameter read-only tool, the description covers the needed context: what the tool returns, when to use it, and how it differs from a similar sibling. It could be slightly richer in describing the shape of the available dates or what 'addons' means, but it is sufficient for correct selection and invocation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description does not add parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

States a specific verb and resource ('Get booking availability for a tour') and enumerates the returned components: participant categories, addons, and available dates with participant ranges. It also distinguishes itself from gyg_get_tour_options by framing itself as the lighter alternative, so an agent can separate the two at a glance.

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

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

Explicitly names the sibling alternative (gyg_get_tour_options) and gives the selection condition: use this when you only need 'when can I go'. This is clear routing guidance that leaves little to inference.

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?

readOnlyHint=true already communicates the safe, read-only nature, and 'List' is consistent with that. The description adds the date-range scoping and the output-level notion that options include ticket types, times, and languages, but it does not describe pagination behavior or result structure. This is useful but not rich behavioral context, so a 3 fits the annotated baseline.

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 with no filler. Every element earns its place: the action, the resource, the clarifying examples, and the optional date-range qualifier.

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 read-only list endpoint with a fully schema-documented 7-parameter input, the description gives the essential output concept and a useful optional filter. However, there is no output schema, so more detail about the response shape would help, and the lack of sibling routing guidance leaves a real completeness gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly and the description does not need to compensate. The description mentions date-range filtering and general option semantics but adds no parameter-specific meaning beyond what the schema provides, keeping this at the baseline of 3.

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

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

The description uses a specific verb ('List') and a specific resource ('bookable options of a tour'), with parenthetical examples ('ticket types, times, languages offered') that clarify exactly what is returned. It does not explicitly differentiate itself from sibling tools such as gyg_get_tour_availability, so it stops short of a 5, but the core purpose is 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?

There is no guidance about when to use this tool versus gyg_get_tour_availability, gyg_get_tour, or other siblings. The mention of an optional date range describes a capability, not a selection criterion, so the agent must infer usage from the tool name and the schema.

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 and the description's 'List' is consistent with a safe read operation. The description adds minor return-shape context (rating outline plus review items) but does not address pagination behavior, ordering defaults, rate limits, or other runtime traits. With annotations covering safety, this 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?

The description is a single sentence with no filler. The verb and resource are front-loaded, and the parenthetical adds useful return detail 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?

The schema is rich and fully documents all parameters, and the readOnlyHint annotation covers the safety profile. The description provides the key return distinction (rating outline plus individual review items), which partially compensates for the missing output schema. It is not fully complete, but it is sufficient for a straightforward read-only review-listing 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 every parameter already has a meaningful description, including limits, defaults, and allowed enums. The tool description adds no parameter-level meaning, making the schema the primary source of semantics. 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 uses a specific verb ('List') plus a clear resource ('customer reviews for a tour') and adds useful output scope ('rating outline plus individual review items'). This distinguishes it from sibling tools like gyg_get_tour or gyg_search_tours without needing to inspect the schema.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools. It relies entirely on the tool name and parameter schema to convey applicability.

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, openWorldHint, and idempotentHint. The description adds valuable context: it makes one authenticated request, explains the diagnostic output (credential source, acceptance, RTT), and emphasizes it never returns the credential. This goes beyond annotations, though it could mention rate limits or the exact structure of the hint. With annotations covering safety, a 4 is justified.

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 concise paragraph, front-loading the core purpose and then adding behavioral details. Every sentence contributes value: resolution method, request target, report contents, read-only nature, and usage trigger. No redundancy or fluff.

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

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

For a 0-parameter diagnostic tool with annotations covering safety, the description is nearly complete. It covers the request, the response report, and the use case. Minor gaps: it doesn't specify the exact format of the hint or the timeouts/pagination, but given the simplicity and output schema absence, it's adequately complete, not perfect.

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 0 parameters, so the description doesn't need to document any. The baseline for 0 params is 4, and the description appropriately clarifies the tool's behavior without parameter details. It doesn't subtract for missing param info because there is none to describe.

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 resolves credentials and makes a health-check request to api.getyourguide.com, reporting credential source, acceptance, and RTT. This distinct purpose is well differentiated from sibling tools which all focus on data retrieval (tours, availability, reviews, categories, locations), making it clear this is a diagnostic tool rather than a data tool.

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: 'Call this when a real tool fails and you want to know which hop broke.' This gives clear context and a specific trigger condition. It doesn't name alternatives explicitly, but given the sibling tools are all data-retrieval tools, the contrast is implicit and the trigger is unambiguous, earning a 5.

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

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

The readOnlyHint annotation already covers the safety profile, so the description doesn't need to restate that. The description adds the behavioral note that the returned IDs are meant for filtering, which is helpful context but not deep behavioral detail (e.g., pagination or response format). Given the annotation coverage, a 3 is appropriate.

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?

A single, front-loaded sentence that states the core action, the resource, and a usage hint. There is zero wasted wording, and the most important information (what it lists and why) appears first.

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 a simple list operation with no output schema, but the description implies the return of categories with IDs ('use the IDs'), which is sufficient for an agent to understand what it will receive. It does not explicitly describe the response shape, but for a read-only list with this simplicity, the description is complete enough.

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

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

The schema describes all three parameters (limit, offset, language) with full coverage, so the description adds no additional parameter meaning. The baseline of 3 applies because the schema does the heavy lifting; the description doesn't compensate further but also doesn't need to.

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 ('List') and resource ('GetYourGuide activity categories'), and immediately adds the purpose of the IDs for filtering tour searches. This clearly distinguishes it from siblings like gyg_list_category_tours (which lists tours for a category) and gyg_search_tours, making its role unambiguous.

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

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

The phrase 'use the IDs to filter tour searches' gives explicit guidance on when to call this tool: to obtain category IDs for downstream filtering. It does not explicitly state when not to use it or name alternatives, but the context from the sibling list and the clear purpose provide adequate direction.

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 readOnlyHint annotation already covers the key safety trait, and the description's 'List' wording is consistent with that. The description adds no further behavioral context such as pagination behavior or response projection, but it is not misleading and does not contradict 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 a single clear sentence with no redundant wording or filler. It is front-loaded and appropriately sized for a simple listing tool.

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 schema and readOnly annotation cover most invocation details, and the description conveys the basic category-scoped list operation. However, the absence of any usage guidance relative to sibling tools, combined with no output schema, leaves some selection and expectation ambiguity 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?

The input schema has 100% description coverage, including categoryId provenance, limit and offset bounds, currency, language, and the view enum's effect on response shape. The description itself adds no parameter detail, but the schema already carries the full semantic weight, so the baseline of 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?

The description states a specific verb ('List') and a bounded resource ('tours in one GetYourGuide category'), so the core operation is unambiguous. It does not explicitly differentiate itself from sibling tools like gyg_list_location_tours or gyg_search_tours, but the category scoping is implied clearly enough.

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

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

The description gives no guidance on when to use this tool versus gyg_search_tours, gyg_list_location_tours, or gyg_get_tour. There are no mentioned exclusions, conditions, or alternative tools, leaving the agent to infer selection criteria from sibling names and the categoryId parameter.

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 readOnlyHint annotation already declares this is a safe read operation, so the description doesn't need to repeat that. The description adds the scoping detail (city, POI, or region) and the view parameter's effect on response shape is documented in the schema. However, the description itself doesn't disclose behavioral traits like pagination behavior or default response shape beyond what the schema already provides.

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 is front-loaded with the core action ('List tours available at one GetYourGuide location') and adds the parenthetical scope clarification. Zero 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 read-only list tool with 100% schema coverage and no output schema, the description plus schema covers what an agent needs: the resource, the scope, and all parameter semantics. The only minor gap is that the description doesn't mention the default view or pagination behavior, but the schema covers those. The sibling list provides enough context for tool 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 the schema already documents all 6 parameters thoroughly. The description adds minimal parameter-level meaning beyond the schema, but the schema itself is rich (view enum with detailed explanation, limit/offset ranges, currency/language defaults). 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 a specific verb ('List'), a specific resource ('tours'), and a clear scope ('at one GetYourGuide location (city, POI, or region)'). It distinguishes itself from sibling tools like gyg_search_tours (search vs list) and gyg_list_category_tours (category vs location) by naming the resource and scope explicitly.

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 this tool: when you need tours at a specific location, and the sibling list (gyg_search_tours, gyg_list_category_tours) provides context for alternatives. However, it does not explicitly state when NOT to use it or name a specific alternative, so it falls just short of a 5.

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

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

The description adds behavioral context beyond the annotations: it states that by default it returns 'slim summaries' and that view:"full" returns whole records. This is helpful because readOnlyHint=true already signals a safe read operation, so the description need not restate that. It does not mention rate limits or auth, but for a read-only search tool with a safe hint, 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 compact and front-loaded: it starts with the core purpose, then quickly lists the main search dimensions and the view behavior in two sentences. Every sentence contributes to understanding the tool's functionality, with no filler or redundant restatement of the name.

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

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

Given the complexity (13 parameters, no output schema), the description covers the essential search behavior, filters, sorting, and the response view distinction. Pagination, currency, and language are left to the schema, which fully documents them. The absence of an output schema is partially mitigated by describing 'slim summaries' vs 'whole records,' though more detail on the returned structure could be useful. Overall, it is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the main filter concepts (free text, location ID, category ID, date range, sort) that are already fully documented in the schema. It adds minimal new meaning, such as the 'iata:' syntax, but that is also present in the q parameter description. Thus it does not significantly compensate 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 opens with a specific verb and resource: 'Search GetYourGuide tours and activities.' It then lists concrete filter dimensions (free text, location ID, category ID, date range), sort fields, and the default/full view distinction. This clearly differentiates it from sibling list tools like gyg_list_category_tours and gyg_list_location_tours by emphasizing free-text search and general search capability.

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 through the filters it supports (e.g., free-text search, iata codes), but it never explicitly states when to prefer this tool over siblings like gyg_list_category_tours or gyg_list_location_tours. There is no direct 'when not to use' guidance, leaving some selection inference to the agent. This meets the 'implied usage' level but lacks explicit alternatives.

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