ourpr.

Get a course's line

ourpr_get_course_route

Read-onlyIdempotent

Where a course actually runs: its start, its finish, its bounding box, every mile marker, and the streets in the order you meet them.

For a watch, hand over page_url: a signed-in runner sends the course to Garmin Connect from the page. There is no GPX download.

Args:

slug (string): From ourpr_list_courses.
include_polyline (boolean): Add the encoded centerline, about 9,800 characters. Default false.
response_format ('markdown' | 'json'): Default 'markdown'.

Returns: { "slug": string, "name": string, "course_type": string, "distance_mi": number, "start": { "lat": number, "lng": number } | null, "finish": { "lat": number, "lng": number } | null, "bbox": { "min_lat": number, "min_lng": number, "max_lat": number, "max_lng": number } | null, "mile_markers": [{ "mile": number, "lat": number, "lng": number }], "streets_in_order": [{ "name": string, "from_mi": number, "to_mi": number }], "polyline": string | null, "page_url": string }

On an out-and-back the start and the finish are the same point, by design.

Examples:

"Send me the Boston course for my watch" -> hand over page_url
"What streets does Dallas run down?" -> read streets_in_order
"Where does Honolulu start?" -> read start

Error handling:

Returns the slug list suggestion when the slug is unknown.

Input Schema

Name	Required	Description	Default
`slug`	Yes	The course's slug.
`response_format`	No	Output format. 'markdown' reads well in a chat answer. 'json' carries every field for further computation.	markdown
`include_polyline`	No	Add the encoded centerline. It runs to about 9,800 characters and only helps if you will decode it. Leave it off and hand over `page_url` instead.

Output Schema

Name	Required	Description	Default
`bbox`	Yes
`name`	Yes
`slug`	Yes
`start`	Yes
`finish`	Yes
`page_url`	Yes
`polyline`	Yes
`course_type`	Yes
`distance_mi`	Yes
`mile_markers`	Yes
`streets_in_order`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 3, 2026

changedInput schema / properties / include_polyline / description

Previous value: -"Add the encoded centerline. It runs to about 9,800 characters and only helps if you will decode it. Leave it off and hand over `gpx_url` instead."New value: +"Add the encoded centerline. It runs to about 9,800 characters and only helps if you will decode it. Leave it off and hand over `page_url` instead."

removedOutput schema / properties / gpx_url

Removed value: -{
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "slug",
-  "name",
-  "course_type",
-  "distance_mi",
-  "start",
-  "finish",
-  "bbox",
-  "mile_markers",
-  "streets_in_order",
-  "polyline",
-  "gpx_url",
-  "page_url"
-]New value: +[
+  "slug",
+  "name",
+  "course_type",
+  "distance_mi",
+  "start",
+  "finish",
+  "bbox",
+  "mile_markers",
+  "streets_in_order",
+  "polyline",
+  "page_url"
+]

First observedSep 26, 2026

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 goes well beyond them. It discloses that delivery to a watch requires the runner to be signed in and use the page (no GPX path), sizes the polyline at roughly 9,800 characters, explains the out-and-back start==finish case as intentional, and specifies the unknown-slug 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?

Front-loaded and cleanly sectioned into purpose, args, returns, examples, and errors, which is easy to scan. The cost is redundancy: the full JSON return shape duplicates the output schema, and the three examples restate obvious mappings an agent could infer.

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 tool with full annotations and an output schema, everything an agent needs is present: slug provenance, the watch-distribution path, edge cases (start equals finish), polyline cost, and error recovery. Nothing required to call it correctly is left to inference.

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, but the description adds real meaning by sourcing slug from ourpr_list_courses and framing include_polyline as a tradeoff (only useful if you will decode it) rather than a bare boolean. It does not meaningfully extend response_format beyond the schema's own explanation.

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 opening sentence names a specific resource and enumerates exactly what is returned: start, finish, bounding box, mile markers, and streets in order. That field list differentiates it from ourpr_get_course (basics), ourpr_get_course_terrain, and ourpr_get_course_amenities without the agent needing to open any schema.

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?

It tells the agent where the slug comes from (ourpr_list_courses) and gives a concrete decision rule for the "for my watch" case: hand over page_url because there is no GPX download. It stops short of explicitly naming which sibling to use instead for terrain or amenity questions, so routing is implied rather than stated.

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

All ourpr. tools Inspect

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

Need Help?