Un servidor de protocolo de contexto de modelo para interactuar con Babashka , un intérprete nativo de Clojure para scripts.
Ejecutar código Babashka mediante herramientas MCP
Almacenar en caché los resultados de comandos recientes
Acceda al historial de comandos a través de los recursos de MCP
Tiempos de espera de comandos configurables
Related MCP server: Claude Code Control MCP
Babashka se puede instalar de varias maneras:
brew install borkdude/brew/babashkabash < <(curl -s https://raw.githubusercontent.com/babashka/babashka/master/install)# Using scoop
scoop install babashkaPara otros métodos de instalación, consulte la guía de instalación oficial de Babashka .
Después de la instalación, verifique que Babashka funcione:
# Check version
bb --version
# Try a simple expression
bb -e '(+ 1 2 3)'
# Run a script from string
bb -e '(defn hello [x] (str "Hello, " x "!")) (hello "World")'
# Use -i flag to process lines of input
ls | bb -i '(take 2 *input*)'# Install dependencies
npm install
# Build the MCP server
npm run buildEl servidor se puede configurar a través de variables de entorno:
BABASHKA_PATH : Ruta al ejecutable de Babashka (predeterminado: "bb")
Ejecutar código Babashka con tiempo de espera opcional:
{
name: "execute",
arguments: {
code: string; // Babashka code to execute
timeout?: number; // Timeout in milliseconds (default: 30000)
}
}Ejemplo:
{
name: "execute",
arguments: {
code: "(+ 1 2 3)",
timeout: 5000
}
}El servidor mantiene un caché de ejecuciones de comandos recientes accesible a través de:
babashka://commands/{index} - Acceder a resultados de comandos específicos por índice
Babashka admite la optimización explícita de llamadas finales mediante la forma especial recur , pero no implementa el TCO automático. Por ejemplo:
;; This will cause stack overflow
(defn countdown [n]
(if (zero? n)
:done
(countdown (dec n))))
;; This works with TCO using recur
(defn countdown [n]
(if (zero? n)
:done
(recur (dec n))))Repositorio Babashka GitHub : el proyecto principal de Babashka
Libro de Babashka - Documentación oficial
Ejemplos de Babashka - Colección de ejemplos de guiones
pod-babashka-buddy - API criptográfica para Babashka
bb-clis - Colección de scripts útiles de Babashka CLI
bb-scripts - Diversos scripts de utilidad para Babashka
setup-babashka - Acciones de GitHub para instalar Babashka
babashka-docker-action - Ejecutar scripts de Babashka en GitHub Actions
Este servidor está diseñado para ser autoalojado, lo que significa que se reescribirá en Babashka. La implementación actual de TypeScript sirve como referencia y punto de partida.
Implementación autoalojada
Reescribir el servidor MCP en Babashka
Aproveche las capacidades nativas de Babashka para un mejor rendimiento
Eliminar la dependencia de Node.js
Mantener la compatibilidad total con el protocolo MCP
Admite todas las funciones actuales:
Ejecución de comandos
Gestión de recursos
Historial de comandos
Manejo del tiempo de espera
Funciones mejoradas
Añadir soporte para cápsulas Babashka
Implementar capacidades de vigilancia de archivos
Añadir integración REPL
Compatibilidad con múltiples instancias de Babashka
Optimizaciones de rendimiento
Implementar estrategias de almacenamiento en caché
Optimizar el uso de recursos
Reducir el tiempo de inicio
Pruebas y documentación
Conjunto completo de pruebas
Documentación de la API
Ejemplos de uso
Puntos de referencia de rendimiento
Execute Babashka (bb) code
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Babashka code to execute | |
| timeout | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('execute') but doesn't describe key behaviors like execution environment, security implications, error handling, or output format. This is a significant gap for a tool that runs arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing code and the lack of annotations and output schema, the description is incomplete. It doesn't address critical aspects like what the execution returns, error conditions, or safety considerations, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters (code and timeout). The description adds no additional meaning beyond what the schema provides, such as examples of valid Babashka code or timeout implications. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('execute') and resource ('Babashka (bb) code'), making the purpose immediately understandable. It doesn't need sibling differentiation since there are no sibling tools, but it could be slightly more specific about what 'execute' entails (e.g., running code in a Babashka environment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, such as typical use cases, prerequisites, or alternatives. With no sibling tools, it doesn't need to distinguish from others, but it lacks any context about appropriate scenarios for executing Babashka code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0executeScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'execute' has a clear and distinct purpose for running Babashka code.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'execute' is straightforward and appropriate for its function.
A single tool is too few for most practical server purposes, as it severely limits functionality and flexibility. While it might suffice for a minimal interface, it feels thin and under-scoped for general use.
The tool provides basic execution capability, but there are notable gaps such as no tools for managing scripts, handling dependencies, or providing utilities like linting or debugging. This limits the server's usefulness for broader Babashka workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
A Model Context Protocol server for Wix AI tools
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
