Skip to main content
Glama

Servidor MCP aislador

isolator-mcp es un servidor de Protocolo de Contexto de Modelo (MCP) escrito en TypeScript. Actúa como un contenedor de la herramienta CLI de Go integrada, isolator , y proporciona un entorno de ejecución de código seguro accesible a través de MCP.

Las aplicaciones LLM (hosts MCP) pueden conectarse a este servidor y usar su herramienta execute_code para ejecutar de forma segura fragmentos de código Python, Go o JavaScript proporcionados directamente o cargados desde archivos de fragmentos predefinidos.

Características

  • Proporciona la herramienta MCP execute_code .

  • Admite la ejecución de código proporcionado directamente ( language , entrypoint_code ) o mediante fragmentos con nombre ( snippet_name ).

  • Admite varios idiomas (Python, Go, JavaScript, configurable).

  • Utiliza el isolator integrado Go CLI ( isolator-cli/ ) para la ejecución segura del contenedor Docker.

  • Valores predeterminados de seguridad configurables (tiempo de espera, límites de recursos, red) a través de isolator_config.json .

  • Administra directorios temporales en el host para la ejecución de código.

  • Maneja la copia de archivos en contenedores (mediante instrucciones a la CLI isolator ).

  • Devuelve resultados estructurados (stdout, stderr, status) a través de MCP, estableciendo isError: true en caso de fallas a nivel de herramienta.

Related MCP server: SQL MCP Server

Prerrequisitos

  • Docker: Necesario para la creación y ejecución de contenedores por parte de isolator-cli . Asegúrese de que el demonio de Docker esté en ejecución.

  • Go: necesario para crear el binario Go isolator-cli integrado.

  • Node.js y npm: necesarios para instalar dependencias, compilar y ejecutar el servidor TypeScript isolator-mcp .

Instalación

  1. isolator de compilación Go CLI: navegue hasta el directorio Go CLI integrado y compile el binario:

    cd isolator-cli
    go build -o isolator main.go
    cd .. 

    Esto crea el ejecutable ./isolator-cli/isolator que necesita el servidor.

  2. Configurar isolator-mcp :

    • Editar isolator_config.json : Actualizar isolatorPath para que apunte a la ruta absoluta del binario compilado (p. ej., /Users/ompragash/Documents/Cline/MCP/isolator-mcp/isolator-cli/isolator ). Ajustar los límites predeterminados, el directorio de trabajo del contenedor, las imágenes de idioma o la ubicación de promptsDir (usado para fragmentos) si es necesario.

    • Asegúrese de que el directorio de prompts exista (predeterminado: ./prompts ). Agregue fragmentos de código (p. ej., hello_world.py ). El nombre de archivo base (p. ej., hello_world ) se utiliza como snippet_name .

  3. Instalar dependencias del servidor: navegue al directorio principal ( isolator-mcp ) y ejecute:

    npm install
  4. Servidor de compilación: compila el código TypeScript:

    npm run build

    Esto crea el script ejecutable en build/index.js .

  5. Configurar el host MCP: agregue el servidor al archivo de configuración de su cliente MCP (por ejemplo, cline_mcp_settings.json para la extensión VS Code):

    {
      "mcpServers": {
        "isolator": {
          "command": "node",
          "args": ["/Users/ompragash/Documents/Cline/MCP/isolator-mcp/build/index.js"],
          "env": {},
          "disabled": false,
          "autoApprove": []
        }
      }
    }

    (Ajuste la ruta en args si es necesario) . El host MCP debería detectar e iniciar el servidor automáticamente.

Nota importante: Asegúrese de que las imágenes de Docker especificadas en isolator_config.json (p. ej., python:3.11-alpine , golang:1.21-alpine ) se hayan descargado previamente en su sistema mediante docker pull <image_name> . La herramienta isolator no descarga automáticamente las imágenes faltantes.

Desarrollo local / Pruebas

