A content exploration toolkit that helps LLMs surface high signal, unsummarized web content.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
parkour
"an activity in which people move quickly around buildings and objects in a city while performing jumps and other skilful movements, usually trying to move between points as quickly, smoothly, and safely as possible"
Parkour is a content exploration toolkit that helps LLMs surface high signal, unsummarized web content. It makes extensive use of clean APIs and Markdown conversion to enable targeted content extraction and knowledge synthesis. A rolling 2Q page cache keeps recently visited pages in memory so that follow-up requests (section extraction, BM25 search, slice retrieval, comparison pivots) are served quickly and without additional round-trips. While primarily designed for Claude Code and Claude Desktop, it should be adaptable to most agentic toolchain needs.
API integrations:
What sets Parkour apart from the standard approaches are three principles:
We design our tool outputs with the LLM in mind. The LLM is our immediate user, and if our user has a good experience the humans behind them have an even better experience.
The standout feature of Parkour is a frontmatter tool envelope that intelligently advises the LLM and steers its decisionmaking. This is a fancy way of saying "our tool payloads are prefaced with instructional YAML frontmatter". It's a technique that is simple on its face but deceptively powerful.
Parkour also intercepts requests for content from websites with robust first-party APIs. When the LLM asks to fetch a URL that belongs to a known source, the server skips the generic HTTP-fetch-and-convert path and calls the source's structured API directly. Faster, richer metadata, no scraping:
| Source | Detection | API used |
|---|---|---|
| Wikipedia | /wiki/ URLs | MediaWiki API (clean markdown, footnotes, no navboxes) |
| arXiv | /abs/, /pdf/ URLs | Atom API (authors, affiliations, categories, versions) |
| Semantic Scholar | semanticscholar.org/paper/ | S2 Graph API (bypasses CAPTCHA) |
| DOI | doi.org/10.* URLs | Content negotiation (CrossRef/DataCite metadata) |
| GitHub | github.com/* | REST API (bypasses JS SPA) |
reddit.com, redd.it | Userless OAuth API (oauth.reddit.com, anonymous token, no account or API key) | |
| Discourse | x-discourse-route response header | JSON API with raw author markdown |
| IETF | rfc-editor.org/rfc/rfcN[.json], datatracker.ietf.org | RFC Editor JSON / Datatracker REST. .html/.txt/.xml body URLs deliberately fall through to the generic HTML pipeline so section= / search= work over the rendered RFC. |
For example, asking Parkour to fetch https://arxiv.org/abs/1706.03762 doesn't scrape the landing page. It returns structured metadata via the Atom API, with frontmatter hints pointing to the HTML full text and a Semantic Scholar cross-reference for citation counts:
The frontmatter does the heavy lifting here. full_text tells the LLM where to find the rendered paper. see_also steers it toward Semantic Scholar for citation data. shelf confirms the paper is now tracked for citation export. None of this required the LLM to guess or make extra tool calls.
LLMs lack training to be responsible scholars. They would be better at tracking citations than humans if they were instructed to do so, but most instructions for compacting context aren't designed to preserve these at all -- to say nothing about gathering those citations as they work.
While we can't do anything about the training, we can make sure the MCP server passively accumulates citations for actively browsed Github projects, research papers, and IETF publications. We can't force the LLM to do anything with those citations, but we do give it a little reminder nudge in the tool payload every time one of those citations are accumulated. This increases the odds that the LLM has access to that information when it's time to write documentation, which will reduce the odds of it being forgotten or hallucinated. Is the solution perfect? No, but we think it's a step in the right direction. Researchers will also find it legitimately useful. We're very open to feature suggestions on how this can be improved for academics.
We also do some errand running that the average user won't think of doing, let alone a LLM.
Modern LLM solutions have converged on agentic toolchains that pair cheaper text analysis LLMs (Haiku) with larger models that excel at reasoning (Opus), but sometimes the finer details get lost in this process. In a worst case scenario, sometimes these details get hallucinated during the summarization process...including the attributed authors of research papers and software. Considering that the very frontier of LLM capabilities live and die by the quality of research papers, this is unacceptable to us.
The best way to minimize the damage of LLM enshittification is to make it easy for their pilots to do the right thing. By providing a tool that synthesizes better data while also making a best effort to steer the LLM toward being a good netizen, we reduce the "litter" left in the wake of irresponsible LLM use. The caveat is that the quality of outputs must create the incentive to use the tool on their own merit, otherwise this MCP server would simply be yet another doomed recycling initiative.
There is no magic wand for making LLMs go away, so let's build LLM toolkits that make things better for more than just the venture capitalists.
Why is LLM summarization so popular?
Our counterpoint:
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/parkour-mcp)<a href="https://allmcps.com/mcp/parkour-mcp"><img src="https://allmcps.com/api/badge/parkour-mcp?style=directory" alt="Parkour MCP on AllMCPs" /></a>