Angling Lines

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: prices are live, include the venue price plus cheapest crossing for quoted vehicles, are in GBP, and unavailable weeks return a structured unavailable result rather than a price. This is exactly the kind of behavioral disclosure that helps an agent set expectations.

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

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

The description is three sentences, front-loaded with the primary action and required inputs, then key operational details. Every sentence adds value, and no information is wasted or redundant with the schema.

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 complex 11-parameter tool with no output schema, the description covers the essential behavioral outcomes: what is quoted, what the price includes, the currency, and the unavailable result shape. The schema covers parameter details, so nothing critical is missing for an agent to call the tool correctly.

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

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

The input schema covers all 11 parameters with descriptions, so the schema carries the semantic burden. The description adds only high-level context about the party, vehicles, and currency rather than parameter-specific detail. Baseline 3 is appropriate given 100% 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 states a specific verb and resource: 'Quote one Angling Lines venue for one fixed 7-day week' with the exact inputs (venue name/slug, Saturday arrival date, party) and the output (total price). This clearly distinguishes get_quote from sibling list/search/prepare tools.

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

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

The description clearly communicates the operation and context: quoting a single venue for a fixed week from the live booking engine, and returning unavailable when not free. It does not explicitly name alternatives or state when not to use it, but the purpose and the sibling list make the distinction inferable.

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, so the safety profile is covered. The description adds useful behavioral context: results are ordered cheapest first, the price is the TOTAL holiday price with that crossing, the cheapest option matches get_quote, and availability is subject to sailing availability at checkout. It does not detail pagination or result limits, but for a list tool with read-only/idempotent annotations this is solid.

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

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

Three sentences with no waste. The first sentence states the core purpose and ordering, the second lists the return fields and downstream usage, and the third adds the two most important caveats (price match and availability). 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?

For a read-only list tool with 100% schema coverage and no output schema, the description is nearly complete. It explains the return fields, the ordering, the price semantics, the downstream consumer (prepare_booking), and the availability caveat. The only minor gap is that it does not describe the exact structure of the route ids or how many options are typically returned, but that is not essential for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds the relationship between the returned route ids and prepare_booking, and clarifies that the price is the total holiday price, but it does not need to repeat parameter details. Baseline 3 is appropriate when the schema carries the heavy lifting.

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 precise resource ('Channel crossing choices for one trip'), and the key dimensions (venue, Saturday arrival date, party) with an ordering ('cheapest first'). It also distinguishes itself from siblings by naming prepare_booking as the downstream consumer of the route ids, so an agent can tell it apart from get_quote and list_swims.

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 clear context: it is for one trip, cheapest first, and the route ids are to pass to prepare_booking when the customer picks one. It also notes the cheapest option matches get_quote and that crossing choice is subject to sailing availability. It does not explicitly say when NOT to use it versus get_quote or list_swims, but the context is strong enough to route an agent.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, lowering the bar. The description adds context beyond these: what data is returned (free/taken swim numbers, capacities, venue-specific rules, map URL) and the behavioral rule that single-swim requests at Golden Carp Lake must not be silently expanded. The 'never silently expand' instructions describe agent behavior rather than tool mechanics, but they still add operational context that complements the read-only annotation. No contradiction 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?

At roughly 103 words across six sentences, the description is long but justified by the complexity of the Golden Carp Lake special case and downstream routing. It is front-loaded: core purpose first, then return values, then special-case rules, then general guidance. Every sentence earns its place, though the middle could arguably be tightened without losing the critical prohibitions.

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 five parameters, no output schema, and the special Golden Carp Lake logic, the description is thorough: it states what is checked, what is returned, venue-specific handling, and downstream tool routing. The only gap is absence of explicit output-format details (no output schema exists to carry that burden), but the enumerated return types (free/taken numbers, capacities, rules, map URL) give the agent a solid model of the result. 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 and the schema already documents all five parameters with individual descriptions. The description reinforces two of them ('specific Saturday date' maps to date, 'actual party' maps to anglers), and it mentions accommodation_ids and booking_options as downstream values rather than this tool's parameters. This adds minor reinforcement but no new semantic detail beyond what the schema provides, so the 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 opens with a specific verb and resource: 'Check swim and accommodation availability for a venue on a specific Saturday date and actual party,' and lists concrete outputs (free/taken swim numbers, capacities, venue-specific rules, map URL). It distinguishes itself from list_crossings and list_venues by content, though it doesn't explicitly contrast with venues_available_on_date, a sibling with potentially overlapping scope. A clear purpose overall, but sibling differentiation is implicit rather than 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 provides exceptionally detailed usage direction: it names the Golden Carp Lake special case (four fixed booking_options, never individual swims), prescribes the exact flow (explain package, obtain acceptance before passing booking_option to get_quote, list_crossings, or prepare_booking), and states explicit prohibitions ('Never silently expand a single-swim request or increase the party to package capacity'). It also covers general venues ('pass chosen swims and accommodation_ids, or allow suitable free defaults') and flags that choices affect price, so the final selection must be quoted. This is proactive, alternative-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?

