Skip to content

Releases: ffleurey/mcpscope

v0.1.1

Choose a tag to compare

@ffleurey ffleurey released this 08 Jul 20:59

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 serve http://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 the BACKEND_HOST / BACKEND_PORT environment variables (e.g. BACKEND_HOST=0.0.0.0 to 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/health now reports host, port, and connectable url / mcpUrl.

Breaking-ish: if you pointed an MCP client or script at the old default http://localhost:3030, update it to http://localhost:3066 (or pass --port 3030 / set BACKEND_PORT=3030 to 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

Choose a tag to compare

@ffleurey ffleurey released this 07 Jul 22:35

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.