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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description restates the default image-stripping behavior, but that fact is already fully documented in the view parameter's schema description, and it adds nothing on auth requirements, rate limits, or behavior for invalid/nonexistent IDs.

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 tight sentences with the core operation front-loaded and the non-obvious default behavior trailing it. No filler, no restatement of the tool name or title.

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 read-only lookup with a fully documented 3-parameter schema and no output schema, the description covers the essentials. It could be stronger by naming a few top-level fields returned or noting behavior for an unknown ID, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so locationId, language and view are all documented in the schema, which sets the baseline at 3. The description's note about view:"full" is consistent with but not additive to the schema's own enum description, and language is not mentioned at all.

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 (get), a specific resource (GetYourGuide location), the resource subtypes it covers (city, POI, region), and the required lookup key (numeric ID). It is trivially distinguishable from siblings like gyg_get_tour and gyg_search_tours, which target different resources.

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

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

Usage is implied — call it when you already have a location ID — but the description never states when to prefer this over gyg_search_tours or gyg_list_location_tours, nor what to do if you only have a name rather than an ID. It does clarify the view default, which is a conditional usage hint.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The only behavioral trait the description adds is that image URLs are stripped by default and view:'full' retains them, but that same fact is already spelled out in the view parameter's schema description, so the marginal value is small. No auth, rate-limit, or error behavior is disclosed.

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 tight sentences with no waste; the what/when and the default-behavior caveat are both front-loaded and easy to scan.

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

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

With no output schema, the description could say a bit more about the returned record's shape beyond the image-URL note, and it says nothing about invalid-ID or error behavior. Still, for a single-record read whose annotations and schema are rich and whose parameters are fully documented, an agent has enough to call it correctly.

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

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

Schema description coverage is 100%: the schema already documents view (compact vs full, with the image-URL nuance), tourId, currency and language defaults. The description adds nothing beyond the schema's own text, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the full GetYourGuide record for one tour/activity') and pins the lookup key to a numeric ID, which conceptually separates it from the listing/search siblings. It never names a sibling (e.g. gyg_get_tour_options or gyg_get_tour_reviews) or explicitly excludes them, so this is clear but not sibling-differentiating.

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 'by its numeric ID' phrasing implies the usage context (single-record lookup once an ID is known from a search/list call), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings such as gyg_get_tour_options or gyg_get_tour_availability. Adequate implied guidance only.

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

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

Annotations already declare readOnly, idempotent, openWorld, so the safety profile is covered. The description adds useful response-shape behavior: image URLs are stripped by default and view:"full" restores them, which tells the agent about output volume/side effects. It stops short of describing date-list pagination or ordering, so it is not fully 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?

Three tight sentences: purpose first, differentiation second, the view caveat last. No filler and the most decision-relevant information is front-loaded.

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

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

There is no output schema, so the description correctly compensates by naming the returned payload (categories, addons, dated availability with participant ranges). Minor gaps remain around list size/pagination and whether dates are filtered by any implicit window, but the description is otherwise complete for a read-only lookup.

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 view enum, tourId format, and language defaults are already fully documented in the schema; the description's note about image stripping only restates the view semantics. Baseline 3 is appropriate when the schema carries the parameter burden.

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 (Get) and resource (booking availability for a tour) and enumerates the payload contents: bookable participant categories, addons, and available dates with participant ranges. It also explicitly differentiates itself from the sibling gyg_get_tour_options, so an agent can route without opening either schema.

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

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

Gives an explicit selection rule: use this 'when you only need "when can I go"', and names gyg_get_tour_options as the heavier alternative for the fuller case. That is a clear when-to-use and when-to-prefer-the-sibling statement.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuine behavioral context on top: image URLs are suppressed by default and the caller must pass view:"full" to retain them, which tells an agent what the default response will and won't contain.

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 tight sentences: capability first, then the view/image-URL caveat. Nothing is padded and no sentence is redundant.

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 an 8-parameter read-only tool with no output schema, the description does the important work of characterizing the returned options. It omits any mention of the limit/pagination behavior and the currency/language defaults, but the schema covers those fields, so the gap is minor.

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 is already documented, and by the rubric that sets a baseline of 3. The description restates the date-range option and the view default but adds no format detail or syntax beyond what the schema field descriptions already say.

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

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

States a specific verb and resource ('List the bookable options of a tour') and enumerates what those options are (ticket types, times, languages offered), which implicitly separates it from siblings like gyg_get_tour and gyg_get_tour_availability. It never names an alternative tool explicitly, so it stops short of full sibling differentiation.

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?

'Optionally within a date range' hints at when the date parameters matter, but there is no explicit when-to-use guidance, no prerequisite (e.g. needing a valid tour ID first), and no routing to or away from siblings. Usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuine behavioural fact — image URLs are stripped by default — but says nothing about ordering defaults, offset capping, or rate limits. Some added value, but it also largely repeats the view parameter already spelled out in the schema.

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

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

Two tight sentences with the primary purpose front-loaded and the notable default (image stripping) immediately after. No filler, though the second sentence is partially redundant with the schema's view description.

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

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

