ChatGPX

Filippo Valle — Tue, 06 Oct 2026 07:33:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

chatGPX lets you chat with your own Komoot hiking, running, and cycling history. You log in with your Komoot account, the app downloads your tours as GPX files, and an LLM with tool access answers questions about them. The numbers come from the raw GPS tracks rather than from description text: distance (haversine), elevation gain and loss, elapsed time, and pace, with a monthly breakdown across your whole history. Where Komoot reports its own figures, they are shown alongside as a cross-check.

It is meant to send people outdoors. Questions like "which month did I climb the most?" or "what was my longest hike this year?" turn past outings into a record you can learn from and plan the next one against. It is aimed at hikers, runners, and cyclists who already log activities and want more than a dashboard. It is also a small, reusable example of exposing personal outdoor data to any MCP client.

Demo

Code

fvalle1 / chatGPX

chatgpx

Chat with your own Komoot hiking/running/cycling activities, and get real statistics computed from the raw GPS data — not just descriptions.

You log in with your Komoot email and password, the app pulls your tours as GPX files, and you can then chat with an LLM (over OpenRouter) that has tool access to that data via an MCP server — including tools that compute real distance, elevation and pace figures from the GPS track itself, not just whatever a description string happens to say.

How it fits together

server.py — an MCP server exposing tools over your downloaded GPX activities (list_activities, read_activity, get_activity_stats get_stats_summary, summarize, generate_activity_video) plus a docs://traces resource.
gpx_sync.py — logs in to Komoot and downloads all tours as GPX files (download_all_gpx(email, password, output_dir=...) -> list[Path]) compatible with what server.py reads.
chat_backend.py — connects to server.py over MCP…

View on GitHub

How I Built It

MCP server (server.py): exposes list_activities, read_activity, get_activity_stats, get_stats_summary, summarize, and an optional generate_activity_video. It can run over stdio or streamable-http, so any MCP client can use it.
Sync (gpx_sync.py): downloads tours as GPX using the open-source KomootGPX library, vendored as a git submodule. Filters for tour type, sport, and date range are optional.
Chat backend (chat_backend.py): connects to the MCP server and passes its tools to the LLM as function calls. It works with any OpenAI-compatible provider that supports tool calling, configured through OPENAI_BASE_URL and OPENAI_MODEL.
Web app (app.py): a small web app with a static frontend and /api/login and /api/chat endpoints.
Optional video: flyover clips from a self-hosted Cosmos3-Nano server.
Models used: [name the open-weight model(s) you ran and how, e.g. local inference or a hosted open-weight model].
Tooling: [mention Claude Code, Serena, or other agent harnesses if relevant, since .claude and .serena are in the repo].

Statistics are computed in code, not by the model. The LLM decides which tool to call and explains the result, which keeps the figures reproducible.

Why Does Open Innovation Matter?

Open standards (MCP, GPX) and open libraries (KomootGPX) allowed the project to be assembled in a short time.
Any OpenAI-compatible endpoint can be used, so the same code works with a hosted open-weight model or a fully local one.
Location history is personal data. Running the MCP server and inference locally means GPS tracks do not have to be sent to a closed API.
The video feature relies on a self-hosted model, which is not tied to a vendor's availability or pricing.

DEV Community: Filippo Valle