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 version1.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)
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 therun endpoint, Jinba Toolbox resolves which version to use:
- If the request body includes a
versionfield, that exact version is used. - Otherwise, the currently published (active) version is used.
Rollback
Rolling back is simply a matter of changing the published version to a previous one: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: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
testendpoint 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.
Related
- REST API — Full endpoint reference including version routes
- SDK — Programmatic version management
- Security & Access Control — Who can publish versions