Skip to content

v1.108.313 — An install created before a default can never learn there is a choice

Choose a tag to compare

@jgravelle jgravelle released this 31 Aug 18:58
· 3 commits to main since this release

An install created before a default can never learn there is a choice

tool_surface is written into a config exactly once, on a genuinely first-ever install, and is deliberately kept out of the config template so a package update can never inject it. That freeze is correct — it is what stops an upgrade silently collapsing your tool list.

It also means an install created before the counter default stays on full permanently, because nothing revisits it. The change was made unreachable rather than offered.

jcodemunch-mcp surface and jcodemunch-mcp install-status now print a one-time priced offer, computed on your install at the moment you run it:

Tool surface: full (91 tools, 26,943 schema tokens)
  A new install today would default to 'counter' (6 tools, 1,050 schema tokens).
  Switching would remove 25,893 tokens from your tool-schema block.
    basis: one_time_at_full_rate_then_cache_read
  85 tools would stop being advertised. They stay callable through order/menu/route.

  Switch:  jcodemunch-mcp config set tool_surface counter
  Undo:    jcodemunch-mcp config set tool_surface full
  Silence: jcodemunch-mcp config set surface_offer_seen true

It is a message, not a migration. Nothing changes until you run the switch command, the undo is one command in the other direction, and doing nothing is a supported permanent answer — no countdown, no eventual default flip. The saving carries its basis: the schema block is stable across requests, so it is payload size, not a per-request saving.

Also fixed: three readers of one conflation

__version__ comes from importlib.metadata, frozen at install time and never read from the tree. Three things treated it as evidence about which code is running.

  • install-status source drift false-alarmed on every editable install (the module is imported from the tree, so a new process cannot load stale code) and was blind to the copied install that caused the incident it was written for. drifted is now about code; the new metadata_stale is about the recorded version, which is what serverInfo reports to your MCP host.
  • The process registry's version is identical across every process on a source install, so it could not answer "is this old server running old code?". code_stale answers it from process start time against source mtime.
  • CONFIGURATION.md still described the tool-schema block as a fixed per-turn cost. It is paid at full rate roughly once per cache lifetime and at cache-read rates thereafter.

install_layout.py is the new single authority for "where does this install's code come from?" — a question that had grown three separate answers.


Tests: 9078 passed / 13 skipped / 0 failed locally; 9091 total on every CI job across Python 3.10–3.13 on Ubuntu and Windows.