Skip to main content
Glama

ourpr.

Get water and toilets on a course

ourpr_get_course_amenities
Read-onlyIdempotent

Public drinking water and toilets on the line of one course, each placed at the mile it sits at.

READ THIS LIMIT BEFORE YOU ANSWER. These come from OpenStreetMap: public taps and toilets somebody mapped near the route. It is a FREQUENCY difference, not a category one — a race day sets up many more stops than an ordinary day has. A mapped tap can also be seasonal, shut off or gone. Never present this as an aid-station plan, and never imply the count is guaranteed.

It answers the training question instead: if I run this course on an ordinary day, where can I drink?

Args:

  • slug (string): From ourpr_list_courses.

  • response_format ('markdown' | 'json'): Default 'markdown'.

Returns: { "slug": string, "name": string, "distance_mi": number, "source": string, "is_race_aid_station_list": false, "water_count": number, "toilet_count": number, "longest_gap_without_water_mi": number | null, "longest_gap_from_mi": number | null, "longest_gap_to_mi": number | null, "amenities": [{ "kind": string, "mi": number, "lat": number, "lng": number }], "page_url": string }

The longest gap counts the start and the finish as ends, so a course with one water stop at mile 3 of 6 reports a 3 mile gap, not 0.

Examples:

  • "Where can I refill on the Cowtown ultra?" -> slug="cowtown-ultra-marathon"

  • "How far do I go without water on Boston?" -> read longest_gap_without_water_mi

  • Do not use when: you want race-day aid stations. ourpr. does not hold those.

Error handling:

  • A course with no mapped amenity returns empty arrays and zero counts. That means none is mapped, not that none exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe course's slug.
response_formatNoOutput format. 'markdown' reads well in a chat answer. 'json' carries every field for further computation.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
slugYes
sourceYes
page_urlYes
amenitiesYes
distance_miYes
water_countYes
toilet_countYes
longest_gap_to_miYes
longest_gap_from_miYes
is_race_aid_station_listYesAlways false. These are public amenities, not race aid stations.
longest_gap_without_water_miYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses critical behavioral nuances: the data source is OpenStreetMap, mapped taps may be seasonal/shut off/gone, and empty arrays mean 'none mapped' not 'none exist.' This adds essential interpretive guardrails that the annotations alone do not convey, and there is no contradiction with the readOnlyHint.

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

Conciseness4/5

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

The description is well-structured with clear sections (overview, limitations, args, returns, examples, error handling) and front-loads the core purpose. While it is longer than average, every sentence earns its place by addressing a specific concern or clarifying usage. The formatting aids scanability despite the length.

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?

With an output schema present, the description focuses on higher-level context: it explains the limitations, the training-use case, the 'Do not use' condition, and the meaning of empty results. Combined with the output schema and annotations, an agent has all necessary information to invoke this tool correctly and interpret its results. Nothing critical is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by specifying the slug should come from ourpr_list_courses and clarifying the response_format semantics ('markdown reads well in a chat answer, json carries every field for further computation'). This extra context makes the parameters more actionable than the schema alone, justifying a 4.

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 clearly states the tool's function: returning public drinking water and toilets on a course, positioned by mile. It explicitly differentiates from race-day aid stations, which distinguishes it from sibling tools like ourpr_get_course_route or ourpr_get_course_terrain. The title and verb align perfectly with the detailed purpose.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool ('if I run this course on an ordinary day, where can I drink?') and when not to ('Do not use when: you want race-day aid stations'). It also provides two concrete examples that map natural language queries to intended use, leaving no ambiguity about the selection context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources