fix(mcp): launch PAL via uvx from PyPI - #232
Merged
Merged
Conversation
The entry ran `uv run --project` against a local checkout at an absolute path under /Users/lgates, which only exists on one machine. It had also stopped working entirely: the checkout pins `required-version = ">=0.8.17,<0.12"` while current uv is 0.12.x, so every project command failed with `error: Required uv version ... does not match the running version` and the server never started. `uvx pal-mcp-server` resolves the published package (PyPI 10.5.0, released by the project's own release-please workflow via trusted publishing), needs no local install or checkout, and completes an MCP initialize handshake in 0.6s. Any env block on the entry is preserved unchanged. The server key is renamed `pal-mcp-server` -> `pal` so the exposed tools are `mcp__pal__*` in every repo. The two names were split roughly half and half across the fleet, so guidance naming one of them silently missed in the others even when the server was healthy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WFdCCsngcpLhXmSNPacr2W
Bare `uvx pal-mcp-server` does not check the index on a normal run. It
prefers a copy installed with `uv tool install` when one exists, and
otherwise reuses whatever it first cached -- with no time-based expiry, so a
machine can sit on an old build indefinitely and a published fix never
reaches it.
Measured against a machine holding 10.4.4 while PyPI served 10.5.0:
uvx pal-mcp-server -> 10.4.4
uvx --refresh pal-mcp-server -> 10.4.4
uvx --reinstall pal-mcp-server -> 10.4.4
uvx --refresh-package ... pal-mcp-server -> 10.4.4
uvx pal-mcp-server@latest -> 10.5.0
uvx --isolated pal-mcp-server -> 10.5.0
`--refresh` and `--reinstall` act on the wheel cache, which is not what
selects the version here, so neither overrides the preference. `@latest`
does, and is the form the uv docs give for this.
Cost is one index round-trip per server start: 0.8-1.1s against 0.5s
cached. The trade is that a start now wants network; PAL is a network client
anyway, so an offline start had little to do.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFdCCsngcpLhXmSNPacr2W
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Points this repo's PAL MCP entry at the published package and renames the server key to
pal:Any
envblock on the entry is preserved byte-for-byte; onlycommand/argsand the key change.Why
A fleet-wide sweep of the 13 repos configuring PAL found five different launch shapes, four of them either broken or unable to run anywhere but one laptop. Each shape was probed with a real MCP
initializehandshake:uvx pal-mcp-server(PyPI)pal-mcp-serverbinaryuv tool installhas runuvx --from git+…uv run --project <local checkout>rc=2uvx --from git+…BeehiveInnovationsWhen the server fails to start, the agent sees no PAL tools at all and falls back to invoking PAL by hand — which is the behaviour that prompted the sweep.
pal-mcp-serveris on PyPI at 10.5.0, published by the project's ownrelease-pleaseworkflow via trusted publishing (OIDC), so the package is the same code the git URL was building — without the clone, the local install, or the network dependency.The rename
The server key was
pal-mcp-serverin nine repos andpalin four. That changes the exposed tool names betweenmcp__pal__*andmcp__pal-mcp-server__*, so any skill or rule naming one form silently missed in the other half of the fleet even where the server was healthy. Standardising onpalmatches the canonical registry in the dotfiles repo (.chezmoidata.toml,[mcp_servers.pal]).Local
.claude/settings.local.jsonenablement lists were updated to match in the same pass. Those files are gitignored, so they are not part of this diff.Verification
The rewritten entry was launched exactly as configured —
uvx pal-mcp-server, with the entry's ownenvapplied — and completed an MCPinitializehandshake, reporting PAL 10.4.4 from cache.🤖 Generated with Claude Code
https://claude.ai/code/session_01WFdCCsngcpLhXmSNPacr2W