Tiny Replay, now as an MCP server

Last week I made Tiny Replay, which turns a run, a ride or a hike into a tiny illustrated replay on the real map. To use it you had to go to Strava, find the activity, export the file and drop it on the page.

Now it has an MCP server, so you can just ask. This is what happens when I do:

Open it in Tiny Replay ↗

That is the actual replay from the actual conversation, playing inside this page. One message, and the answer is a link. Try the other two tabs.

The last one is my favourite, because there is nothing to fetch. I didn’t record the run, so the route comes from OpenStreetMap’s router instead, down the Castellana and the Prado, and 5:20 a kilometre becomes 31:32. Kipchoge doesn’t come from Strava either: the course is the Prater as the INEOS 1:59 Challenge describes it, with two runners on it.

Two servers that don’t know each other

Tiny Replay knows nothing about Strava. It has no integration, no app registered with Strava, no login. Claude already has a Strava connector, and Tiny Replay now has an MCP server with one tool, make_replay. The assistant reads from one and writes to the other.

That is what I like most about MCP: two services that were never designed to work together, and the model in the middle does the glue. The part that was mine to design was only the handoff: what one tool gives the model, and what the other one asks for.

The one problem worth solving

The obvious version doesn’t work. Tiny Replay needs the route point by point, a position and a time every second. My half marathon is 5,838 of those, and Strava hands them over as 155,000 characters. That didn’t even fit in a single tool result: Claude Code had to save it to a file. Asking the model to copy it into another tool is tens of thousands of tokens of numbers copied by hand, and sooner or later a digit comes out wrong.

But Strava already has a small version of every activity: the route as an encoded polyline, plus the start and the elapsed time. That is enough. The replay follows the polyline, and the shape is exact.

The polyline on the right is the whole race, all 21.3 km of it. The half marathon went to Tiny Replay as 1.3 KB, and Kipchoge’s whole marathon, both runners, as 1.4 KB.

The description is the interface

When I tested it, the heavy part turned out to be on the other side: finding the activities. Asking Strava for the splits of one run brings back every segment on it, about a hundred on mine, and a page of activities with their routes came to 71,000 characters.

I can’t change Strava’s server, but I can change what mine tells the model. So make_replay’s description says that splits are optional and not worth an extra call per activity, and to pick runs by what the activity list already says (date, distance, name) instead of trying to read where a route goes. A tool’s description is the only documentation the model reads, and it decides how much work the whole chain does.

A link that never reaches a server

Tiny Replay has no server, and the file you drop on it never leaves your browser. I wanted to keep that.

So the MCP server doesn’t store anything. It takes the activities, checks them by building the same track the page will build, and packs them into the link itself, after the #. The browser never sends the part after the # to the server, so opening the link doesn’t send your run anywhere. The page reads it and plays it. The replay above is exactly that: a link, framed.

The server is about a hundred lines of JavaScript with no dependencies, a Vercel function next to the app that reuses the page’s own code to check what it gets.

How to add it

Closing

Most of the work went into one decision: what to pass between the two tools. The rest is plumbing. If you run, add it and ask for your last run.