Connect Riza to Claude: Deploy Runtimes and Execute Secure Scripts

If you need to connect Riza to Claude to execute sandboxed code, deploy custom runtimes, and orchestrate secure tools, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function calls and Riza's REST API. You can either build and host this middleware yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Riza to ChatGPT or explore our broader architectural overview on connecting Riza to AI Agents.

Giving a Large Language Model (LLM) the ability to execute arbitrary code is incredibly powerful, but it introduces significant security and infrastructure challenges. Riza solves the isolation problem by providing secure, WebAssembly-based sandboxes. However, connecting those sandboxes to Claude requires handling complex API payloads, managing execution states, and mapping dynamic input schemas. Every time you want to expose a new Riza tool to your agent, you have to write boilerplate integration code.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Riza, connect it natively to Claude Desktop, and execute complex code orchestration workflows using natural language.

The Engineering Reality of the Riza API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against a code execution platform like Riza is highly specialized. You are not just pushing standard CRUD objects - you are managing execution states, handling multiline source code strings, and provisioning custom runtime environments.

If you decide to build a custom MCP server for Riza, you own the entire API lifecycle. Here are the specific challenges you will face:

Handling Strict Execution Payloads Riza offers different endpoints depending on the execution model. Ad-hoc scripts run via the code execution endpoints and return raw stdout and stderr. Function executions require the LLM to output a strictly formatted execute function that returns a JSON-serializable value. If you expose these raw REST requirements directly to an LLM without proper schema validation, the model will frequently write code that executes but fails to return data in the format your application expects. You have to write logic to intercept, validate, and normalize these execution payloads.

Managing Runtime Manifests When you create a custom runtime in Riza, you have to submit specific manifest files and dependency arrays (like additional_python_imports). Managing the state of these runtimes - checking if they are built, handling revision IDs, and passing the correct runtime_revision_id to subsequent tool creations - requires complex state management within your MCP server.

Rate Limits and Concurrent Executions Riza imposes limits on API requests and concurrent code executions. If your AI agent spins up dozens of parallel scripts, Riza will return an HTTP 429 Too Many Requests error. Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API like Riza returns a 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your AI agent or client application) is entirely responsible for reading these headers and implementing its own retry and backoff logic.

Instead of building this infrastructure from scratch, you can use Truto. Truto normalizes Riza's endpoints into dynamic MCP tools, allowing Claude to execute code securely without you writing a single line of integration glue.

How to Generate a Riza MCP Server with Truto

Truto dynamically generates MCP tools based on the actual endpoints and documentation of the Riza API. The resulting MCP server is scoped to a single integrated account and secured via a cryptographic token in the URL. You can create this server via the Truto UI or programmatically via the API.

Method 1: Generating the Server via the Truto UI

For administrators setting up a local Claude Desktop instance or testing workflows, the UI is the fastest path.

1. Log into your Truto dashboard.
2. Navigate to the Integrated Accounts page and select your connected Riza account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., restrict to read-only methods or specific tags).
6. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/abc123def456...).

Method 2: Generating the Server via the API

For platform engineers building multi-tenant AI products, you can generate MCP servers programmatically. This is useful when you want to provision an MCP server for a specific tenant on demand.

Make a POST request to /integrated-account/:id/mcp with your desired configuration:

curl -X POST https://api.truto.one/integrated-account/<riza_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Riza Code Executor",
    "config": {
      "methods": ["create", "get", "list"],
      "require_api_token_auth": false
    }
  }'

The Truto API validates the integration, generates a secure token, and returns a ready-to-use URL:

