ToolSet Management

Create ToolSets, configure sandbox environments, manage packages, and control visibility in the Jinba Toolbox console

A ToolSet is a collection of related tools bundled with a shared execution environment. Think of it as an npm package or Docker image — it groups tools together, defines their runtime dependencies, and supports semver-based versioning.

Creating a ToolSet

1. Navigate to ToolSets

   Inside your organization, click ToolSets in the sidebar. This is the default page when entering an organization.

2. Click New ToolSet

   Click the New ToolSet button. A creation form will appear with the following fields.

3. Fill in the Details

   Field	Description
   Slug	URL-safe identifier (e.g. slack-tools). Cannot be changed after creation.
   Name	Human-readable display name (e.g. “Slack Tools”).
   Description	A short summary of what this ToolSet does.
   Language	TypeScript or Python. Determines the code template and runtime. Cannot be changed after creation.
   Provider	Sandbox provider: E2B or Daytona. Cannot be changed after creation.
   Visibility	Public or Private. Can be changed later.
   MCP Server	Enable to expose this ToolSet as an MCP endpoint. Can be toggled later.

4. Create

   Click Create. You will be redirected to the ToolSet detail page where you can start adding tools.

ToolSet Detail Page

The detail page is the central hub for managing a ToolSet. It is organized into four tabs:

Tools

Lists all draft tools in the ToolSet. Add new tools, click a tool to open the code editor, and see at a glance whether there are unpublished changes.

Versions

View published version history, publish new versions, and switch the active (deployed) version.

Packages

Manage sandbox dependencies. Add or remove npm packages (TypeScript) or pip packages (Python) that your tools need at runtime.

Environments

Manage environment variables available to tools during execution. Values are stored encrypted and can be revealed on demand.

Sandbox Configuration

Every ToolSet defines a sandbox environment that its tools execute in. The sandbox configuration is set at creation time:

• Language — TypeScript or Python. This controls which runtime is used and what code templates are generated for new tools.
• Provider — E2B or Daytona. The sandbox provider handles container creation, code execution, and lifecycle management.

Managing Packages

Navigate to the Packages tab to manage runtime dependencies.

1. Add a Package

   Click Add Package and enter the package name (e.g. axios for TypeScript, requests for Python). You can optionally specify a version constraint.

2. Remove a Package

   Click the delete icon next to any listed package to remove it from the sandbox configuration.

Package changes are reflected in the draft state. You must publish a new version for the updated packages to take effect in production API calls.

Managing Environment Variables

Navigate to the Environments tab to manage secrets and configuration values.

1. Add a Variable

   Click Add Variable. Enter a key (e.g. SLACK_TOKEN), a value, and optionally mark it as a secret. Secret values are masked in the UI.

2. Edit or Delete

   Click the edit icon to update a variable’s value, or the delete icon to remove it.

3. Reveal Secrets

   Use the reveal toggle to temporarily show masked secret values. Revelation is per-variable and requires appropriate permissions.

Environment variables are injected into the sandbox at execution time and are available via process.env (TypeScript) or os.environ (Python).

Versioning and Publishing

ToolSets use semantic versioning (e.g. 1.0.0, 1.1.0, 2.0.0). Each version is an immutable snapshot of all tools and their code at the time of publishing.

1. Make Changes

   Edit tools, add new tools, or update packages in the draft state.

2. Publish a Version

   Click New Version on the Versions tab. Enter a version number (the console suggests the next patch version) and optional release notes. Click Publish.

3. Set the Active Version

   The most recently published version automatically becomes the active version used by API and MCP calls. You can switch the active version by hovering over any version in the list and clicking Set as Active.

Published versions are immutable. To make changes, edit the draft tools and publish a new version.

Visibility Settings

ToolSet visibility controls who can discover and execute your tools:

Visibility	Discovery	Execution
Private	Only organization members	Only organization members (via session or API key)
Public	Anyone on the Explore page	Any organization with a valid API key
Restricted	Not listed publicly	Only explicitly allowed organizations

To change visibility, use the visibility toggle in the ToolSet header. Changing to Public requires confirmation because it makes tool schemas visible on the Explore page (source code is never shared).

MCP Server

When MCP Server is enabled for a ToolSet, the console provides an MCP connection endpoint URL that you can copy. AI agents and LLM clients that support the Model Context Protocol can connect directly to this endpoint to discover and call the tools in the ToolSet.

Toggle MCP on or off from the ToolSet header at any time.

Import and Export

The ToolSet detail page supports zip-based import and export:

• Export — Downloads a .zip archive containing all tool definitions, code, and metadata. Useful for backup or migration.
• Import — Upload a .zip archive to bulk-import tools into the ToolSet. Existing tools with matching slugs will be updated.

Editing ToolSet Settings

Click the settings/edit link in the ToolSet header to navigate to the edit page where you can:

• Change the Name and Description.
• Change the Visibility setting.
• Toggle MCP Server on or off.

The Language, Provider, and Slug are read-only after creation.

Deleting a ToolSet

Click Delete in the ToolSet header. A confirmation dialog will appear warning that all tools, versions, and associated run records will be permanently removed. This action cannot be undone.