Para ejecutar el servidor localmente para desarrollo o pruebas (sin instalarlo a través de la configuración del host de MCP):

  1. Crear Go CLI: asegúrese de que el isolator Go CLI esté creado dentro de su subdirectorio:

    cd isolator-cli 
    go build -o isolator main.go
    cd ..
  2. Construir servidor TS: en este directorio principal ( isolator-mcp ), ejecute npm install y npm run build .

  3. Configurar: asegúrese de que isolator_config.json apunte correctamente al binario ./isolator-cli/isolator compilado a través de la clave isolatorPath (use la ruta absoluta).

  4. Ejecutar servidor: ejecute el servidor compilado directamente usando Node:

    node build/index.js

    El servidor se iniciará, se conectará a través de stdio e imprimirá registros (incluidos los mensajes console.error de index.ts ) en la consola.

  5. Interacción (Manual): Puedes enviar manualmente mensajes JSON-RPC (p. ej., tools/list , tools/call ) a la entrada estándar del servidor para probar sus respuestas. Herramientas como @modelcontextprotocol/inspector también pueden ser útiles ( npm run inspector ).

(Recuerde detener este servidor que se ejecuta manualmente antes de confiar en el host MCP para iniciarlo a través del archivo de configuración).

Arquitectura y flujo

  1. Solicitud de host MCP: un LLM solicita al host MCP (por ejemplo, extensión VS Code) que llame a la herramienta execute_code del servidor isolator con argumentos.

  2. Procesamiento del servidor ( index.ts ):

    • Recibe la solicitud tools/call a través de stdio.

    • Valida argumentos usando Zod.

    • Carga la configuración desde isolator_config.json .

    • Determina la fuente del código:

      • Si se proporciona snippet_name , lee el archivo correspondiente desde el promptsDir configurado y determina el idioma a partir de la extensión del archivo.

      • Si se proporcionan entrypoint_code y language , los utiliza directamente.

    • Crea un directorio temporal en el host.

    • Escribe el código del punto de entrada y cualquier additional_files en el directorio temporal.

    • Construye los argumentos de la línea de comandos para el isolator incorporado Go CLI, incluidos los indicadores de seguridad de la configuración y la ruta al directorio temporal.

    • Genera el proceso isolator usando Node.js child_process.spawn .

  3. Ejecución de Go CLI ( isolator-cli/isolator run ):

    • Analiza los indicadores (incluido el nuevo indicador --env ).

    • Crea un flujo tar del contenido del directorio temporal.

    • Utiliza el SDK de Docker para crear un contenedor con una imagen especificada, límites de recursos, variables de entorno (desde --env ) y configuraciones de seguridad (SIN montaje de enlace).

    • Utiliza CopyToContainer para copiar el flujo tar en el directorio de trabajo del contenedor.

    • Inicia el contenedor, que ejecuta el comando solicitado (por ejemplo, python /workspace/hello_world.py ).

    • Espera la finalización, captura stdout/stderr.

    • Quita el contenedor.

    • Imprime el resultado (estado, salida, etc.) como JSON en su salida estándar.

  4. Manejo de resultados del servidor ( index.ts ):

    • Lee la salida JSON de la salida estándar del proceso isolator finalizado.

    • Analiza el resultado JSON.

    • Formatea CallToolResult para MCP, combinando stdout/stderr y configurando isError si la CLI de Go informó un estado de no éxito.

    • Envía el resultado de vuelta al host MCP.

    • Limpia el directorio temporal en el host.

  5. Respuesta del host MCP: transmite el resultado al LLM, que luego formula una respuesta para el usuario.

Herramienta execute_code

Descripción

Ejecuta código (Python, Go, JavaScript) en un entorno de contenedor aislado y seguro.

Esquema de entrada ( arguments )

  • language (cadena, opcional): El lenguaje de programación (p. ej., "Python", "Go", "JavaScript"). Obligatorio si no se proporciona snippet_name .

  • entrypoint_code (cadena, opcional): El código principal que se ejecutará. Obligatorio si no se proporciona snippet_name .

  • entrypoint_filename (cadena, opcional): Nombre del archivo del código principal (p. ej., "main.py", "script.js"). Si no se proporciona, el valor predeterminado se basa en el idioma.

  • additional_files (matriz, opcional): matriz de objetos, cada uno con:

    • filename (cadena, obligatorio): Nombre del archivo adicional.

    • content (cadena, obligatorio): Contenido del archivo adicional.

  • snippet_name (cadena, opcional): Nombre de un archivo de fragmento de código predefinido (sin extensión) ubicado en el promptsDir configurado. Se excluye mutuamente con language y entrypoint_code .

