plugin: switch /pipefy:login + .mcp.json from #subdirectory pin to release-wheel URLs

[gbrlcustodio]

Problem

Workstream C (#229) ships the /pipefy:login slash command and .mcp.json MCP server entry using uvx --from "git+https://github.com/gbrlcustodio/pipefy-mcp-server#subdirectory=packages/<pkg>". Two real costs:

• Every plugin install pays a full git clone + setuptools/hatchling build pass for each workspace member that gets pulled in (pipefy-cli → pipefy-auth → pipefy-sdk). Slow first-run, slow every --refresh.
• The bare-form URL (uvx --from git+<repo> pipefy-cli) fails on the workspace-root pyproject.toml because setuptools default-discovers the flat packages/ + skills/ layout. #subdirectory= is a workaround, not a fix.
• pipefy-auth is a workspace dep declared in packages/cli/pyproject.toml and packages/mcp/pyproject.toml. uvx with #subdirectory=packages/<pkg> cannot resolve sibling workspace members through [tool.uv.sources] from a remote install — only --with chains save it. Manifest bloat.

Goal

Point the plugin at the pre-built wheels the release pipeline already ships to GitHub Releases. Today's release.yml (.github/workflows/release.yml:67-100) runs uv build --all-packages -o dist --wheel --sdist and verifies one SDK + CLI + MCP + Auth wheel per tag. Latest v0.2.0-beta.1 already carries three of the four (the Auth wheel will land in the next tag, since packages/auth was added on dev after the current tag).

Target .mcp.json:

{
  "mcpServers": {
    "pipefy": {
      "command": "uvx",
      "args": [
        "--with", "https://github.com/gbrlcustodio/pipefy-mcp-server/releases/download/v0.2.0-beta.2/pipefy_sdk-0.2.0b2-py3-none-any.whl",
        "--with", "https://github.com/gbrlcustodio/pipefy-mcp-server/releases/download/v0.2.0-beta.2/pipefy_auth-0.2.0b2-py3-none-any.whl",
        "--from", "https://github.com/gbrlcustodio/pipefy-mcp-server/releases/download/v0.2.0-beta.2/pipefy_mcp_server-0.2.0b2-py3-none-any.whl",
        "pipefy-mcp-server"
      ]
    }
  }
}

Same shape for commands/login.md (swap the MCP wheel for the CLI wheel).

Scope

1. Prerequisite tag: cut v0.2.0-beta.2 (or the next beta) from main after dev → main merge that includes packages/auth. Release workflow produces all four wheels and uploads them.
2. .mcp.json rewrite: drop #subdirectory= form; pin each --with / --from to release-wheel URLs at the new tag.
3. commands/login.md rewrite: same swap for the CLI wheel; preserve $ARGUMENTS passthrough.
4. Plugin version bump: .claude-plugin/plugin.json version and .claude-plugin/marketplace.json plugins[].version track the underlying release tag.
5. Release-workflow automation: extend release.yml to patch .claude-plugin/plugin.json, .claude-plugin/marketplace.json, .mcp.json, and commands/login.md to point at the just-cut tag's wheel URLs, then commit + push to main (or open a follow-up PR) on each tag. Without this, every release requires a manual plugin-manifest bump.
6. README + docs/setup.md Plugin install blocks: drop the uvx --from git+...#subdirectory=... callouts; just show /plugin install pipefy (wheel URLs are an implementation detail of the manifest).

Why this is separate from #229

#229 has to ship something that works today against the current dev snapshot, before a new release tag exists. The release-wheel path requires (a) the next beta tag and (b) the workflow automation. Doing it inside #229 blocks the slash command until the release cycle catches up.

Acceptance

• v0.2.0-beta.2 (or successor) release on GitHub carries all four wheels (SDK + CLI + MCP + Auth).
• claude plugin install pipefy@pipefy results in MCP server spawn that runs without git clone or local build — claude plugin details pipefy still reports MCP servers (1) pipefy.
• /pipefy:login runs the OAuth flow using only the release wheel URLs (pipefy_cli-*.whl + pipefy_auth-*.whl + pipefy_sdk-*.whl).
• Release workflow auto-patches the wheel URLs on tag; manual editing of the plugin manifest is not required for routine releases.
• README + docs/setup.md "Plugin install (Claude Code)" blocks no longer reference #subdirectory= or any git URL.

Related

• Builds on plugin: ship Claude Code plugin marketplace entry with /pipefy-login slash command #229 (initial plugin manifest + slash command).
• Cross-impact with install: one-command curl installer (CLI + MCP + skills + client config) #231 (curl installer) — same #subdirectory= workaround applies there; release-wheel approach unblocks both.
• Cross-impact with cli: default PIPEFY_AUTH_URL to Pipefy prod IdP #233 (CLI default PIPEFY_AUTH_URL) — independent, can land in either order.

Out of scope

• Refactoring root pyproject.toml to make bare uvx --from git+<repo> pipefy-mcp-server work directly (option 2a / meta-package in the prior discussion). Release-wheel URLs make that refactor unnecessary.

[gbrlcustodio]

Re-scoping this now that #368 landed on dev.

The .mcp.json half is done. #368 switched the bundled MCP server entry off the git+...#subdirectory=... pins to a plain PyPI install (uvx --prerelease allow pipefy-mcp-server), resolved by the every-tag PyPI publishing from #365. PyPI supersedes the release-wheel-URL approach this issue originally proposed: it drops the per-install clone + build without needing to patch wheel URLs into the manifests on each release. (The related #260, which tracked the release-wheel-URL path, is already closed for the same reason.)

What remains is the CLI install path, still on #subdirectory git refs and still paying a full clone + build on every install:

• commands/install.md (the /pipefy:login installer command)
• packages/cli/README.md (the documented install blocks)

Both should move to the same PyPI form (uvx --prerelease allow --from pipefy-cli ..., dropping --prerelease allow once a stable release is published), matching what #368 did for the MCP server.

Keeping this open, scoped to the remaining CLI install path.