Versioning & compatibility

Three components version independently but have to stay compatible:

Component	What it is	How you get it
primedelta (SDK)	The Python client	git install
primedelta-mcp (MCP server)	The tool server; depends on the SDK	git install
.mcpb (plugin bundle)	The Claude Desktop extension; pins an SDK + MCP	built from the MCP repo

The compatibility matrix

The MCP repo's RELEASING.md carries the authoritative SDK ↔ MCP ↔ .mcpb compatibility matrix — check it there when you pin versions:

• https://github.com/PrimeDeltaCorp/primedelta-mcp
• https://github.com/PrimeDeltaCorp/primedelta-python

The current plugin bundle's version is shown at the top of the generated plugin config reference; the tool surface it exposes is in the MCP tools reference. Both are generated from the code, so they always describe what's actually shipped.

What this means in practice

• Plugin users get a matched SDK + MCP inside the bundle — you don't manage versions yourself. Rebuild the bundle to update.
• Self-hosters install the SDK and MCP together. Install them from the same point in time (both from main, or both from a tagged release) so the MCP gets an SDK it was tested against.
• SDK-only users track the SDK on its own; the MCP compatibility matrix doesn't apply to you.

Pinning

Git installs track a branch by default. To pin, install from a tag or commit:

pip install "primedelta @ git+https://github.com/PrimeDeltaCorp/primedelta-python.git@<tag-or-sha>"

Pin the SDK and MCP to a matched pair from the compatibility matrix rather than mixing arbitrary revisions.

Stability

The API is pre-1.0 and can still change between releases. The generated references are the source of truth for the surface at any given version — read them for the version you've installed, not a remembered signature.