Skip to main content

Overview

Jinba Toolbox uses a semver-based versioning system with immutable snapshots. Each toolset maintains a draft (the editable working copy) and a list of published versions. When you publish, a complete snapshot of the toolset — including all tool code, schemas, and sandbox configuration — is frozen as an immutable version that can never be modified. This design ensures reproducibility: running version 1.0.0 always executes the same code, regardless of when or where it is called.

Concepts

Draft vs. Versions

Immutable Snapshots

Each version captures a complete snapshot of the toolset at the time of publishing:
  • All tool code and entrypoints
  • Input and output schemas
  • Tool names and descriptions
  • Sandbox configuration (provider, language, packages, resources)
This means even if you later update the draft, existing versions remain unchanged.

Publishing Workflow

1

Edit the draft

Make changes to tools in the draft through the web console or the API. Use the test endpoint to verify behavior:
2

Publish a new version

When the draft is ready, publish it with a semver version number and optional release notes:
Or using the SDK:
3

Set the published version

Choose which version the API should serve. Newly published versions do not automatically become the active version — you must explicitly set it:
The change takes effect immediately.
4

Continue developing

The draft remains intact after publishing, so you can keep iterating on the next version without affecting the live published version.

Version Resolution

When a tool is executed via the run endpoint, Jinba Toolbox resolves which version to use:
  1. If the request body includes a version field, that exact version is used.
  2. Otherwise, the currently published (active) version is used.

Rollback

Rolling back is simply a matter of changing the published version to a previous one:
Because versions are immutable, no data is lost during a rollback. The newer version remains available and can be re-activated at any time.

Version API

Version Data Model

Each published version stores a full snapshot:

Usage Tracking

Jinba Toolbox tracks API call counts per version. You can view usage statistics in the web console or retrieve run history through the API:
Usage data helps you determine when it is safe to deprecate older versions.

Best Practices

  • Follow semantic versioning — use major bumps for breaking schema changes, minor bumps for new tools or features, and patch bumps for fixes.
  • Write release notes — they help your team understand what changed between versions.
  • Test before publishing — use the test endpoint to validate the draft before creating an immutable version.
  • Do not skip the publish step for MCP — MCP endpoints serve the published version, not the draft.
  • Monitor per-version usage — before deprecating a version, verify that no consumers still depend on it.