mcpbeat Sign in

ourpr. MCP Server

not responding

ourpr. is listed as active in the registry but did not answer our last check. It exposes 18 tools.

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

Uptime history 16 days of history · worst day 0%
16 days agonow
19.6%
Uptime 24h
18 of 92 checks
18
Tools
read from the server
468 ms
Response time
average over 24h
open, no key
Access
streamable-http

What changed 5

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 1 October 2026. No other catalogue keeps this.

3 Oct 3 tool descriptions were rewritten ourpr_get_run, ourpr_list_runs, ourpr_run_stream
1 Oct 2 tool descriptions were rewritten ourpr_get_course_terrain, ourpr_list_courses

ourpr. does not always answer

Over the last week it answered 17.1% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 5 min ago.

run in your terminal
claude mcp add ourpr-courses --transport http https://ourpr.app/api/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "ourpr-courses": {
      "url": "https://ourpr.app/api/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.ourpr-courses]
url = "https://ourpr.app/api/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "ourpr-courses": {
      "url": "https://ourpr.app/api/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "ourpr-courses": {
      "url": "https://ourpr.app/api/mcp"
    }
  }
}

Available tools 18

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

ourpr
ourpr_detect_reps
Whether one particular run was an interval session, and its reps.
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, "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.
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.
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. The GPX file is free and needs no account. Hand `gpx_url` to a person who wants the course on a watch. 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, "gpx_url": string, "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" -> read gpx_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.
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.
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.
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.
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.
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.
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.
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.
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'.
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.
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.
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.
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.
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.
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.

Endpoints

URLTransportStateLatencyChecked
https://ourpr.app/api/mcp streamable-http answering 94 ms 5 min ago

Alternatives to ourpr.

same job, measured the same way
T
Tokenizedblock
by philpof102-svg

Plan swaps of Coinbase tokenized stocks and TokenizedBlock blocks on Base; your wallet signs.

7 tools answering
Ourpr MCP Server
by joeyaflores

Read your own ourpr running history in an AI agent, and put a plan on the week ahead.

62 installs/wk local only
DiscordServers
by discordservers

Search Discord server listings, and manage your own servers once you sign in.

answering
Colaunched
by colaunched

Your Colaunched account: ideas scored for you, their evidence and your launch. OAuth sign-in.

answering
Yab, Yet Another Browser
by yetanotherbrowser

Your own signed-in Mac browser for any agent: open, read and act in tabs. Local and free.

428 installs/wk local only
context-doctor
by kushalp1

Cut your Claude Code bill, measured on your own sessions. Profile and slim any LLM conversation.

927 installs/wk local only
OBTO
by obto

Your AI builds, deploys, and runs full-stack apps on a hosted workspace created at first sign-in.

answering
DABLOCK AI Visibility Index
by dablock

Measured share of answer for 24 crypto and Web3 brands. An open dataset, not an audit of your site.

5 tools answering

ourpr. — questions

Answers built from our own checks of this server.

What can ourpr. do?
It exposes 18 tools, read directly from the server on our last check. Among them: ourpr_detect_reps, ourpr_get_course, ourpr_get_course_amenities, ourpr_get_course_route, ourpr_get_course_terrain, ourpr_get_run and 12 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is ourpr. working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 18 of 92 checks got a reply (19.6%), average response time 468 ms. The bar chart above shows every period we have measured.
The registry lists ourpr. as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
How do I connect ourpr.?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does ourpr. need an API key?
No. ourpr. completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 18 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is ourpr.?
It answers our handshake in 468 ms on average, which is faster than 28% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.