The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds context that it returns the full catalogue with headline facts and boolean flags, but it does not describe potential performance implications (e.g., large payload) or pagination behavior. While this is useful, the lack of such details means it doesn't go beyond the annotations sufficiently to warrant a higher score.

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 compact two-sentence block that front-loads the core purpose and scope. It includes all essential information—content, flags, URLs, usage guidance, and no-argument note—with zero filler. Every sentence earns its place, and the structure is well-organized.

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

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

The tool is simple (no parameters, no output schema), and the annotations cover read-only and idempotent behavior. The description fully explains what the response contains boats, flags, URLs—and explicitly warns it is not availability. Nothing an agent needs to correctly invoke this tool is missing, given the absence of an output schema.

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

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

The tool has no parameters, so the schema is trivially complete. The description effectively explains that no arguments are needed)Skip, which directly addresses the absence of parameters. It also explains the return payload's structure (features, URLs), which adds value not derivable from the empty schema. This is more than the baseline 4 for zero 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 enumerates every bookable Angling Lines carp fishing venue in France, with a specific verb 'List' and a defined resource. It explicitly distinguishes itself from the sibling search_venues by noting that feature keys match filter names, which is a specific and actionable distinction. This is not a tautology and immediately conveys the tool's unique role.

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

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

The description provides explicit guidance on when to use this tool versus alternatives, directly recommending 'prefer search_venues to filter server-side'. It also clarifies that it returns the full catalogue and is not an availability check, which distinguishes it from venues_available_on_date. This is high-quality usage guidance with clear 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 already declare readOnlyHint and idempotentHint, but the description adds critical specifics: 'creates nothing until the customer opens it' and 'Nothing is held or booked until checkout is completed.' It also discloses that dog crossing fees are not included in the quote and that missing choices return a reason. This goes beyond the annotation safety profile to explain exact non-effects and error 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?

The description is concise and front-loaded: it opens with the core purpose, immediately clarifies non-creation behavior, gives usage timing, and then error handling. Each sentence adds distinct value—no fluff or repetition. It is structured logically, moving from what it does to when to use it to what happens on failure.

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

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

Given the tool's complexity (14 parameters, 3 required), the description covers all essential workflow aspects: what it prepares, what it returns (live total, signed prefill link), when to call, what happens with missing/unavailable choices, and that nothing is held until checkout. The schema handles parameter-level details, so the description focuses on the overall flow, making it complete 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% – every parameter has a detailed description in the input schema. The tool description does not add extra meaning to any parameter; it only references overall context like GCL booking_option and crossing, which are already described in the schema. Baseline 3 applies because the schema carries the full semantic load.

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 precise action (prepare a confirmed trip), the exact resources involved (swims, accommodation, GCL booking_option, crossing), and the destination (Angling Lines review page). It distinguishes itself from siblings like get_quote (quotes) and list_swims/list_crossings (lookups) by focusing on preparation rather than retrieval or quoting.

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 call: 'Call after the customer confirms the venue, Saturday date, party and choices.' It also provides an alternative path when choices are missing/unavailable: resolve in chat with list_swims/list_crossings, and notes GCL can be booked through chat. This gives clear timing and fallback 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 and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it explains the two distinct behaviors (list-all vs. drill-in), discloses that results include descriptions and venue counts, and reveals the curation aspect (hand-picked, not filterable). This is useful context that the annotations alone don't 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?

