Releases: ffleurey/mcpscope
Release list
v0.1.1
A small patch release with one fix — and the first release published fully automatically by CI (npm, Docker/GHCR, and Electron installers all built and published by the tag-driven release workflow, with no manual publishing step).
Changed
- Fixed default port 3066 across all deployment modes (#1, #2).
mcpscope serve, Docker, and the desktop app now all servehttp://localhost:3066(MCP interface at/mcp). The desktop app previously picked a random free port on every launch and could not be configured; it now respects theBACKEND_HOST/BACKEND_PORTenvironment variables (e.g.BACKEND_HOST=0.0.0.0to reach it from WSL or Docker) and fails with an actionable message if the port is taken. - Server info in the UI: a new Server card on the Configuration page shows a listening indicator, the bind address, the Web UI URL, and the MCP endpoint with a copy button.
/api/healthnow reportshost,port, and connectableurl/mcpUrl.
Breaking-ish: if you pointed an MCP client or script at the old default
http://localhost:3030, update it tohttp://localhost:3066(or pass--port 3030/ setBACKEND_PORT=3030to keep the old address).
Release-pipeline shakedown
This version exists partly to exercise the automated release path end-to-end: npm trusted publishing (OIDC), the GHCR image (ghcr.io/ffleurey/mcpscope:0.1.1 / :0.1 / :latest), and the macOS/Windows/Linux desktop installers attached below.
mcpscope v0.1.0
The first public release. What mcpscope is, how to install it, and a worked example live in the README and TUTORIAL — this note is just the story of why it exists.
A couple of months ago I set out to build an MCP server for my home automation that could surface more insight and statistics than the tools I had, and immediately ran into the real problems of building for an LLM: writing tool descriptions that earn their tokens, managing context, and doing the data work server-side instead of handing raw data to the model. My target was small local models running in Ollama on an 8 GB GPU, so tiny models with about 8k of context.
I like that kind of constraint. I spend my spare time writing assembly for the VIC-20 and C64 and C for 8-bit AVRs, and an 8k context window feels a lot like managing memory on a small machine — every token has to earn its place. But I couldn't see enough of what was happening: OpenWebUI and the LM Studio chat show you the conversation, not how the model reasons, which tools it reaches for, or exactly how those 8k tokens get spent. So I built mcpscope to watch the harness work — tool calls and context management, part by part, token by token.
For about a month it was a personal instrument for my own curiosity. It turned out useful enough that I decided to challenge myself to clean it up and release it as open source — which was also a way to push a second experiment one step further: mcpscope has been built with coding agents throughout, across many models from small local ones to frontier ones. It's early. I'm about to put it to work on a couple of real MCP servers, and I fully expect it to keep changing.