Overview
Jinba Toolbox provides native Model Context Protocol (MCP) endpoints that expose your toolsets as MCP-compatible servers. This allows AI agents and LLM-based applications — such as Claude Desktop, Cursor, and custom agent frameworks — to discover and execute your tools through a standardized JSON-RPC interface. Each MCP-enabled toolset becomes an MCP server (Streamable HTTP transport). The endpoint accepts JSON-RPC requests conforming to the MCP specification, returns tool definitions and executes tools. It serves the toolset’s active published version — publish a version first.MCP Endpoints
Jinba Toolbox offers two types of MCP endpoints:Organization MCP
For internal use within your organization. Requires your organization’s API key (or a signed-in session). Falls back to the latest version if the environment has no active version.
Public MCP
For external consumers accessing public toolsets. Requires any valid API key; the credit cost is charged to the caller’s organization.
:orgId is the provider organization’s canonical ID.Enabling MCP for a ToolSet
MCP must be enabled on a per-toolset basis. You can toggle it in the web console or through the API:Connecting AI Agents
Claude Desktop
The console’s MCP Connection card (Tools tab of an MCP-enabled ToolSet) provides a ready-made Claude Desktop configuration that bridges the Streamable HTTP endpoint through thesupergateway stdio bridge. Add it to claude_desktop_config.json and replace $JINBA_API_KEY with your key:
/v1/public/{orgId}/slack-tools/mcp URL instead.
Cursor
In Cursor’s MCP settings, add a new server using the streamable HTTP transport:Jinba App
The Connect with JinbaApp button on the same card creates (or reuses) an API key for the chosen environment and opens Jinba App with the MCP server pre-configured.Custom Agent Integration
If you are building a custom agent, connect to the MCP endpoint using any MCP-compatible client library. The endpoint supports JSON-RPC over HTTP. Example using the MCP TypeScript SDK:How It Works
1
Agent discovers tools
The agent sends a
tools/list JSON-RPC request to the MCP endpoint. Jinba Toolbox responds with the list of tools in the toolset — the tool slug as name, its display name as title, its description, and its input and output schemas.2
Agent calls a tool
When the agent needs to use a tool, it sends a
tools/call request with the tool name and arguments. The arguments are validated against the tool’s input schema, and the caller organization’s credit balance is checked (one credit per call).3
Sandbox execution
Jinba Toolbox executes the tool code in an isolated sandbox environment (E2B or Daytona). The active published version of the tool is used, and a Run record is created.
4
Result returned
The tool’s output (or an error) is returned to the agent as JSON text content in the MCP response;
isError is set when the execution failed. Logs are available on the run’s detail page, not in the MCP response.Organization vs. Public Endpoints
Authentication
Both MCP endpoints require a Bearer token in theAuthorization header:
- Which organization the request is associated with (the caller organization recorded on the run)
- Which organization’s credits are consumed
- Which ToolSet environment (variables and active version) is used
Best Practices
- Enable MCP selectively — only activate MCP on toolsets that you intend to expose to AI agents.
- Use the public endpoint for external integrations and the organization endpoint for internal workflows.
- Monitor usage through the run history API to track which tools agents are calling and how frequently.
- Publish a version before exposing a toolset via MCP — the endpoint executes the published version, not the draft.
- Provide clear tool descriptions — AI agents rely on tool names and descriptions to decide which tool to invoke.
Related
- REST API — Full endpoint reference
- SDK — Programmatic access via the TypeScript SDK
- Versioning & Publishing — How published versions are resolved