feat(plugin): install the MCP server from PyPI

[gbrlcustodio]

What

Switch the bundled plugin .mcp.json (and the MCP package README's launch snippets) from uvx --from git+...#subdirectory=... to a plain PyPI install: uvx --prerelease allow pipefy-mcp-server.

Why

The bundled config launched the server from git subdirectory refs, so every /plugin install and --refresh cloned the repo and built four workspace members (pipefy, pipefy-auth, pipefy-infra, pipefy-mcp-server) from source. All five packages now publish to PyPI on every tag (#365), so uvx resolves pipefy-mcp-server and its dependency closure straight from the index, with no clone or build.

--prerelease allow is required while the 0.x line ships only pre-release versions (a plain uvx pipefy-mcp-server finds nothing installable when only pre-releases exist). It drops once a stable release is published; the README documents that.

Scope

• .mcp.json: the zero-config default the plugin ships.
• packages/mcp/README.md: the install block and the claude mcp add snippet, to match.

Left for a separate follow-up (a broader docs pass, not the programmatic install path):

• The root README.md CLI install blocks (uvx --from git+...packages/cli) and its pre-1.0 "not yet on PyPI" policy prose.
• commands/install.md (the CLI installer command).

Context

This is the surviving, still-relevant piece of the old #260 (install via release wheel URLs). #260's Release-wheel-URL approach is superseded now that PyPI publishing is live: PyPI is simpler and also removes the clone/build. #260 can be closed.

Test

• .mcp.json parses as valid JSON.
• All five distributions are live on PyPI at the current pre-release (0.3.0a1), so uvx --prerelease allow pipefy-mcp-server resolves the full closure from the index.

[adriannoes]

Summary

Moving the bundled plugin config from git subdirectory refs to PyPI is the right follow-up to #365 — it removes the clone/build cost on every /plugin install and keeps the diff focused on the programmatic install path (.mcp.json + MCP README).

I ran a clean-cache smoke test before reviewing:

• uvx pipefy-mcp-server --version → installs 0.3.0a1 with mcp 1.28.1, prints 0.3.0-alpha.1, exit 0
• uvx --prerelease allow pipefy-mcp-server --version → resolves mcp 2.0.0b1, crashes on ModuleNotFoundError: mcp.server.fastmcp, exit 1

So the proposed --prerelease allow flag both isn't needed for the named pre-release app and actively breaks the default install by upgrading transitive deps to MCP 2.x pre-releases.

What worked well

• PyPI migration aligns with #365 (all five wheels on the index) and supersedes the wheel-URL approach from #260.
• .mcp.json and packages/mcp/README.md stay in sync.
• Scope is deliberately tight; deferring root README / commands/install.md is reasonable.

Related PRs (merge context)

• #365 (merged) — prerequisite; PyPI publishing on every tag makes this PR possible.
• #367 (open) — sibling dep pinning + plugin manifest lockstep; independent of this diff but worth landing soon for published metadata correctness.
• #369 (draft, stacked on this branch) — user-scope Claude Code registration; should land after this PR settles the .mcp.json shape.

Required before merge

• Drop --prerelease allow from .mcp.json and the README snippets; use plain uvx pipefy-mcp-server and update the prose that claims the flag is required while only pre-releases exist.

[adriannoes]

Summary

The follow-up commit addresses the blocking issue cleanly: .mcp.json and the MCP README now use plain uvx pipefy-mcp-server, and the README documents why a global --prerelease allow must not be added back.

Re-ran clean-cache smoke on the current PyPI index: uvx pipefy-mcp-server --version → 0.3.0-alpha.1, exit 0.

What worked well

• Fix matches the review feedback and the author's inline explanation on the thread.
• PyPI migration goal from #365 is preserved without the transitive mcp 2.0.0b1 regression.
• Scope stays tight; deferred install surfaces remain appropriately out of band.

Good to merge into dev. #367 and #369 can proceed on their own tracks once this lands.