Skip to main content
Jinba Toolbox executes every tool in an isolated sandbox container. You can test tools interactively from the editor or review the full execution history of your organization.

​
Testing from the Tool Editor

The Tool Editor includes a built-in Test Panel for running your tool against a live sandbox.
1

Enter Test Input

In the Test Panel (bottom section of the editor), type or paste a JSON object that matches the tool’s input schema. For example:
{
  "name": "Alice",
  "greeting": "Hi"
}
2

Run the Tool

Click the Run button or press Cmd/Ctrl + Enter. The tool will execute in a sandbox with the ToolSet’s configured language, packages, and environment variables.
3

View Results

The Test Panel automatically switches to the Output tab, showing:
  • Output — The JSON object returned by the run function on success.
  • Error — The error name and message if the tool failed.
  • Logs — stdout and stderr output captured during execution.
Testing from the editor uses the current draft code, not the published version. This lets you iterate quickly before publishing.

​
Test Execution Flow

When you click Run, the following happens behind the scenes:
  1. The console sends the draft code and input JSON to the API’s /test endpoint.
  2. The API spins up a sandbox instance using the ToolSet’s configured provider (E2B or Daytona).
  3. Packages defined in the ToolSet are installed in the sandbox.
  4. Environment variables are injected into the sandbox process.
  5. The code is executed with the provided input.
  6. The sandbox captures the return value, stdout, stderr, and any errors.
  7. Results are sent back to the console and displayed in the Test Panel.

​
Run History

Every tool execution — whether triggered from the editor, the REST API, or an MCP call — produces a Run record. The Run History page provides a centralized view of all executions within your organization.

​
Browsing Runs

Navigate to Runs in the organization sidebar to see the execution history. The runs list displays:
ColumnDescription
ToolThe slug of the tool that was executed
StatusCurrent state: success, failed, running, or pending
DurationExecution time in milliseconds
DateWhen the run was created
Runs are sorted by creation date with the most recent first.

​
Status Indicators

Each run has a status that reflects where it is in the execution lifecycle:

Pending

The run has been created but the sandbox has not started execution yet.

Running

The tool is currently executing inside the sandbox.

Success

The tool completed successfully and returned an output.

Failed

The tool encountered an error during execution.

​
Run Detail Page

Click any run in the list to open its detail page. The detail view shows: Summary Card A four-column summary at the top showing Duration, Created, Started, and Completed timestamps. Tabbed Data View
  • Input — The JSON input that was sent to the tool.
  • Output / Error — On success, the JSON output returned by the tool. On failure, the error name and message.
  • Logs — Captured stdout and stderr from the sandbox process. This tab only appears when logs are present.

​
Caller vs. Provider View

Runs have two perspectives:
  • Caller view — When your organization executed a tool (whether your own or another organization’s public tool), you see full details: input, output, error, and logs.
  • Provider view — When another organization executed one of your public tools, you can see the run’s status and metadata but not the input, output, or logs. This protects the caller’s data privacy.
The provider view displays a message indicating that execution details are only available to the calling organization, along with the caller’s organization name.

​
Execution via API

Beyond the console, tools can be executed programmatically:

REST API

POST /v1/orgs/:orgId/toolsets/:slug/tools/:toolSlug/run — Execute a published tool version via the API. Requires an API key with execute scope.

MCP Endpoint

POST /v1/orgs/:orgId/toolsets/:slug/mcp — Call tools through the Model Context Protocol. AI agents can discover and invoke tools via the standard MCP JSON-RPC interface.

Public Execution

POST /v1/public/:orgSlug/:toolsetSlug/run/:toolSlug — Execute a public tool using any organization’s API key.

SDK

Use the @jinba-toolbox/sdk to execute tools from your TypeScript application with a simple function call.
All execution methods produce Run records visible in the console’s Run History.

​
Execution Lifecycle

The complete lifecycle of a tool run:
1

Pending

The API receives the execution request and creates a Run record with status pending.
2

Sandbox Creation

A sandbox instance is created using the configured provider (E2B or Daytona) with the ToolSet’s language, packages, and environment variables.
3

Running

The tool’s code is executed inside the sandbox with the validated input. The status changes to running.
4

Completion

The sandbox returns the output (or error) along with captured stdout/stderr logs. The status changes to success or failed, and the duration is recorded.

​
Best Practices

  • Test with varied inputs — Cover edge cases (empty strings, large numbers, missing optional fields) in the Test Panel before publishing.
  • Check logs for debugging — When a tool fails, the stderr logs often contain stack traces and error details that pinpoint the issue.
  • Monitor run history — Regularly review the Runs page to spot patterns in failures or unexpected durations.
  • Use the Copilot after failures — After a failed test run, the AI Copilot has access to the error output and can suggest fixes.