tenki-mcp

tenki_exec

Run a command in an existing sandbox session and retrieve stdout, stderr, and exit code inline. Large output is returned as a head and tail preview, with full output saved to files in the sandbox.

Instructions

Run a command in an existing sandbox and return stdout, stderr, and exit code inline. Streams over max_output_bytes (default 64KB) come back as a head+tail preview with the full output retained at stdoutPath/stderrPath in the sandbox.

Input Schema

TableJSON Schema

Name	Required	Description
`cwd`	No	Working directory (honored in-script).
`env`	No	Environment variables as a key→value object.
`args`	No	Arguments.
`command`	Yes	Executable, e.g. 'npm' or 'python3'.
`session_id`	Yes	Sandbox session id (UUID), from tenki_create_sandbox or tenki_list_sandboxes.
`timeout_seconds`	No
`max_output_bytes`	No	Per-stream inline output cap in bytes (default 65536). Larger output is truncated head+tail and kept in the sandbox at stdoutPath/stderrPath.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	True only when exitCode is 0 AND stdout/stderr capture succeeded.
`args`	Yes	Arguments the executable was invoked with.
`stderr`	Yes	Captured standard error (empty when capture failed — see captureError).
`stdout`	Yes	Captured standard output (empty when capture failed — see captureError).
`command`	Yes	The executable that was run.
`exitCode`	Yes	Process exit code; 0 means success. (The API omits zero values; the server normalizes an absent code to 0.)
`stderrPath`	No	Sandbox path holding the FULL stderr, present only when truncated — page through it with tenki_exec (e.g. sed -n / tail -c).
`stdoutPath`	No	Sandbox path holding the FULL stdout, present only when truncated — page through it with tenki_exec (e.g. sed -n / tail -c).
`captureError`	No	Present when the command ran but its output could not be read back; stdout/stderr are unknown, not empty.
`stderrTruncated`	No	Present (true) when stderr exceeded the output cap and carries only a head+tail preview.
`stdoutTruncated`	No	Present (true) when stdout exceeded the output cap and carries only a head+tail preview.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

The description adds strong behavioral context beyond the annotations by explaining output truncation, the head+tail preview, and where full output is retained at stdoutPath/stderrPath. It does not contradict the annotations, though it could have more explicitly noted the side-effect potential of running arbitrary commands.

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

Conciseness5/5

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

Two front-loaded sentences deliver the core purpose and the most important edge-case behavior without wasted words. The structure is efficient and every clause contributes useful information.

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?

For a 7-parameter tool with an output schema and annotations, the description covers the essential return behavior and output-size handling. It does not explicitly describe timeout behavior or distinguish itself from tenki_run_code, but these are minor gaps given existing schema and annotation coverage.

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

Parameters3/5

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

Schema description coverage is high (86%), so the baseline is 3. The description's max_output_bytes explanation largely repeats what the schema already provides, and it adds little new semantic meaning for params like timeout_seconds, cwd, or env.

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

Purpose4/5

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

The description clearly states the tool's action and resource: 'Run a command in an existing sandbox' and explicitly lists the return values: stdout, stderr, and exit code. It is clear and specific, though it does not explicitly differentiate itself from tenki_run_code or other command/code execution siblings.

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

Usage Guidelines3/5

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

The phrase 'existing sandbox' implies a prerequisite and suggests use after sandbox creation, but the description gives no explicit when-to-use/when-not-to-use guidance or alternative tool names. The usage context is implied rather than clearly stated.

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

Deploy Server