Connect Riza to Claude: Automate Secure Custom Tool Execution

If you need to give your AI agents the ability to write and execute code in an isolated environment, you need a Model Context Protocol (MCP) server connected to a sandbox provider. This server translates Claude's tool calls into secure execution requests. You can build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL for Riza. 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.

Allowing a Large Language Model (LLM) to execute arbitrary code is inherently dangerous. Doing it securely requires moving the execution environment off your host machine and into isolated sandboxes. Riza provides this infrastructure, but connecting it directly to an LLM requires bridging complex state machine logic - building runtimes, managing revisions, mapping dependencies, and parsing multi-stream execution outputs (stdout, stderr, exit codes). Every time an execution fails, you must cleanly feed that failure back to the LLM so it can debug and retry.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Riza, connect it natively to Claude, and orchestrate secure remote code execution using natural language.

The Engineering Reality of the Riza API

A custom MCP server is a self-hosted integration layer that sits between your LLM and the target API. While the open MCP standard provides a predictable way for models to discover tools, implementing it against an execution environment like Riza comes with highly specific architectural constraints.

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

Complex Sandbox Lifecycle Sequencing Riza does not operate as a single "eval" endpoint. It is a state machine. To run custom tools with specific dependencies, you must orchestrate a precise sequence: create a runtime, define a manifest file containing package requirements, create a runtime revision, create a tool defining the input schema, and finally trigger the execution. If an LLM attempts to hit these REST endpoints raw, it will frequently attempt to execute tools before the container revision finishes building, or it will confuse a runtime_id with a revision_id. Truto's MCP tool definitions inject strict JSON schemas and descriptions that guide the LLM on exactly which foreign keys are required for each sequential step.

Multi-Stream Output Parsing When code executes, it does not just return a string. Riza returns a complex object containing the target output, but also standard streams like stdout, stderr, the numeric exit_code, and execution duration. If an LLM executes a script that raises a runtime exception, the actual error trace is often buried in stderr while the output remains null. A custom MCP server has to carefully format these concurrent streams into a single JSON response block so Claude can read the stack trace and self-correct its code.

Execution Quotas and Rate Limits Riza enforces concurrency limits and API rate limits. If your agent gets stuck in a loop trying to brute-force a failing script, it will quickly exhaust these limits and Riza will return an HTTP 429 Too Many Requests error. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Riza API returns a 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The Claude client is responsible for reading these headers and executing appropriate retry and backoff logic.

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

    Claude->>MCP: Call create_a_riza_tool_execution
    MCP->>Riza: POST /v1/tools/execute
    Riza-->>MCP: HTTP 429 Too Many Requests
    Note right of MCP: Standardizes IETF headers<br>(limit, remaining, reset)
    MCP-->>Claude: Error 429
    Note left of Claude: Claude reads headers<br>and initiates backoff

How to Generate a Riza MCP Server with Truto

Truto dynamically derives MCP tools directly from the integration's resource definitions and schema documentation. You do not write any custom tool logic. Each MCP server is cryptographically scoped to a single connected Riza account.

You can generate the MCP server in two ways: via the Truto UI, or programmatically via the API.

Method 1: Via the Truto UI

This is the fastest method for internal tooling and rapid prototyping.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Riza instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server settings. You can optionally apply method filters (e.g., restricting the server to read operations to prevent the LLM from executing new code) or tag filters.
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123def456...).

Method 2: Via the Truto API

If you are building an AI product and need to generate MCP servers for your customers dynamically, use the REST API. The API validates the configuration, stores the hashed token in Cloudflare KV for sub-millisecond validation, and returns the endpoint.

POST /integrated-account/:id/mcp