{
  "id": "mcp_898ad9a",
  "name": "Riza Code Executor",
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

How to Connect the MCP Server to Claude

Once you have your Truto MCP server URL, you must connect it to your AI client. The process differs depending on whether you are using a managed UI or configuring a local desktop environment.

Method 1: Via the Claude UI

If you are using Anthropic's managed interfaces that support custom connectors, you can add the URL directly.

1. Open Claude and navigate to Settings.
2. Go to Integrations or Connectors.
3. Click Add MCP Server.
4. Paste the Truto MCP URL.
5. Click Add.

Claude will immediately ping the /mcp/:token endpoint, initialize the JSON-RPC 2.0 handshake, and ingest the available Riza tools.

Method 2: Via Manual Configuration File (Claude Desktop)

If you are using the local Claude Desktop application, you must edit the client configuration file to establish a Server-Sent Events (SSE) connection.

1. Open your claude_desktop_config.json file. On macOS, this is typically located at ~/Library/Application Support/Claude/claude_desktop_config.json.
2. Add the Truto MCP server using the @modelcontextprotocol/server-sse transport.

{
  "mcpServers": {
    "riza_sandbox": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}

Restart Claude Desktop. The application will use npx to spawn a local process that connects to Truto's remote SSE endpoint, making the Riza API available for tool calling.

Riza MCP Hero Tools

When Claude connects to the Truto MCP server, it gains access to a dynamically generated toolset. Because Truto handles the schema parsing automatically, Claude knows exactly what arguments to pass and what data types to expect. Here are the highest-leverage tools for Riza automation.

create_a_riza_code_execution

This tool allows the LLM to execute an ad-hoc script in an isolated sandbox. It is ideal for quick data transformations, calculations, or logic tests where you just need to read the standard output.

Usage note: The LLM must supply the language (e.g., python, javascript) and the literal code string. The response includes the exit_code, stdout, stderr, and duration in milliseconds.

"Write a Python script to calculate the first 50 numbers of the Fibonacci sequence and execute it using the create_a_riza_code_execution tool. Tell me how many milliseconds it took to run."

create_a_riza_tool

Unlike ad-hoc code executions, this tool creates a reusable, named function in your Riza project. You define the name, the language, the source code, and a strict JSON input schema. This turns a raw script into a structured API endpoint.

Usage note: The LLM must define the input_schema using JSON Schema format. This ensures that when the tool is called later, Riza validates the input arguments before execution.

"Use the create_a_riza_tool command to register a new Python tool named 'extract_urls'. It should accept a string called 'text' in its input schema, use a regular expression to find all HTTP/HTTPS URLs, and return them as a JSON array."

create_a_riza_tool_execution

Once a tool is registered via the previous step, this operation executes it by passing a structured payload matching the tool's defined input schema.

Usage note: This is powerful because it allows the LLM to build its own persistent utility library within Riza and call those utilities dynamically by their tool_id.

"Execute the 'extract_urls' tool you created earlier using create_a_riza_tool_execution. Pass in this block of text: 'Check out https://example.com and http://test.org for more info.' Let me know what JSON array it returns."

create_a_riza_runtime

Standard sandboxes have default dependencies. If your code requires specific libraries (like pandas or requests in Python), you must provision a custom runtime. This tool creates the environment configuration.

Usage note: The model must supply a name, language, and a manifest_file (which defines the environment). Building runtimes takes time, so the status will initially be pending.

"I need to run some data analysis. Use create_a_riza_runtime to provision a new Python environment named 'data_science_env'. Include 'pandas' and 'numpy' in the requirements manifest."

create_a_riza_secret

If the sandboxed code needs to call out to external third-party APIs (e.g., fetching data from Stripe before processing it), you should never hardcode credentials. This tool securely stores secrets as environment variables within the Riza project.

Usage note: The value is encrypted at rest by Riza. The code executing in the sandbox can then read these variables via standard environment lookups (e.g., os.environ.get('API_KEY')).

"Store a new secret in Riza using create_a_riza_secret. Name it 'STRIPE_API_KEY' and use the value 'sk_test_12345'. We will use this in the next billing script we deploy."

list_all_riza_executions

This tool retrieves the audit log of all executions in your Riza project. It is essential for monitoring failures, tracking execution durations, and auditing what code the AI agent has run in the past.

Usage note: Truto automatically injects pagination arguments (limit and next_cursor). You can also ask the LLM to filter specifically for failed runs using the only_non_zero_exit_codes flag.

"Use list_all_riza_executions to pull the last 20 code runs. Filter for only non-zero exit codes so we can debug any scripts that crashed over the weekend."

For the complete list of available operations, including fetching specific revisions and deleting runtimes, view the Riza Integration Page.

Workflows in Action

By chaining these dynamically generated MCP tools together, Claude can execute complex, multi-step engineering tasks entirely autonomously.

Workflow 1: Ad-Hoc Data Analysis

An operations manager has a messy CSV string of customer transactions and needs to calculate the total revenue grouped by region. Instead of writing a script locally, they ask Claude to handle it.

"Here is a raw CSV string of transaction data. Use the create_a_riza_code_execution tool to write a Python script that parses this CSV, groups the transactions by the 'Region' column, and sums the 'Amount' column. Return the final aggregations to me."

1. Code Generation: Claude analyzes the prompt and writes a Python script utilizing the built-in csv module to parse the string and aggregate the data.
2. Tool Execution: Claude calls create_a_riza_code_execution with language: "python" and the generated script in the code field.
3. Result Processing: The Truto MCP server translates this into a Riza REST request. Riza spins up an isolated sandbox, runs the script, and returns the stdout. Claude reads the stdout and presents the final regional revenue numbers to the user.

Workflow 2: Building a Persistent Integration Utility

A developer wants to create a reusable utility for scrubbing Personally Identifiable Information (PII) from text logs before storing them. They want this utility permanently available in Riza.

"I need a permanent PII scrubbing utility. First, use create_a_riza_tool to build a JavaScript tool named 'pii_scrubber' that takes a 'raw_log' string, redacts any email addresses, and returns 'clean_log'. Then, test it using create_a_riza_tool_execution with the string 'User dev@example.com logged in'."

1. Tool Registration: Claude calls create_a_riza_tool. It defines the input schema (requiring raw_log) and writes the JavaScript regex logic to scrub emails.
2. ID Retrieval: Truto returns the Riza response, which includes the newly generated id for the tool.
3. Tool Execution: Claude immediately calls create_a_riza_tool_execution, passing the id from step 2 and the test string as the input payload.
4. Validation: Riza executes the registered tool. Claude receives the JSON response ({"clean_log": "User [REDACTED] logged in"}) and confirms the utility works.

sequenceDiagram
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant Riza as Riza API

    Claude->>Truto: Call create_a_riza_tool<br>(name: pii_scrubber, code: ...)
    Truto->>Riza: POST /v1/tools
    Riza-->>Truto: Return Tool ID (tl_987xyz)
    Truto-->>Claude: Return Tool ID

    Claude->>Truto: Call create_a_riza_tool_execution<br>(tool_id: tl_987xyz, payload: ...)
    Truto->>Riza: POST /v1/tools/tl_987xyz/execute
    Riza-->>Truto: Return JSON Result
    Truto-->>Claude: Return Result

Workflow 3: Orchestrating Custom Runtimes

A DevOps engineer needs to run a specialized script that requires the requests library to fetch data from an internal health check endpoint.

"Use create_a_riza_runtime to build a Python environment named 'health_checker' that includes the 'requests' library. Once you initiate it, check its status using list_all_riza_runtimes to confirm it built correctly."

1. Runtime Provisioning: Claude calls create_a_riza_runtime, submitting the required manifest JSON structure to include requests via additional_python_imports.
2. Status Polling: Truto returns the initial response (status: pending).
3. Verification: Claude then calls list_all_riza_runtimes (or get_single_riza_runtime_by_id) to audit the environment status, waiting for it to transition to available before running any scripts against it.

Security and Access Control

Giving an LLM the ability to execute code requires strict governance. If you are generating a Truto MCP server for a team or integrating it into a production agent architecture, you must control what the LLM is allowed to do. Truto enforces this through token configuration:

• Method Filtering: Restrict the server to specific operation types using config.methods. For example, setting methods: ["read"] allows the LLM to audit past executions (list_all_riza_executions), but blocks it from running new code (create_a_riza_code_execution).
• Tag Filtering: Group tools by functional area using config.tags. You can restrict an MCP server to only expose tools related to runtime management while hiding secret management tools.
• API Token Authentication: By default, possessing the MCP URL is enough to connect. For high-security environments, enable require_api_token_auth: true. This forces the client to pass a valid Truto API token in the Authorization header during the initial MCP handshake.
• Automatic Expiration: If you are giving a contractor or temporary AI agent access to Riza, set an expires_at datetime. The MCP token will automatically self-destruct at the specified time, cutting off all API access instantly.

Architecting for Safe AI Execution

The combination of Claude's reasoning capabilities and Riza's secure sandboxes represents a massive leap forward for autonomous engineering agents. However, building the connective tissue to normalize schemas, handle rate limits, and orchestrate JSON-RPC protocols takes weeks of engineering time away from your core product.

By leveraging Truto's dynamic MCP server generation, you bypass the boilerplate entirely. You get a secure, filtered, and documented interface to Riza that Claude can natively understand, allowing your team to focus on building the actual AI workflows instead of maintaining integration middleware.