Skip to main content
Glama

List published running courses

ourpr_list_courses
Read-onlyIdempotent

List every running course published on ourpr., with its place, distance, climb and next race date.

Each course is a MEASURED centerline built from recorded runs, with elevation from a public terrain model: USGS 3DEP 10 m in the US, and the city's own 1 m model in Berlin. It is not a course map traced by hand.

START HERE. Every other course tool takes a slug, and this is where slugs come from.

Args:

  • query (string, optional): Match the name and the place. Partial, case-insensitive.

  • kind ('race' | 'trail' | 'route', optional): Keep one kind.

  • course_type ('loop' | 'out-and-back' | 'point-to-point', optional): Keep one shape.

  • min_distance_mi / max_distance_mi (number, optional): Bound the distance in miles.

  • upcoming_only (boolean): Keep only courses whose race date has not passed. Default false.

  • limit (number): 1 to 50. Default 20.

  • offset (number): Skip this many. Default 0.

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

Returns: { "total": number, // matched the filters "count": number, // in this answer "offset": number, "has_more": boolean, "next_offset": number, // present when has_more "published_total": number, // every published course "courses": [{ "slug": string, // "boston-marathon" "name": string, // the event's own name, title sponsor included "place": string | null, // "Hopkinton → Boston, MA" "kind": string, "course_type": string, "distance_mi": number, "climb_ft": number | null, "steepest_pct": number | null, "next_race_date": string | null, // YYYY-MM-DD "days_out": number | null, // null once the date has passed "page_url": string }] }

The order is the race calendar: the soonest race first, then undated courses by distance.

Examples:

  • "What marathons does ourpr. have?" -> min_distance_mi=26

  • "Which race is next?" -> upcoming_only=true, limit=1

  • "Anything in Fort Worth?" -> query="fort worth"

  • Do not use when: you want the hills on one course. Use ourpr_get_course_terrain.

Error handling:

  • Returns "No course matched" with the filters echoed when nothing matches.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoKeep only this kind. 'race' is a published event course, 'trail' is a trail segment, 'route' is an everyday loop.
limitNoThe most courses to return.
queryNoMatch against the course name and its place. Case-insensitive, partial. Example: 'boston', 'fort worth', 'half'.
offsetNoHow many courses to skip. Use it with `next_offset`.
course_typeNoKeep only this shape of course.
upcoming_onlyNoKeep only courses whose next race date is today or later. A course with no date is dropped by this filter.
max_distance_miNoKeep only courses no longer than this, in miles.
min_distance_miNoKeep only courses at least this long, in miles.
response_formatNoOutput format. 'markdown' reads well in a chat answer. 'json' carries every field for further computation.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesCourses in this answer.
totalYesCourses that matched the filters.
offsetYes
coursesYes
has_moreYes
next_offsetNo
published_totalYesEvery published course, before any filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, and the description adds genuinely new behavioral context: the measured-centerline provenance and elevation model, the result ordering (race calendar, soonest first, then undated by distance), and the 'No course matched' error behavior. These are things an agent could not infer from the annotations or schema.

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?

Well front-loaded: purpose, provenance, routing guidance, then args/returns/examples/errors. The Returns block duplicates the output schema field-by-field, which is unnecessary given the schema exists, but the rest is dense and earns its space.

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 nine-parameter listing tool with full schema coverage, an output schema, and annotations, nothing an agent needs is missing: routing, ordering, defaults, error behavior and examples are all present.

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?

Schema description coverage is 100%, so every one of the nine parameters is already documented with types, bounds, defaults and enum meanings in the schema. The description's Args block largely restates that, adding only unit emphasis (miles). Baseline 3 is appropriate.

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?

States a specific verb and resource ('List every running course published on ourpr.') and enumerates the important returned fields right up front. The 'START HERE. Every other course tool takes a slug' line distinguishes it from all slug-taking siblings, and the explicit exclusion points to ourpr_get_course_terrain.

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?

Explicit when-to-use ('START HERE', source of slugs), an explicit do-not-use case routed to a named sibling, and four worked examples mapping natural-language questions to parameter sets. This is about as complete as usage guidance gets.

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