The Babashka MCP Server allows interaction with the Babashka interpreter via the Model Context Protocol (MCP), enabling code execution and resource management.
Execute Babashka code: Run Clojure scripts and expressions through the server with configurable timeouts.
Timeout configuration: Set execution timeouts between 1-300 seconds (1,000-300,000 milliseconds), with a default of 30 seconds.
Access command history: Retrieve and browse results of recent command executions through MCP resources (e.g., babashka://commands/{index}).
Result caching: Automatically cache recent command executions for efficient retrieval.
Custom configuration: Specify the path to the Babashka executable using the BABASHKA_PATH environment variable.
Development roadmap: Future plans include self-hosting, REPL integration, and performance optimizations.
The MCP server provides integration with Babashka, which is a native Clojure interpreter for scripting. It allows execution of Clojure code through the MCP protocol.
The README mentions GitHub Actions tools for Babashka, including setup-babashka and babashka-docker-action, which are recommended for using Babashka in GitHub Actions workflows.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Babashka MCP Server execute (+ 1 2 3) to test basic arithmetic"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for interacting with Babashka, a native Clojure interpreter for scripting.
Execute Babashka code through MCP tools
Cache recent command results
Access command history through MCP resources
Configurable command timeouts
Related MCP server: macOS Automator MCP Server
Babashka can be installed in several ways:
brew install borkdude/brew/babashkabash < <(curl -s https://raw.githubusercontent.com/babashka/babashka/master/install)# Using scoop
scoop install babashkaFor other installation methods, see the official Babashka installation guide.
After installation, verify Babashka works:
# 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 buildThe server can be configured through environment variables:
BABASHKA_PATH: Path to the Babashka executable (default: "bb")
Execute Babashka code with optional timeout:
{
name: "execute",
arguments: {
code: string; // Babashka code to execute
timeout?: number; // Timeout in milliseconds (default: 30000)
}
}Example:
{
name: "execute",
arguments: {
code: "(+ 1 2 3)",
timeout: 5000
}
}The server maintains a cache of recent command executions accessible through:
babashka://commands/{index} - Access specific command results by index
Babashka supports explicit tail call optimization through the recur special form, but does not implement automatic TCO. For example:
;; 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))))Babashka GitHub Repository - The main Babashka project
Babashka Book - Official documentation
Babashka Examples - Collection of example scripts
pod-babashka-buddy - Cryptographic API for Babashka
bb-clis - Collection of useful Babashka CLI scripts
bb-scripts - Various utility scripts for Babashka
setup-babashka - GitHub Actions for installing Babashka
babashka-docker-action - Run Babashka scripts in GitHub Actions
This server is designed to eventually become self-hosting, meaning it will be rewritten in Babashka itself. The current TypeScript implementation serves as a reference and starting point.
Self-Hosted Implementation
Rewrite the MCP server in Babashka
Leverage Babashka's native capabilities for better performance
Remove Node.js dependency
Maintain full compatibility with MCP protocol
Support all current features:
Command execution
Resource management
Command history
Timeout handling
Enhanced Features
Add support for Babashka pods
Implement file watching capabilities
Add REPL integration
Support for multiple Babashka instances
Performance Optimizations
Implement caching strategies
Optimize resource usage
Reduce startup time
Testing & Documentation
Comprehensive test suite
API documentation
Usage examples
Performance benchmarks
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. Dates show when Glama detected each change.
v1.0.0executeWith 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bmorphism/babashka-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
