Skip to main content
Glama
mozicim

Node Code Sandbox MCP

by mozicim

sandbox_stop

Terminate and remove a running Node.js sandbox container to clean up resources after completing code execution tasks.

Instructions

Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
container_idYes

Implementation Reference

  • The main handler function `stopSandbox` that executes the tool logic: checks if Docker is running, stops and removes the container using `docker rm -f`, updates the active containers set, and returns appropriate success or error messages.
    export default async function stopSandbox({
      container_id,
    }: {
      container_id: string;
    }): Promise<McpResponse> {
      if (!isDockerRunning()) {
        return {
          content: [textContent(DOCKER_NOT_RUNNING_ERROR)],
        };
      }
    
      try {
        // Directly use execSync for removing the container as expected by the test
        execSync(`docker rm -f ${container_id}`);
        activeSandboxContainers.delete(container_id);
        // console.log(
        //   `[stopSandbox] Removed container ${container_id} from registry.`
        // );
    
        return {
          content: [textContent(`Container ${container_id} removed.`)],
        };
      } catch (error) {
        // Handle any errors that occur during container removal
        const errorMessage = error instanceof Error ? error.message : String(error);
        console.error(
          `[stopSandbox] Error removing container ${container_id}: ${errorMessage}`
        );
    
        // Still remove from our registry even if Docker command failed
        activeSandboxContainers.delete(container_id);
    
        return {
          content: [
            textContent(
              `Error removing container ${container_id}: ${errorMessage}`
            ),
          ],
        };
      }
    }
  • Zod input schema defining the required `container_id` string argument.
    export const argSchema = { container_id: z.string() };
  • src/server.ts:75-80 (registration)
    MCP server tool registration for 'sandbox_stop', linking the name, description, input schema (`stopSchema`), and handler (`stopSandbox`).
    server.tool(
      'sandbox_stop',
      'Terminate and remove a running sandbox container. Should be called after finishing work in a sandbox initialized with sandbox_initialize.',
      stopSchema,
      stopSandbox
    );
  • src/server.ts:15-15 (registration)
    Import of the handler function and schema for sandbox_stop from the tools module.
    import stopSandbox, { argSchema as stopSchema } from './tools/stop.ts';
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool 'Terminate[s] and remove[s]' a container, which implies destructive behavior and cleanup. However, it doesn't mention potential side effects (e.g., data loss), permissions required, or error conditions, leaving gaps for a mutation tool.

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?

The description is two sentences with zero waste: the first states the purpose, and the second provides usage guidelines. It's front-loaded with the core action and appropriately sized for the tool's complexity.

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?

Given a destructive tool with no annotations and no output schema, the description is mostly complete: it covers purpose, usage, and behavioral intent. However, it lacks details on return values or error handling, which would be helpful for full context.

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?

With 0% schema description coverage and 1 parameter, the description adds no explicit parameter information. However, the context implies 'container_id' refers to a sandbox from sandbox_initialize. Since there's only one required parameter, the baseline is 4, as minimal parameter guidance is needed.

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?

The description clearly states the specific action ('Terminate and remove') and target resource ('a running sandbox container'), distinguishing it from sibling tools like sandbox_initialize (which creates) and sandbox_exec (which runs commands). It uses precise verbs that convey both stopping and cleanup.

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?

The description provides explicit usage guidance: 'Should be called after finishing work in a sandbox initialized with sandbox_initialize.' This clearly defines when to use this tool versus alternatives (e.g., not for ongoing execution) and references the prerequisite sibling tool.

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/mozicim/node-code-sandbox-mcp'

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