Restricción: se debe proporcionar snippet_name O bien language y entrypoint_code .

Salida ( CallToolResult )

  • content : una matriz que contiene un único objeto TextContent .

    • type : "texto"

    • text : una cadena que contiene la salida estándar y la salida estándar combinadas de la ejecución, con el siguiente formato:

      --- stdout ---
      [Actual stdout output]
      --- stderr ---
      [Actual stderr output]

      Si se produjo un error durante la ejecución (código de salida distinto de cero, tiempo de espera), el texto se antepondrá con Execution Failed (status): [error message]\n\n .

  • isError (booleano): true si el estado de ejecución informado por la CLI isolator fue "error" o "tiempo de espera", false en caso contrario.

(Los errores a nivel de protocolo, como argumentos no válidos o errores al iniciar el proceso, generarán una respuesta de error MCP estándar en lugar de un CallToolResult ) .

Available Tools

1 tool
execute_codeC

Executes code (Python, Go, JavaScript) in a secure, isolated container environment.

ParametersJSON Schema
NameRequiredDescriptionDefault
additional_filesNoOptional array of additional files needed for execution
entrypoint_codeNoThe main code content to execute. Required unless using snippet_name.
entrypoint_filenameNoOptional filename for the main code (defaults based on language).
languageNoThe programming language (python, go, javascript). Required unless using snippet_name.
snippet_nameNoName of a pre-defined code snippet to execute (e.g., 'hello_world'). Mutually exclusive with entrypoint_code/language.

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'secure, isolated container environment' which hints at safety, but doesn't disclose critical behaviors like execution time limits, resource constraints, output handling, error behavior, or authentication needs. For a code execution tool with zero annotation coverage, this is insufficient.

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 a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary elaboration. It's 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.

Completeness2/5

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

Given the complexity of a code execution tool with no annotations and no output schema, the description is incomplete. It lacks details on return values, error handling, execution constraints, and safety guarantees. The description doesn't compensate for the missing structured data, leaving significant gaps for an AI agent.

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 100%, so the schema fully documents all 5 parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining mutual exclusivity rules or language-specific defaults. Baseline 3 is appropriate when schema does the heavy lifting.

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 action ('Executes code') and resource ('in a secure, isolated container environment'), specifying supported languages (Python, Go, JavaScript). It distinguishes from potential alternatives by mentioning the execution environment, but without sibling tools, full differentiation isn't possible.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. The description mentions the execution environment but doesn't specify use cases, prerequisites, or limitations. Without siblings, this is less critical, but still a gap in usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedexecute_code

TDQS

B3.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools, as there are no other tools to compare it to. The tool's purpose is clearly defined and distinct by default.

Naming Consistency5/5

Since there is only one tool, it inherently follows a consistent naming pattern with itself. The tool name 'execute_code' uses a clear verb_noun structure, which is appropriate and consistent in this minimal context.

Tool Count2/5

A single tool for a server named 'Isolator MCP Server' suggests a very narrow scope, but it may be too minimal for practical use. While the tool handles code execution, the server's purpose might imply broader isolation features, making the count feel thin and potentially under-scoped.

Completeness2/5

The tool surface is severely incomplete for a server focused on isolated code execution. There are obvious gaps, such as no tools for managing containers, listing available environments, checking execution status, or handling input/output beyond the single execute command, which will limit agent capabilities.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A TypeScript implementation of a Model Context Protocol server that provides a frictionless framework for developers to build and deploy AI tools and prompts, focusing on developer experience with zero boilerplate and automatic tool registration.
    681 npm
    14
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    A TypeScript implementation of a Model Context Protocol server that enables language models to securely query PostgreSQL databases, including those behind SSH bastion tunnels.
    9 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A TypeScript server implementing the Model Context Protocol that enables AI agents to interact with the Akash Network, allowing them to deploy applications, create leases, manage deployments, and access other Akash services through typed tools.
    58 npm
    13
    Apache 2.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that enables LLMs to run ANY code safely in isolated Docker containers.
    121
    MIT