MCP HeartbeatTHE MCP OBSERVATORY
Public workspace

Explore

Evidence for your next connection.

Independent measurements of remote MCP servers. Every observation has a timestamp.

Read-only probes

MCP server · Code & DevOps

ourpr.

Measured race courses, open to all, and your own runs, Blocks and plans once you sign in.

Checks passed
12 / 22

2 failed · 8 not measured

Median response
895 ms

Median of successful probes over 7 days

30-day uptime
Not measured

Share of countable probes over 30 days, including daily rollups. Auth challenges are excluded.

Discovered tools
18

Tool definitions returned by this server

Independent monitoring

Health & checks

Status history

Outdated check

Last connection measurement is over 24 hours old. Current availability is unknown.

Last checked
Check summary by test group
Test areaPassedFailedUnmeasured
ConnectionCan a client connect and discover tools?
500
Reliability & speedDoes it respond consistently and quickly?
004
Access & authenticationWhat is required to use this server?
102
Tool qualityAre the tool definitions usable by an agent?
400
Publisher identityCan the publisher be traced to its source?
222

Unmeasured means there is not enough evidence to decide. How these checks work

Inspect individual checks 22 recorded

Core

  • Pass
    Reachable

    Latest probe returned HTTP 200 in 895 ms.

  • Pass
    Valid handshake

    protocolVersion 2025-11-25, serverInfo.name ourpr-courses-mcp-server.

  • Pass
    Lists tools

    tools/list returned 18 tools.

  • Pass
    Current protocol

    Negotiated 2025-11-25. The bar is 2025-06-18 or newer.

  • Pass
    HTTPS

    The endpoint URL is https.

Performance

  • Not measured
    Fast (p50)

    Median latency 895 ms over 1 samples in 7 days. The bar is 1000 ms. Need at least 5 samples.

  • Not measured
    Consistent (p95)

    95th percentile 895 ms over 1 samples in 7 days. The bar is 3000 ms. Need at least 20 samples.

  • Not measured
    Reliable (uptime)

    1 of 1 attempts returned a tool list in 30 days (100%). The bar is 99%. Need at least 30 samples.

  • Not measured
    Stable tool list

    Fewer than two successful probes in 30 days, so tool-list stability is not measured.

Access

  • Pass
    Open access

    tools/list succeeded with no credential, and the record declares none.

  • Not measured
    Standard auth

    Auth is not required, so the OAuth metadata check does not apply.

  • Not measured
    Free tier cited

    No publisher quote has been checked.

Tools

  • Pass
    Tools described

    Every tool description is at least 20 characters.

  • Pass
    Valid input schemas

    Every inputSchema is a JSON Schema object.

  • Pass
    Parameters documented

    41 of 41 parameters have a description (100%). The bar is 80%.

  • Pass
    Safety hints

    Every tool sets readOnlyHint or destructiveHint.

Publisher

  • Pass
    Verified namespace

    Listed in the Official MCP Registry.

  • Not measured
    Website matches publisher

    This namespace is not a reverse domain, so the website comparison does not apply.

  • Fail
    Source repo linked

    No repository URL is on file.

  • Fail
    Repo owner matches

    The GitHub repository owner does not match the namespace login.

  • Pass
    Recently updated

    Updated 2026-09-27T00:24:07.628098Z, within 180 days.

  • Not measured
    Open-source licence

    No GitHub repository to ask about a licence.

Start using ourpr.

Connect to this server

Choose your client, copy the configuration, then enable the server in your client’s MCP settings.

Run this command in your terminal, then restart Claude Code.

Claude Code

claude mcp add --transport http ourpr https://ourpr.app/api/mcp

Capabilities

Tools 18

ourpr_detect_reps

Whether one particular run was an interval session, and its reps.