With no output schema but full schema coverage on 8 parameters, the description covers purpose, default response shape, and the key opt-in. An agent can call this correctly; only sorting defaults and large-result traversal guidance are absent.

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

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

Schema description coverage is 100%, so all 8 parameters including the compact/full semantics, limit bounds and the offset-300 cap are already documented. The description only restates the view toggle, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

Specific verb+resource ("List customer reviews for a tour") with the response shape noted. The resource is clearly distinct from siblings like gyg_get_tour or gyg_get_tour_options, though no sibling is named 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?

Gives one actionable condition (pass view:"full" to keep image URLs), but says nothing about when to choose this over gyg_get_tour for review data, nor about pagination behaviour for walking large review sets. Usage is implied by the tool's scope rather than stated.

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

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

Annotations already declare 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?

Annotations already declare safe, idempotent, open-world reads; the description adds a non-obvious default behavior (image URLs stripped) and the opt-in switch, which is genuine value beyond the structured fields.

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, zero filler, with the primary purpose and the default-stripping caveat both 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 exists, but the description covers purpose, the key default-view behavior, and how results feed into tour searches. Pagination and language behavior rest on the schema descriptions, which is reasonable here.

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

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

Schema coverage is 100% and the view parameter's enum is fully documented in the schema, so the description's mention of view:"full" largely restates it. It adds no syntax or semantics for limit, offset, or language.

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

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

States a specific verb and resource ('List GetYourGuide activity categories') and adds the downstream purpose ('use the IDs to filter tour searches'), which distinguishes it from siblings like gyg_list_category_tours and gyg_search_tours.

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?

Clearly implies a lookup-first workflow (get IDs, then filter searches) and explains when to pass view:"full", but never names an alternative sibling or a when-not-to-use condition.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds nothing beyond restating the purpose – no auth requirements, rate limits, or pagination behavior are disclosed.

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 with no wasted words. It is appropriately sized for a one-line purpose statement, though it could carry a bit more without becoming verbose.

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

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

For a tool with six parameters, pagination, and configurable response views, the description is too sparse. It omits when to use it, what it returns, and how pagination works, leaving those to the schema and annotations. Incomplete 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 all six parameters are fully documented in the schema. The description adds no parameter semantics beyond what the schema already provides, meeting 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?

States a specific verb 'List', resource 'tours', and scope 'in one GetYourGuide category'. It implicitly distinguishes from location-based and search siblings via the category scope, but does not name any sibling 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?

No when-to-use guidance, no exclusions, and no mention of alternatives such as gyg_search_tours or gyg_list_location_tours. The agent must infer usage from the tool name alone.

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, so the safety profile is covered. The description adds essentially nothing beyond the annotations: no note on pagination defaults, result volume, rate limits, or what a missing/invalid locationId yields, so it earns only the low end of the annotated bar.

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 with no filler, naming the verb, the resource and the scoping dimension. Nothing to trim.

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 read with full annotation and schema coverage and no output schema, so the description need not explain return values. However, given six parameters and two near-identical siblings in the service, the absence of routing guidance leaves a real gap for correct 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%, including a detailed enum explanation for 'view' and defaults for limit/offset/currency/language, so the schema carries the full parameter burden. The description adds no parameter meaning at all, which is the baseline 3 case.

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

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

States a specific verb (List) plus resource (tours) plus scope (one GetYourGuide location, city/POI/region), which an agent can act on immediately. It stops short of naming the neighbouring gyg_list_category_tours / gyg_search_tours, so the sibling distinction is only implied by the word '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?

There is no when-to-use / when-not-to-use guidance and no alternative named, even though gyg_list_category_tours and gyg_search_tours overlap heavily in intent. The only usable signal is the required locationId, which the schema already supplies.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety/read profile is covered. The description's only behavioral addition is that results default to slim summaries and view:"full" expands them — but that same detail is already spelled out in the view parameter's schema description, so it adds little beyond structured data.

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 dense sentences with no filler; the purpose is front-loaded before filters, sort, and response shape. Every clause carries 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 13-parameter, all-optional search tool with no output schema, the description covers purpose, filter axes, sorting, and response shape, and annotations carry the read-only profile. It omits pagination (limit/offset), currency/language defaults, and the extraParams escape hatch, though the schema documents all of these.

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%, including the view enum semantics, date formats, limits, and the iata: free-text convention, so the baseline is 3. The description restates the filter/sort axes and the iata: hint already present in the q parameter, adding no new syntax or constraints.

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

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

States a specific verb+resource ("Search GetYourGuide tours and activities") and enumerates the supported filter axes and sort options. It does not, however, distinguish itself from siblings like gyg_list_location_tours or gyg_list_category_tours, which overlap with the location/category filtering described here, so an agent still has to infer which to pick.

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 by listing what can be filtered (free text, location, category, dates) and sorted, which tells an agent this is the flexible query tool. But it never states when to prefer it over gyg_list_location_tours, gyg_list_category_tours, or gyg_get_tour, and gives no exclusions or prerequisites.

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