Versioning

PipMCP never changes what agents see behind your back. Imports create versions, edits create versions, and nothing reaches an MCP endpoint until it is published.

Integration versions

Every import, whether manual, through the API or from an automatic refresh, creates a new integration version with its own operations, schemas, auth schemes and tools. Versions are immutable. When a newer import finishes, older unpublished drafts are marked superseded.

Version statuses:

Status	Meaning
pending / processing	The import is running.
review	Finished; waiting for review and publishing.
ready	Published or ready to publish.
failed	The import failed; see the error and retry.
superseded	Replaced by a newer draft before it was published.

A scheduled refresh that downloads the same file as the last import stops there and does not create a version. A re-import you start yourself still creates a version, and the diff marks it unchanged when the normalized spec matches.

Diffs

Each version is compared with the one before it. The diff lists:

• Endpoints added, removed and changed (request body, parameters or response).
• Authentication changes.
• Tools added, removed and changed (input schema), including newly required inputs.
• Breaking changes, flagged separately.

A change counts as breaking when:

• an endpoint or a tool is removed,
• a parameter becomes required, is removed, or changes type,
• a request body gains a new required field,
• a tool gains a new required input,
• the authentication scheme changes.

Publishing an integration version

Publishing makes a version's tools the ones MCP endpoints serve. It is blocked while:

• the import has not finished,
• uncertain mappings still need review,
• any tool is failing its quality checks.

When you publish, each tool's previous published version is retired and replaced; tools that no longer exist in the new version stop being served. Endpoints pick up the change right away.

Until you publish, endpoints keep serving the previously published version, even if a newer import exists.

Auto-publish safe changes

For integrations with automatic refresh you can turn on auto-publish safe changes. A refreshed version is then published automatically only if it has no breaking changes and nothing needs review. Anything else waits for you.

Tool versions

Editing a tool (description, risk level, input schema or execution plan) creates a new tool version. Static tests and quality checks run again. Publish the tool to make the edit live. A tool can only be published on its own when it belongs to the integration version that is currently published; otherwise, publish the integration version first.

Renaming a tool or changing its visibility or confirmation setting takes effect without a new version.

Recommended workflow

1. Import or refresh.
2. Read the diff, especially the breaking changes.
3. Resolve anything marked Needs review.
4. Publish.
5. Watch Executions for new errors after the change.