{
  "name": "Riza Code Execution Server",
  "config": {
    "methods": ["read", "write", "custom"]
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The response will contain the secure URL you pass to your MCP client.

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, you need to connect it to Claude. Because Truto handles the OAuth token lifecycle and Riza API authentication under the hood, the URL is entirely self-contained.

Method 1: Via the Claude UI (Desktop/Web)

Anthropic natively supports remote MCP servers.

1. Open Claude and navigate to Settings -> Integrations (or Connectors depending on your tier).
2. Click Add MCP Server.
3. Provide a name (e.g., "Riza Sandbox Engine").
4. Paste the Truto MCP server URL and click Add.

Claude will immediately call the /initialize and /tools/list endpoints. You can now prompt Claude to interact with Riza.

Method 2: Via Manual Configuration File

If you are configuring Claude Desktop manually or running a custom MCP client, you can add the server using the configuration file. Because Truto exposes a remote HTTP endpoint, you typically use an SSE (Server-Sent Events) proxy utility to bridge the local stdio client to the remote Truto server.

Edit your claude_desktop_config.json file:

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

Restart Claude Desktop. The client will establish a connection to Truto, and the Riza tools will populate in the interface.

Riza Hero Tools for Claude

When Claude calls tools/list, Truto dynamically generates the definitions. Here are the highest-leverage tools available for Riza orchestration.

create_a_riza_command

The most direct way to execute ad-hoc scripts in a secure sandbox. This tool takes source code and a target language, spinning up an ephemeral container to run the code. It returns the stdout, stderr, exit_code, and duration.

"Execute the following Python script to parse this CSV data using create_a_riza_command. If the exit code is non-zero, check the stderr output, fix the code, and run it again."

create_a_riza_runtime

Instead of running ephemeral scripts, this tool provisions a persistent runtime environment. You define the language and supply a manifest file (like a requirements.txt or package.json). Riza uses this to build an isolated container image with your specific dependencies.

"I need to test an integration with a specific third-party library. Use create_a_riza_runtime to provision a new Python environment containing the 'httpx' and 'pydantic' packages."

create_a_riza_runtime_revision

Once a runtime exists, you update its dependencies by creating new revisions. This tool allows Claude to iteratively add packages to a sandbox without destroying the parent runtime ID.

"The previous execution failed because of a missing dependency. Use create_a_riza_runtime_revision to add 'numpy' to the existing runtime ID, then wait for the status to report as ready."

create_a_riza_tool

This creates a reusable, strongly-typed function within your Riza project. You supply the source code, the language, and a JSON Schema defining the exact inputs the tool accepts.

"Create a new tool named 'fetch_user_metadata' in Riza. The input schema should require a 'user_id' string, and the code should execute a mock HTTP GET request returning a JSON object."

create_a_riza_tool_execution

Once a tool is defined, this endpoint triggers it. Claude passes a JSON payload matching the tool's defined input schema, and Riza executes the underlying code against that input. This is critical for parameterizing sandbox executions.

"Execute the 'fetch_user_metadata' tool you just created using create_a_riza_tool_execution. Pass in 'user_id: 9948' and return the resulting output to me."

list_all_riza_executions

An auditing tool that returns the history of executions in your Riza project. It includes timestamps, durations, and exit codes. You can instruct Claude to filter for specific states.

"Audit our sandbox environments using list_all_riza_executions. Filter the results to only show executions with non-zero exit codes from the last 24 hours, and summarize the most common stderr messages."

create_a_riza_secret

Injects secure configuration into the Riza project environment. This ensures that when Claude writes code that interacts with external APIs, the API keys are not hardcoded into the script source.

"Create a new Riza secret named 'STRIPE_TEST_KEY'. Once created, write a script that accesses this environment variable securely and test it via a riza command."

For the full list of available tools, including resource listing, deletion, and function execution, refer to the Truto Riza Integration Reference.

Workflows in Action

MCP tools transform Claude from a static reasoning engine into an active DevOps engineer. Here are specific workflows you can automate by connecting Claude to Riza.

Workflow 1: Iterative Vulnerability Patch Testing

Security engineers often need to test whether a specific version of a library is vulnerable to an exploit. Instead of configuring local environments, Claude can build sandboxes and test payloads dynamically.

"I need to test if the current manifest is vulnerable to SSRF. Create a Python runtime, install 'requests==2.28.1', create a tool that takes a URL input and fetches it, and then execute that tool against an internal mock IP address. If the request succeeds, rewrite the manifest to update 'requests' to the latest version and run the test again."

How the agent executes this:

1. Calls create_a_riza_runtime with a manifest specifying the vulnerable package version.
2. Calls create_a_riza_tool with the python script and an input schema accepting a target URL.
3. Calls create_a_riza_tool_execution passing the mock internal IP.
4. Analyzes the stdout and exit_code to determine if the exploit worked.
5. Calls create_a_riza_runtime_revision to bump the dependency version.
6. Calls create_a_riza_tool_execution again to verify the patch mitigated the exploit.

Workflow 2: Automated Data Pipeline Debugging

Data engineers frequently deal with parsing scripts that fail when unexpected data formats appear. Claude can use Riza to debug the transformation logic in isolation.

"Run this Python data transformation script on the provided sample dataset using a Riza command. If the script throws a KeyError, fetch the execution details, read the stderr trace to identify the missing column, modify the script to handle the missing key gracefully, and execute it again."

How the agent executes this:

1. Calls create_a_riza_command providing the initial transformation script.
2. Receives the execution payload. Notes that exit_code is 1.
3. Parses the stderr string returned by the tool, identifying the exact line and dictionary key that caused the failure.
4. Rewrites the Python script locally in its context to add a .get() fallback or try/except block.
5. Calls create_a_riza_command with the updated script to confirm the transformation now succeeds.

Security and Access Control

Exposing remote code execution capabilities to an LLM requires strict boundaries. Truto provides multiple layers of access control at the MCP server level:

• Method Filtering: You can restrict a specific MCP server to only allow read operations. This allows Claude to audit logs and view runtime configurations via list_all_riza_executions, but structurally prevents it from executing code via create_a_riza_command.
• Tag Filtering: Limit the MCP server to specific resource tags. If you only want Claude managing users or projects but not execution environments, you filter the tools exposed to the model.
• Require API Token Auth: By default, possessing the MCP server URL grants access to the tools. Setting require_api_token_auth: true forces the client to also pass a valid Truto API token in the Authorization header. This prevents unauthorized execution if an internal URL is leaked.
• Expiration Timers: You can set an expires_at datetime when creating the server. Truto schedules a durable cleanup alarm that completely destroys the server access when the timer hits, perfect for granting temporary sandbox access to contractors or isolated workflows.

The Autonomous Engineering Environment

Connecting Riza to Claude via a managed MCP server solves the hardest problem in AI orchestration: giving models a safe, isolated place to execute and test logic. Instead of building complex JSON-RPC parsing, handling multi-stream terminal outputs, and managing OAuth lifecycles, you simply provision a URL and let the model work.

By offloading the integration boilerplate to a unified infrastructure layer, your engineering team can focus on defining higher-level security boundaries and complex agent architectures, rather than debugging container state machines.

Current relatedPosts: ["what-is-mcp-and-mcp-servers-and-how-do-they-work","managed-mcp-for-claude-full-saas-api-access-without-security-headaches","handling-auth-tool-sharing-in-multi-agent-frameworks-via-mcp"]