tilt-mcp
About
Tilt MCP is a Model Context Protocol server that integrates with Tilt to provide programmatic access to Tilt resources, logs, and management operations for Kubernetes development environments
Details
- Author
- rrmistry
- Categories
- Cloud Service, Other, Infrastructure, Developer Tools
Jump to
Docker Configuration (Recommended for macOS/Windows)
Add the following to your Claude Desktop configuration file:
macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.config/claude/claude_desktop_config.json
For macOS/Linux (single Tilt instance on default port 10350):
{ "mcpServers": { "tilt": { "type": "stdio", "command": "docker", "args": ](#configuration)[ "run", "-i", "--rm", "-v", "${HOME}/.tilt-dev:/home/mcp-user/.tilt-dev", "-v", "${HOME}/.tilt-mcp:/home/mcp-user/.tilt-mcp", "--network=host", "ghcr.io/rrmistry/tilt-mcp:latest" ], "env": {} } } }
A single MCP server can query multiple Tilt instances. Simply specify thetilt_portparameter when calling tools or resources:
# Query resources from different Tilt instances trigger_resource(resource_name="backend", tilt_port="10350") # First instance trigger_resource(resource_name="backend", tilt_port="10351") # Second instance # Get logs from specific instance # URI: tilt://resources/backend/logs?tilt_port=10351
No additional configuration needed - use the same single-instance Docker config above.
{ "mcpServers": { "tilt": { "type": "stdio", "command": "docker", "args": [ "run", "-i", "--rm", "-v", "${env:USERPROFILE}\\.tilt-dev:/home/mcp-user/.tilt-dev", "-v", "${env:USERPROFILE}\\.tilt-mcp:/home/mcp-user/.tilt-mcp", "--network=host", "ghcr.io/rrmistry/tilt-mcp:latest" ], "env": {} } } }
For Windows (CMD):Use%USERPROFILE%instead of${env:USERPROFILE}in the volume mount paths.
- Thetilt_portparameter represents the web UI port (10350, 10351, etc.) - NOT the API port
- The Python code auto-discovers the actual API port from~/.tilt-dev/config
- Context naming: port 10350 → "tilt-default", port 10351 → "tilt-10351", etc.
- The~/.tilt-devdirectory must be mounted withwrite access(Tilt CLI needs lock files)
- socatdynamically forwards the discovered API port tohost.docker.internal
- --network=hostis required forhost.docker.internalto work on macOS/Windows
- auto(default): Auto-detect based on port accessibility. Skips socat if Tilt is already reachable on localhost (e.g., Docker on Linux with--network=host).
- trueor1: Always use socat forwarding, even if the port is already accessible.
- falseor0: Never use socat, even in Docker environments.
If you installed via PyPI or from source, use this simpler configuration:
{ "mcpServers": { "tilt": { "command": "tilt-mcp" } } }
Making sure thattilt-mcpis in your PATH.
To check the installed version of tilt-mcp:
docker build -t ghcr.io/rrmistry/tilt-mcp:latest .
docker build --build-arg TILT_VERSION=0.35.2 -t ghcr.io/rrmistry/tilt-mcp:latest .
To use Debian instead of Alpine (larger image but better compatibility):
docker build --build-arg BASE_IMAGE=python:3.11-slim-bookworm -t ghcr.io/rrmistry/tilt-mcp:latest .
Once configured, the Tilt MCP server provides Resources, Tools, and Prompts through the Model Context Protocol.
Resources are read-only and provide direct access to Tilt data. MCP clients can access them via their URI:
{ "resources": [ { "name": "frontend", "type": "k8s", "status": "ok", "updateStatus": "ok" }, { "name": "backend-api", "type": "k8s", "status": "pending", "updateStatus": "pending" } ], "count": 2 }
Returns the last 1000 lines of logs as plain text (default).
Returns the last 50 lines of logs as plain text.
Returns detailed YAML/text output with configuration, status, and build history.
Tools perform actions that modify the state of your Tilt environment.
{ "name": "trigger_resource", "arguments": { "resource_name": "backend" } }
{ "name": "enable_resource", "arguments": { "resource_names": ["frontend", "backend"], "enable_only": false } }
{ "name": "disable_resource", "arguments": { "resource_names": ["frontend", "backend"] } }
{ "name": "wait_for_resource", "arguments": { "resource_name": "backend", "condition": "Ready", "timeout_seconds": 60 } }
Prompts provide guided workflows for common tasks. They generate contextual messages that guide the LLM through debugging and troubleshooting.
{ "name": "debug_failing_resource", "arguments": { "resource_name": "backend" } }
This generates a comprehensive debugging workflow that guides the LLM to check logs, status, and suggest fixes.
{ "name": "health_check_all_resources", "arguments": {} }
This creates a systematic health check workflow across all resources.
{ "name": "optimize_resource_usage", "arguments": { "focus_resources": ["backend", "database"] } }
This guides the LLM to enable only specified resources and disable others to conserve system resources.
Here are some example prompts you can use with an AI assistant that has access to this MCP server:
- "Use the debug_failing_resource prompt for the backend service"
- "Run a health check on all my resources"
- "Use the troubleshoot_startup_failure prompt to investigate why the frontend won't start"
- "Analyze the logs from the backend service using the analyze_resource_logs prompt"
- "Help me optimize my resources to focus on just the backend and database"
- "Show me all the Tilt resources that are currently running"
- "Which services are failing or have errors?"
- "Compare the status of frontend and backend services"
- "Access the tilt://resources/all resource to see all services"
- "Get the last 100 lines of logs from the backend-api service"
- "Read the logs from tilt://resources/frontend/logs?tail=50"
- "Show me the last 200 lines of logs from any failing services"
- "Help me debug why the frontend service is crashing by looking at recent logs"
- "Disable the frontend and backend services"
- "Enable only the database service and disable everything else"
- "Enable the frontend service"
- "Disable all non-essential services to save resources"
- "Trigger a rebuild of the backend service"
- "Rebuild the frontend and show me the logs"
- "Trigger all services that have errors"
- "Wait for the backend to be ready before checking its logs"
- "Enable the backend, wait for it to be ready, then check its logs"
- "Disable all services, then enable only frontend and wait for it to start"
- "Get detailed info about the database and show me its recent logs"
- "Trigger a rebuild of the API service and wait until it's ready"
- "Run a complete health check and fix any issues you find"
- "Read tilt://resources/backend/describe to understand the configuration"
- "Compare logs from tilt://resources/frontend/logs?tail=500 and tilt://resources/backend/logs?tail=500"
- "Check tilt://resources/all to see which services need attention"
- "Get the last 50 lines from the frontend: tilt://resources/frontend/logs?tail=50"
A Model Context Protocol (MCP) server that integrates withTiltto provide programmatic access to Tilt resources and logs through LLM applications.
Please work on {some LLM request} and then check tilt MCP for "backend-api" resource logs for compile status. Make sure that "backend-tests" resource is successful with your changes.
The key insight is you no longer need to tell your LLMhowto build and deploy your code. Instead, you can simply ask it towhatto build and deploy.
Tilt is a powerful tool for working with Docker/Kubernetes workloads. With the Tilt MCP server, you can integrate Tilt's features directly into your workflow using Large Language Models (LLMs) like Claude Code / Codex / Gemini / VS Code Copilot / etc.
This saves significant LLM tokens (and so ⏱️+💰), both by avoiding to give extra context to your LLM on how to build/deploy, and also by avoiding LLMs actually doing the build/deploy. All the LLM needs to know is to make code changes then call the tilt MCP server to get real-time feedback.
The Tilt MCP server allows Large Language Models (LLMs) and AI assistants to interact with your Tilt development environment. It provides tools to:
- List all enabled Tilt resources
- Fetch logs from specific resources
- Monitor resource status and health
- Enable and disable resources dynamically
- Get detailed information about resources
- Trigger resource rebuilds
- Wait for resources to reach specific conditions
This enables AI-powered development workflows, debugging assistance, automated monitoring, and intelligent resource management of your Tilt-managed services.
The Tilt MCP server follows the Model Context Protocol specification and exposes three types of capabilities:
Resources provide read-only access to Tilt data. They're automatically discovered by MCP clients and can be accessed via their URI.
All resources support an optionaltilt_portparameter (default: 10350) to query different Tilt instances.
- tilt://resources/all- Get all resources from default port (10350)
- tilt://resources/all?tilt_port=10351- Get all resources from port 10351
- tilt://resources/frontend/logs- Get last 1000 lines from frontend (default)
- tilt://resources/frontend/logs?tail=100&tilt_port=10351- Get last 100 lines from frontend on port 10351
- tilt://resources/backend/logs?filter=error- Filter logs for errors (case-insensitive)
- tilt://resources/backend/logs?filter=X-Request-Id:%20abc123- Filter by request ID
- tilt://resources/backend/describe- Get detailed info about backend
Tools enable LLMs to perform actions that modify the state of your Tilt environment.
Read-Only Tools(for clients that don't support MCP Resources):
Note:The read-only tools (list_resources,get_resource_logs,describe_resource) provide the same functionality as the MCP Resources above, but are exposed as tools for better compatibility with LLM clients (like Claude Code) that may not fully support MCP resource discovery.
All tools support an optionaltilt_portparameter to target different Tilt instances running on different ports.
Prompts are reusable templates that guide the LLM through common debugging and troubleshooting workflows.
All capabilities include comprehensive error handling:
- Resource Not Found: RaisesValueErrorwith helpful message
- Tilt Connection Issues: RaisesRuntimeErrorwith Tilt error details
- JSON Parsing Errors: Provides detailed parsing error information
All operations are logged to~/.tilt-mcp/tilt_mcp.logfor debugging.
- 🔍Resources: Read-only access to Tilt data via URI templates (e.g.,tilt://resources/all)
- 🛠️Tools: Actions with side effects for resource management and control
- 💡Prompts: Guided workflows for debugging and troubleshooting
- 📊Resource Discovery: List all active Tilt resources with their current status
- 📜Log Retrieval: Fetch recent logs from any Tilt resource with configurable tail
- 🔄Resource Triggering: Manually trigger Tilt resources to rebuild/update
- ✅Resource Control: Enable or disable resources dynamically
- 📋Detailed Information: Get comprehensive details about any resource
- ⏳Wait Conditions: Wait for resources to reach specific states
- 🤖Guided Workflows: Pre-built prompts for common debugging scenarios
- 🛡️Type Safety: Built with Python type hints for better IDE support
- 🚀Async Support: Fully asynchronous implementation using FastMCP
- 📈MCP Best Practices: Proper separation of resources, tools, and prompts
- 🔧Comprehensive Logging: All operations logged to~/.tilt-mcp/tilt_mcp.log
- Python 3.10 or higher (required by FastMCP 2.0)
- Tiltinstalled and configured
- An MCP-compatible client (e.g., Claude Desktop, mcp-cli)
Option 1: Using Docker (Recommended for macOS/Windows)
The Docker-based installation requires no Python setup and is automatically kept up-to-date with monthly builds. The image is optimized for size using Alpine Linux (~320MB vs 545MB+ for Debian-based images - 41% reduction).
- Automatically discovers the Tilt API port from~/.tilt-dev/configbased on thetilt_portparameter
- Usessocatto dynamically create a TCP tunnel from inside the container to the host Tilt server
- Your host's~/.tilt-devdirectory is mounted with write access (Tilt CLI needs lock files)
- A single MCP server can query multiple Tilt instances by specifying differenttilt_portvalues (10350, 10351, etc.)
- The Python code handles port discovery and socat management automatically
Note:The image size is primarily driven by FastMCP 2.0's dependencies (cryptography, pydantic, etc.). For reference:
- Base Alpine + Python: ~50MB
- Tilt binary: ~20MB
- FastMCP 2.0 + dependencies: ~250MB
See theMCP Configurationsection below for setup instructions.
Best for:Linux users or when you prefer local installation
git clone https://github.com/rrmistry/tilt-mcp.git cd tilt-mcp pip install -e .
Best for:Development or testing local changes
Docker Configuration (Recommended for macOS/Windows)
Add the following to your Claude Desktop configuration file:
macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.config/claude/claude_desktop_config.json
For macOS/Linux (single Tilt instance on default port 10350):
{ "mcpServers": { "tilt": { "type": "stdio", "command": "docker", "args": [ "run", "-i", "--rm", "-v", "${HOME}/.tilt-dev:/home/mcp-user/.tilt-dev", "-v", "${HOME}/.tilt-mcp:/home/mcp-user/.tilt-mcp", "--network=host", "ghcr.io/rrmistry/tilt-mcp:latest" ], "env": {} } } }
A single MCP server can query multiple Tilt instances. Simply specify thetilt_portparameter when calling tools or resources:
# Query resources from different Tilt instances trigger_resource(resource_name="backend", tilt_port="10350") # First instance trigger_resource(resource_name="backend", tilt_port="10351") # Second instance # Get logs from specific instance # URI: tilt://resources/backend/logs?tilt_port=10351
No additional configuration needed - use the same single-instance Docker config above.
{ "mcpServers": { "tilt": { "type": "stdio", "command": "docker", "args": [ "run", "-i", "--rm", "-v", "${env:USERPROFILE}\\.tilt-dev:/home/mcp-user/.tilt-dev", "-v", "${env:USERPROFILE}\\.tilt-mcp:/home/mcp-user/.tilt-mcp", "--network=host", "ghcr.io/rrmistry/tilt-mcp:latest" ], "env": {} } } }
For Windows (CMD):Use%USERPROFILE%instead of${env:USERPROFILE}in the volume mount paths.
- Thetilt_portparameter represents the web UI port (10350, 10351, etc.) - NOT the API port
- The Python code auto-discovers the actual API port from~/.tilt-dev/config
- Context naming: port 10350 → "tilt-default", port 10351 → "tilt-10351", etc.
- The~/.tilt-devdirectory must be mounted withwrite access(Tilt CLI needs lock files)
- socatdynamically forwards the discovered API port tohost.docker.internal
- --network=hostis required forhost.docker.internalto work on macOS/Windows
- auto(default): Auto-detect based on port accessibility. Skips socat if Tilt is already reachable on localhost (e.g., Docker on Linux with--network=host).
- trueor1: Always use socat forwarding, even if the port is already accessible.
- falseor0: Never use socat, even in Docker environments.
If you installed via PyPI or from source, use this simpler configuration:
{ "mcpServers": { "tilt": { "command": "tilt-mcp" } } }
Making sure thattilt-mcpis in your PATH.
To check the installed version of tilt-mcp:
docker build -t ghcr.io/rrmistry/tilt-mcp:latest .
docker build --build-arg TILT_VERSION=0.35.2 -t ghcr.io/rrmistry/tilt-mcp:latest .
To use Debian instead of Alpine (larger image but better compatibility):
docker build --build-arg BASE_IMAGE=python:3.11-slim-bookworm -t ghcr.io/rrmistry/tilt-mcp:latest .
Once configured, the Tilt MCP server provides Resources, Tools, and Prompts through the Model Context Protocol.
Resources are read-only and provide direct access to Tilt data. MCP clients can access them via their URI:
{ "resources": [ { "name": "frontend", "type": "k8s", "status": "ok", "updateStatus": "ok" }, { "name": "backend-api", "type": "k8s", "status": "pending", "updateStatus": "pending" } ], "count": 2 }
Returns the last 1000 lines of logs as plain text (default).
Returns the last 50 lines of logs as plain text.
Returns detailed YAML/text output with configuration, status, and build history.
Tools perform actions that modify the state of your Tilt environment.
{ "name": "trigger_resource", "arguments": { "resource_name": "backend" } }
{ "name": "enable_resource", "arguments": { "resource_names": ["frontend", "backend"], "enable_only": false } }
{ "name": "disable_resource", "arguments": { "resource_names": ["frontend", "backend"] } }
{ "name": "wait_for_resource", "arguments": { "resource_name": "backend", "condition": "Ready", "timeout_seconds": 60 } }
Prompts provide guided workflows for common tasks. They generate contextual messages that guide the LLM through debugging and troubleshooting.
{ "name": "debug_failing_resource", "arguments": { "resource_name": "backend" } }
This generates a comprehensive debugging workflow that guides the LLM to check logs, status, and suggest fixes.
{ "name": "health_check_all_resources", "arguments": {} }
This creates a systematic health check workflow across all resources.
{ "name": "optimize_resource_usage", "arguments": { "focus_resources": ["backend", "database"] } }
This guides the LLM to enable only specified resources and disable others to conserve system resources.
Here are some example prompts you can use with an AI assistant that has access to this MCP server:
- "Use the debug_failing_resource prompt for the backend service"
- "Run a health check on all my resources"
- "Use the troubleshoot_startup_failure prompt to investigate why the frontend won't start"
- "Analyze the logs from the backend service using the analyze_resource_logs prompt"
- "Help me optimize my resources to focus on just the backend and database"
- "Show me all the Tilt resources that are currently running"
- "Which services are failing or have errors?"
- "Compare the status of frontend and backend services"
- "Access the tilt://resources/all resource to see all services"
- "Get the last 100 lines of logs from the backend-api service"
- "Read the logs from tilt://resources/frontend/logs?tail=50"
- "Show me the last 200 lines of logs from any failing services"
- "Help me debug why the frontend service is crashing by looking at recent logs"
- "Disable the frontend and backend services"
- "Enable only the database service and disable everything else"
- "Enable the frontend service"
- "Disable all non-essential services to save resources"
- "Trigger a rebuild of the backend service"
- "Rebuild the frontend and show me the logs"
- "Trigger all services that have errors"
- "Wait for the backend to be ready before checking its logs"
- "Enable the backend, wait for it to be ready, then check its logs"
- "Disable all services, then enable only frontend and wait for it to start"
- "Get detailed info about the database and show me its recent logs"
- "Trigger a rebuild of the API service and wait until it's ready"
- "Run a complete health check and fix any issues you find"
- "Read tilt://resources/backend/describe to understand the configuration"
- "Compare logs from tilt://resources/frontend/logs?tail=500 and tilt://resources/backend/logs?tail=500"
- "Check tilt://resources/all to see which services need attention"
- "Get the last 50 lines from the frontend: tilt://resources/frontend/logs?tail=50"
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
