Skip to main content
Glama

ourpr.

Get one course

ourpr_get_course
Read-onlyIdempotent

Read one published course: its place, distance, climb, how it was measured, and which streets carry it.

DELIBERATELY WITHOUT the elevation profile, the amenities and the centerline. Those are three more tools, because one course payload is about 83 KB and 91% of it is the profile.

Args:

  • slug (string): From ourpr_list_courses. Example: 'boston-marathon'.

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

Returns: { "slug": string, "name": string, // the event's own name, title sponsor included "place": string | null, "alternate_names": string[], // curated geographic aliases "kind": string, "course_type": string, "distance_mi": number, // the stated race distance "measured_mi": number | null, // the centerline ourpr. measured "next_race_date": string | null, "days_out": number | null, "climb_ft": number | null, "descent_ft": number | null, "min_ft": number | null, "max_ft": number | null, "steepest_pct": number | null, "provenance": string | null, // one sentence on how it was built "sources": [{ "label": string, "value": string }], "recorded_on": string | null, // the watch that recorded the seed run "main_ways": [{ "name": string, "mi": number, "share_pct": number }], "through": string[], // named places the line passes through "photo_count": number, "counts": { "named_climbs_and_descents": number, "amenities": number, "mile_markers": number, "profile_points": number }, "page_url": string, "gpx_url": string }

distance_mi is what the race calls itself; measured_mi is what the centerline measures. They differ by a few hundredths and both are reported rather than reconciled.

Examples:

  • "Tell me about the Boston Marathon course" -> slug="boston-marathon"

  • "How much does San Diego climb?" -> slug="san-diego-marathon", read climb_ft

  • Do not use when: you want the hill-by-hill shape. Use ourpr_get_course_terrain.

Error handling:

  • Returns the slug list suggestion when the slug is unknown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe course's slug, exactly as ourpr_list_courses returns it. Example: 'boston-marathon'.
response_formatNoOutput format. 'markdown' reads well in a chat answer. 'json' carries every field for further computation.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
nameYes
slugYes
placeYes
countsYes
max_ftYes
min_ftYes
gpx_urlYes
sourcesYes
throughYes
climb_ftYes
days_outYes
page_urlYes
main_waysYes
descent_ftYes
one_way_miYes
provenanceYes
course_typeYes
distance_miYes
measured_miYes
photo_countYes
recorded_onYes
steepest_pctYes
next_race_dateYes
alternate_namesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds substantial context beyond that: why fields are omitted (83 KB payload, 91% profile), the deliberate reporting of both distance_mi and measured_mi without reconciliation, and the slug-unknown 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.

Conciseness4/5

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

The main purpose and exclusions are front-loaded in the first sentences, and the detailed Returns block is justified for a data-rich tool. However, the block is quite long and includes many inline comments that could be trimmed slightly without losing value.

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 read-only, idempotent tool with an output schema, the description is complete: it gives examples, error handling, sibling routing, field semantics, and format guidance. Nothing an agent needs to select and invoke it correctly is missing.

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 both parameters are already fully documented. The description adds useful context like the slug source ('From ourpr_list_courses') and the purpose of response_format, but this is incremental rather than essential.

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 opens with a specific verb and resource: 'Read one published course' and then enumerates exactly the fields it returns. It explicitly distinguishes itself from siblings by stating it is deliberately without elevation profile, amenities, and centerline, and that those are separate 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 provides clear usage context with examples and an explicit 'Do not use when' for terrain, naming ourpr_get_course_terrain as the alternative. It notes that amenities and route data live in 'three more tools' but does not name those specific sibling tools, so routing is not fully comprehensive.

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