Skip to main content
Glama

ProDisco Run Sandbox

prodisco_runSandbox

Execute and test TypeScript code in a sandboxed environment to manage Kubernetes clusters. Cache scripts for reuse, stream output, and validate with integrated tests.

Instructions

PREREQUISITE: Call searchTools first to discover correct API methods and parameters. Do NOT guess - search to find available APIs before writing code.

Execute TypeScript code in a sandboxed environment.

IMPORTANT: When executing new code, ALWAYS provide a scriptName to cache the script for future reuse. Use descriptive kebab-case names (e.g., "list-pods", "get-etcd-details", "check-node-resources"). Scripts are only cached when scriptName is provided.

BEST PRACTICE: When writing complex logic, data transformations, or code you are uncertain about, use mode: "test" first to validate your implementation with unit tests before running in production. This helps catch bugs early and ensures correctness.

MODES: • execute (default): Blocking execution, waits for completion. Params: code OR cached (required), scriptName (required for caching), timeout. • stream: Real-time output streaming. Params: code OR cached (required), scriptName (required for caching), timeout. • async: Start execution and return immediately with execution ID. Params: code OR cached (required), scriptName (required for caching), timeout. • status: Get status of async execution. Params: executionId (required), wait (optional). • cancel: Cancel a running execution. Params: executionId (required). • list: List active/recent executions. Params: states (optional), limit (optional). • test: Run unit tests with structured results. Params: tests (required), code (optional implementation to test), timeout. CRITICAL: test() and assert are pre-injected globals - do NOT import them, do NOT call test.run(). Just write: test("name", () => { assert.is(actual, expected); }); Available assertions: assert.is(a,b), assert.ok(val), assert.equal(obj1,obj2), assert.not(val), assert.throws(fn).

Sandbox provides console + process.env and restricts require() to an allowlist. ALLOWED IMPORTS:

  • require("@kubernetes/client-node") - Kubernetes API client

  • require("@prodisco/prometheus-client") - Prometheus queries & metric discovery

  • require("@prodisco/loki-client") - Loki LogQL querying

  • require("simple-statistics") - Statistics helpers

  • require("uvu") - Lightweight test runner for sandbox testing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution mode: "execute" (default) - blocking execution, waits for completion; "stream" - real-time output streaming; "async" - start execution and return immediately with execution ID; "status" - get status and output of an async execution; "cancel" - cancel a running execution; "list" - list active and recent executions; "test" - run tests using uvu framework with structured resultsexecute
codeNo(execute/stream/async mode) TypeScript code to execute
cachedNo(execute/stream/async mode) Name of a cached script to execute (from searchTools results)
scriptNameNo(execute/stream/async mode) **REQUIRED for caching**. Name for the script (e.g., "list-pods", "get-etcd-details"). Use descriptive kebab-case names. Scripts without scriptName are NOT cached.
timeoutNo(execute/stream/async mode) Execution timeout in milliseconds (default: 30000, max: 120000)
executionIdNo(status/cancel mode) Execution ID from async mode response
waitNo(status mode) If true, wait for completion (long-poll)
outputOffsetNo(status mode) Offset in output buffer for incremental reads
statesNo(list mode) Filter by execution states
limitNo(list mode) Maximum number of results
includeCompletedWithinMsNo(list mode) Include completed executions from last N milliseconds
testsNo(test mode) Test code using pre-injected test() and assert. IMPORTANT: Do NOT import test/assert, do NOT call test.run() - they are already provided. Example: test("adds numbers", () => { assert.is(add(1,2), 3); }); Available: assert.is(a,b), assert.ok(val), assert.equal(obj1,obj2), assert.not(val), assert.throws(fn)
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses sandbox restrictions, allowed imports, pre-injected globals, caching behavior, and details of each mode (blocking, streaming, async, etc.). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections (PREREQUISITE, IMPORTANT, BEST PRACTICE, MODES, ALLOWED IMPORTS). Front-loaded with critical info. Some repetition of test details from schema, but overall each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive coverage of prerequisites, usage, parameters, and restrictions for a complex tool. Lacks output examples, but no output schema is provided. Completeness is high given the constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by reinforcing caching requirement for scriptName, providing naming conventions, and detailing test globals (test, assert) beyond schema. This extra guidance elevates it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it executes TypeScript code in a sandboxed environment, specifies multiple modes, and explicitly mentions prerequisite call to searchTools, distinguishing it from the sibling tool. Verb and resource are clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call searchTools first, provides best practices for caching and testing, and describes when to use each mode. No ambiguity about when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/harche/ProDisco'

If you have feedback or need assistance with the MCP directory API, please join our Discord server