Discovered
ourpr_get_course

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 } `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.

Discovered
ourpr_get_course_amenities

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.

Discovered
ourpr_get_course_route

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.

Discovered
ourpr_get_course_terrain

The elevation profile of one course, sampled, plus every climb and descent ourpr. named on it. THIS IS THE TOOL FOR "what are the hills and where". Each named section carries the street it runs on, the miles it spans, its net rise or fall and its average grade. The elevation comes from a public terrain model sampled along the measured centerline (elevation_source names it), not from a watch barometer. A barometer drifts; the model is checked against published race figures. Args: - slug (string): From ourpr_list_courses. - points (number): Elevation samples to return, 2 to 200. Default 40. The stored profile holds up to 4,873. - response_format ('markdown' | 'json'): Default 'markdown'. Returns: { "slug": string, "name": string, "distance_mi": number, "climb_ft": number | null, "descent_ft": number | null, "min_ft": number | null, "max_ft": number | null, "steepest_pct": number | null, "climb_ft_per_mi": number | null, "elevation_source": string, "profile_points_stored": number, "profile": [{ "mi": number, "ft": number }], "named_sections": [{ "kind": "climb" | "descent", "name": string, "from_mi": number, "to_mi": number, "net_ft": number, "grade_pct": number }], "page_url": string } The sampled profile always keeps the first point, the last point, the highest and the lowest, so its extremes agree with min_ft and max_ft. A course with no named sections returns an empty array. That means the seeder found no stretch that qualified, not that the course is flat: read climb_ft. Examples: - "What are the hills on Boston?" -> slug="boston-marathon" - "Is Houston flat?" -> slug="houston-marathon", read climb_ft_per_mi - "Give me the profile in detail" -> points=200 Error handling: - Returns the slug list suggestion when the slug is unknown.

Discovered
ourpr_get_run

One activity in full: mile splits with heart rate, cadence, calories, device. Id comes from ourpr_list_runs. For the profile along the route, use ourpr_run_stream.

Discovered
ourpr_get_trail_system

Read one trail system: how many miles of path it holds, how many ways were mapped, where it sits, and where the measurement came from. Args: - slug (string): From ourpr_list_trail_systems. Example: 'trinity-trails'. - response_format ('markdown' | 'json'): Default 'markdown'. Returns: { "slug": string, "name": string, "region": string | null, "total_mi": number, // every branch summed "mapped_ways": number | null, // OpenStreetMap ways in the network "source": string | null, // how the network and its coverage were built "bbox": { "min_lat": number, "min_lng": number, "max_lat": number, "max_lng": number } | null, "page_url": string } `total_mi` counts the whole network. It is not a distance anyone runs in one go. Examples: - "How many miles of trail are in Fort Worth?" -> slug="trinity-trails" - "Where does the network reach?" -> read bbox Error handling: - Returns the slug list suggestion when the slug is unknown.

Discovered
ourpr_list_courses

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.

Discovered
ourpr_list_plans

The runner's planned runs between two dates: day, name, miles, time, tag, the runner's note, whether a logged run fulfilled it, and whether ourpr. create wrote it. Read it before ourpr_plan_week so a new plan does not land on a day that already holds one.

Discovered
ourpr_list_races

Every race ourpr. finds in the history, newest first, tune-ups included: date, name, distance, time, pace and run id. Also the fastest result at 5K, 10K, half marathon and marathon among them.

Discovered
ourpr_list_runs

Training history between two dates, newest first: date, local start, name, type, miles, pace, time, elevation, average heart rate, and on a runs-only list Friel's efficiency factor and the heartbeats each mile took. Start here for totals, streaks, trends, or finding a run. For one run's splits, use ourpr_get_run with an id from here.

Discovered
ourpr_list_trail_systems

List every trail system ourpr. maps. A trail system is a whole network of connected paths, measured end to end, not a single route through it. Args: - response_format ('markdown' | 'json'): Default 'markdown'. Returns: { "count": number, "trail_systems": [{ "slug": string, // "trinity-trails" "name": string, "region": string | null, // "Fort Worth, TX" "total_mi": number, // the whole network, all branches "page_url": string }] } Examples: - "What trail networks does ourpr. map?" -> no arguments - "How big is Trinity Trails?" -> read total_mi, or call ourpr_get_trail_system - Do not use when: you want one measured route. Use ourpr_list_courses with kind='trail'.

Discovered
ourpr_plan_week

Write one planned run, or a week of them, onto days still ahead. Each lands on the runner's week as a plan they can see, edit and remove. Needs a token made with the write scope and ourpr. create. Never logs a run.

Discovered
ourpr_rep_workouts

Interval sessions found across the history, with reps and distances. Detection is conservative, so a session it misses is still in ourpr_list_runs.

Discovered
ourpr_run_laps

The laps the watch recorded for one run — the runner's own button presses. Laps follow the workout; mile splits follow the mile.

Discovered
ourpr_run_stream

A run's profile on a 10 m grid — elevation, heart rate, power, cadence — as min, average, max and coverage per channel, not every sample. Also each half by distance with its moving pace, heart rate and efficiency, the pace change between them, and the drift (aerobic decoupling, Pa:HR), also after the warm up. No profile is a normal answer for an indoor run.

Discovered
ourpr_similar_terrain

Stretches of past runs matching a distance and climb — what the runner has already done that resembles a race they are training for.

Discovered
ourpr_training_blocks

The goal race and its Block: race day, distance, goal time, which week of the Block today falls in, and miles for each week. Also the Blocks before past races, each with its result, weeks and peak week. A Block is the race-anchored Monday to Sunday weeks before a race.

Discovered

Recent measurements

Probe history

View status
Latest stored probes. Raw probe rows are kept for 14 days.
CheckedResultResponseTools
Connected895 ms18