Three sentences, each earning its place: the first defines the resource and gives examples, the second explains the two invocation modes, and the third provides the key differentiator from sibling tools. Information is front-loaded with the core purpose first, and there is zero redundancy with the schema or annotations.

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-optional-parameter tool with no output schema, the description is nearly complete. It covers what the tool does, how to invoke it in both modes, what the response contains (descriptions, venue counts, bookable venues), and why it's distinct from alternatives. The only minor gap is that it doesn't specify the exact response format, but with no output schema and a simple list-returning tool, this is a small omission.

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

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

Schema coverage is 100%, so the schema already documents the 'category' parameter. The description adds value by explaining the semantics of omitting vs. providing the parameter, and gives a concrete example slug ('big-carp-lakes'). This goes beyond the schema's basic description and clarifies the parameter's optionality and effect.

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 ('Browse'), a specific resource ('curated venue categories'), and gives concrete examples of what those categories are. It also distinguishes itself from sibling tools by noting these lists are hand-picked and cannot be reproduced by filtering on venue attributes, which clearly separates it from search_venues and list_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?

The description explicitly explains the two usage modes: calling with no arguments lists all categories, while passing a category slug opens the bookable venues in that category. It also provides a clear exclusion criterion — these curated lists cannot be reproduced by filtering on venue attributes — which tells the agent when NOT to use this tool in favor of search_venues.

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 and idempotentHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: the alternatives computation (venues matching everything but that week, each with nearest earlier/later free Saturday), the whole-catalogue default when no filters are given, and the mutually exclusive date/months modes. It stops short of describing the output shape or the Saturday-only constraint, which lives 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?

The core purpose is front-loaded and every clause carries information — there is no filler or restating of the schema. The description is dense and long, but the length is justified by 21 optional parameters; it would earn a 5 with slight structural segmentation of the modes and filter groups.

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 21-parameter, zero-required-parameter search tool with no output schema, the description covers the default behavior, both query modes, filter combinations, and the category dependency quite thoroughly. Minor gaps: it never sketches the returned venue fields, and the Saturday-only date rule is left entirely to the schema.

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

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

Schema coverage is 100%, so the per-parameter baseline is already satisfied. The description adds value by organizing the 18+ filters into semantic groups (party size, lake facts, facilities) and by explaining the interplay of 'date' vs 'months' and the 'category'→search_categories dependency beyond what each parameter's own description states.

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?

Opens with 'The tool for "find me a lake"' and a specific verb+resource: 'search the Angling Lines catalogue by party size, features and availability.' This clearly positions it as the full catalogue search and distinguishes it from search_categories (the slug source) and the more targeted sibling tools.

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

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

Provides explicit usage context: call with nothing for the whole catalogue, combine filters, add a 'date' for availability plus alternatives, or use 'months' to scan whole months, and narrow with 'category' using slugs from search_categories. It names one cross-tool dependency but never states when NOT to use this tool versus siblings like venues_available_on_date or list_venues.

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, so the safety profile is covered. The description adds useful behavioral context: stays are fixed 7-day weeks, arrival must be a Saturday, non-Saturday dates are rejected, and only venues with real availability are returned. It doesn't detail pagination or exact response shape, but for a read-only lookup tool this is strong.

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 states the core purpose in the first sentence, then adds the critical date-format constraint, then the return behavior, then the sibling differentiation. Every sentence earns its place with no 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?

For a read-only lookup tool with 100% schema coverage and no output schema, the description covers the essential context: what it returns, the date constraints, the default behavior, and when to use it instead of list_venues. It could mention whether results are sorted or limited, but nothing critical is missing for an agent 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%, so the schema already documents all four parameters. The description adds value by explaining the relationship between date and month (mutually exclusive modes), the Saturday constraint, and the default-to-current-month behavior, which goes beyond the schema's individual 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 states a specific verb ('Check'), a specific resource ('Angling Lines venues'), and a precise scope ('genuinely have space for a party'). It also explicitly distinguishes itself from list_venues, making it clear this is the availability-checking tool, not the general listing 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?

The description explicitly says 'Use this — not list_venues — whenever the question is about what is free or bookable.' It also explains the two modes (single Saturday vs whole month) and the date format requirements, giving clear when-to-use guidance and naming the alternative.

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