Skip to main content
Glama

Angling Lines

by com.anglinglines
OverviewDiscussionsAdmin

Get Quote

get_quote
Read-onlyIdempotent

Quote one Angling Lines venue for one fixed 7-day week: give a venue name or slug, a Saturday arrival date (YYYY-MM-DD) and the party, and get the total price for the whole party for the whole week. Prices come from the live booking engine — the venue price plus the cheapest Channel crossing for the vehicles quoted — and are in GBP. Returns a structured "unavailable" result, not a price, when that week is not free for that party.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
carsNoNumber of cars travelling — crossing costs are per vehicle. Ask when unknown for a crossing quote; do not silently assume 1. Pass 0 for a van-only party. Defaults to 1 for older callers.
dateYesThe Saturday arrival date of the 7-day week, as YYYY-MM-DD. Every stay runs Saturday to Saturday.
vansNoNumber of vans travelling. Preserve the customer's count in all crossing and booking calls. Defaults to 0.
swimsNoChosen swim numbers from list_swims; omit for suitable available defaults. Requote after changing swims.
venueYesThe venue to quote, by name or slug, e.g. "Beaurepaire".
anglersYesActual number of fishing guests supplied by the customer, never a package or swim capacity. Keep 2 guests as 2 even for a package with capacity 5.
exclusiveNoQuote the venue exclusively for this party. Some party sizes force exclusive use anyway.
non_anglersNoNumber of non-fishing guests. Defaults to 0.
booking_optionNoGolden Carp Lake whole package explicitly chosen by the customer after seeing available list_swims options: 1 cabin & swim 1; 2 all of swims 2,3,4; 3 exclusive without cabin; 4 exclusive with cabin. Never infer a package from a single swim preference such as swim 4. Required for GCL.
include_crossingNoTrue when the customer wants a crossing, including cheapest crossing at a crossing-optional venue. False for venue-only. Omit to use the venue default.
accommodation_idsNoSelected accommodation IDs returned by list_swims for this date. GCL booking_option includes the matching cabin automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Angling Lines toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources