Kunobi MCP Server
The Kunobi MCP Server bridges AI assistants to the Kunobi desktop IDE for platform engineering, enabling AI-driven management of Kubernetes, FluxCD, ArgoCD, and Helm.
Check Kunobi Status (
kunobi_status): Determine if Kunobi is installed, running, and what tools are currently available through it (e.g.,app_info,query_store,list_stores).Launch Kunobi (
kunobi_launch): Start the Kunobi desktop application, optionally specifying a variant (e.g.,"Kunobi Dev"); defaults to the first installed one.Dynamic Tool Access: When Kunobi is running with MCP enabled, additional tools for managing Kubernetes clusters, FluxCD, ArgoCD, and Helm automatically become available, including real-time cluster visibility, resource browsing, YAML editing, and embedded terminal access.
Auto-reconnect: The server automatically detects when Kunobi stops or restarts and updates tool availability without requiring an MCP server restart.
Real-time Oversight: Users can visually monitor all AI-driven operations through Kunobi's interface while AI assistants perform management tasks.
Enables AI assistants to manage and monitor ArgoCD deployments and resources through the Kunobi platform.
Enables AI assistants to manage and monitor FluxCD resources and deployments through the Kunobi platform.
Provides tools for managing Helm charts and releases via the Kunobi desktop IDE.
Enables real-time Kubernetes cluster visibility, resource browsing, and management through the Kunobi desktop platform.
Click on "Deploy 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., "@Kunobi MCP Server query the store for the most recent entries"
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.
@kunobi/mcp
MCP bridge to Kunobi, a desktop platform management IDE. AI assistants manage Kubernetes, FluxCD, ArgoCD, and Helm while users maintain real-time visual oversight.

What is Kunobi?
Kunobi is a desktop IDE for platform engineering — built with Rust and React, no Electron.
Real-time cluster visibility with resource browser, YAML editor, and embedded terminal
Native FluxCD, ArgoCD, and Helm support
Built-in MCP server for AI assistants (Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, GitHub Copilot CLI)
Available on macOS, Windows, and Linux
No account required, no cloud dependency

Related MCP server: veriloop
Setup
Enable MCP in Kunobi under Settings > AI & MCP, then install:

Automatic (recommended)
Register with all your AI clients in one step:
npx @kunobi/mcp --installThis interactively detects your installed AI clients and registers the server with them. Supported clients:
Claude Code — project or user scope
Claude Desktop — user scope
Cursor — project or user scope
Windsurf — project or user scope
Codex CLI — project or user scope
Gemini CLI — project or user scope
GitHub Copilot CLI — user scope
To remove the server from all clients:
npx @kunobi/mcp --uninstallUpdating
install pins your clients to an exact version (e.g. @kunobi/mcp@1.2.3) so each
launch runs from the npm cache instead of resolving latest from the registry on
every spawn — startup stays fast and can't stall on the network. When a newer
version is published, the server tells you on connect; apply it with:
npx @kunobi/mcp upgradeThis re-pins every client where Kunobi is registered to the newest version and warms the cache. Restart your AI client to load it (the new version takes effect on the next start).
Installed before pinning existed? Pin your current version in place — no upgrade, no registry call:
npx @kunobi/mcp pinIf you ran an older build, the server also hints this on connect when it detects
an unpinned config. Silence the hint with MCP_KUNOBI_NO_PIN_HINT=1.
Prefer always-latest? Opt back out — each launch will resolve the newest version again (slower startup, and can stall on the registry):
npx @kunobi/mcp unpinManual
If you prefer manual setup, add the following to your client's MCP config:
{
"mcpServers": {
"kunobi": {
"command": "npx",
"args": ["-y", "@kunobi/mcp"]
}
}
}How it works
AI assistant <--stdio--> @kunobi/mcp <--HTTP--> Kunobi variants
│
├── keeps one MCP connection per configured variant
├── retries disconnected variants every 5s
└── manages one bundler per variantThe server keeps a persistent MCP connection for each configured Kunobi variant. When a variant is available, its tools are registered with a variant__ prefix (e.g., dev__list_clusters, stable__query_store). When a variant briefly drops, the hub keeps the last-known surface stable while it reconnects in the background. If the disconnect outlives the reconnect grace window, the stale registrations are removed.
Multi-variant support
Kunobi ships multiple release channels that run on different ports. This MCP server discovers all of them simultaneously:
Variant | Default port | Tool prefix |
legacy | 3030 |
|
stable | 3200 |
|
unstable | 3300 |
|
dev | 3400 |
|
local | 3500 |
|
e2e | 3600 |
|
These defaults are auto-generated into ~/.config/kunobi/mcp.json on first run. You can add custom variants or change ports — see Configuration.
Built-in tools
These are always available, even when no Kunobi instance is running:
kunobi_status— reports all variant connection states, ports, and tool countskunobi_launch— launches a Kunobi variant by namekunobi_refresh— forces an immediate reconnect attempt across all configured variantskunobi_call— stable entrypoint for variant tools (variant,tool,arguments)
Recommended calling pattern
Use the stable path below for the most reliable MCP client behavior:
Call
kunobi_statusRead
kunobi://toolsto discover full downstream tool schemas and metadataExecute via
kunobi_call(variant, tool, arguments)
Dynamic tools
When a Kunobi variant is detected, its tools appear automatically with a variant prefix. For example, if dev and stable are both running:
dev__app_info,dev__query_store,dev__list_stores, ...stable__app_info,stable__query_store,stable__list_stores, ...
Tools appear dynamically as variants start, and they are withdrawn only after a sustained disconnect — no MCP server restart needed.
These dynamic variant__tool entries are still supported, but some MCP clients may not refresh dynamic tool lists reliably. Use kunobi_call as the primary path when in doubt.
Resources
Resources exposed by Kunobi variants are proxied through automatically. When a variant connects, its resources become available to the AI client with variant-namespaced URIs to avoid collisions between multiple running variants.
The server also provides built-in resources:
kunobi://status— JSON snapshot of all variant connection states, ports, and capability counts. Supports subscriptions — clients receivenotifications/resources/updatedwhenever variants connect or disconnect.kunobi://tools— JSON discovery document listing each variant status plus full downstream tool, resource, and prompt metadata forkunobi_call.
Prompts
Prompts from Kunobi variants are registered with a variant__ prefix (e.g., dev__setup_cluster). They appear and disappear alongside their variant, just like tools.
Configuration
Config file
Variant-to-port mappings are stored in ~/.config/kunobi/mcp.json (auto-generated on first run with defaults). You can edit this file directly or use the CLI:
# List all configured variants and their connection status
kunobi-mcp list
# Add a custom variant
kunobi-mcp add juan 4200
# Remove a variant
kunobi-mcp remove juanEnvironment variables
Env var | Default | Description |
|
| Reconnect interval in ms |
| — |
|
|
| Set |
| — | Set |
Priority: config file defaults → MCP_KUNOBI_VARIANTS env var (merges on top).
CLI
kunobi-mcp [command] [options]Command | Description |
| Show configured variants and connection status |
| Add or update a variant |
| Remove a variant |
| Register this MCP server with your AI clients (pinned to the current version) |
| Remove this MCP server from your AI clients |
| Pin your AI clients to the current version (faster, hang-proof startup) |
| Revert to always-latest ( |
| Re-pin your AI clients to the latest published version (restart to apply) |
| Show help message |
| Show version number |
(no command, piped) | Start the stdio MCP server (used by AI clients) |
Development
pnpm install
pnpm build
pnpm testFor local development against @kunobi/mcp-bundler:
pnpm dev:link # link local bundler
pnpm dev:unlink # revert to npm versionLicense
Available Tools
2 toolskunobi_callA
Stable tool entrypoint for Kunobi operations. Call a variant tool via (variant, tool, arguments), e.g. variant="dev", tool="k8s". Use kunobi://tools to discover full downstream tool schemas and metadata.
Inputs: tool (required), variant (required), arguments.
kunobi_statusARead-only
Check which Kunobi variants are currently connected to this hub. Reports each variant's port, connection status, available tools, and reconnect timing. Call this before using Kunobi tools to understand what's available.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 2 tools
Each tool has a clear and distinct purpose: 'kunobi_call' is for executing operations on variants, while 'kunobi_status' is for checking connection status and available tools. There is no overlap in functionality.
Both tool names follow a consistent 'kunobi_<verb>' pattern (kunobi_call, kunobi_status), making them predictable and easy to understand.
With only 2 tools, the server feels thin for a hub that presumably provides many downstream tools. However, the tools serve as a lightweight entry point, so the count is borderline acceptable.
The server covers the core lifecycle for a tool hub: discovery (via kunobi_call with 'kunobi://tools'), execution (kunobi_call), and status monitoring (kunobi_status). Missing are variant management tools like registration or shutdown, but these are minor gaps.
Maintenance
Related MCP Connectors
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Remote streamable-HTTP MCP server running on a single Cloudflare Worker. Your assistant gets live Airbnb, Amazon, Booking.com, Google Flights, Maps and Reddit data, social search on X, Instagram and TikTok, the Meta Ad Library, and image/video generation without any keys. Connect your own accounts to let it send WhatsApp or Telegram messages, work an IMAP inbox, manage Meta Ads campaigns and publish to X and LinkedIn. OAuth 2.1 with PKCE; stored credentials are AES-256-GCM encrypted.
Related MCP Servers
AlicenseAqualityDmaintenanceStdio bridge for editors to connect to the GenieOS MCP server, enabling AI agents to interact with GenieOS via Streamable HTTP transport.6413 npmMIT- AlicenseAqualityDmaintenanceExposes a verified tool registry (calculator, sandboxed file read, web fetch) over MCP stdio, enabling any MCP-capable client to reuse the same tools from the inspectable ReAct loop.3MIT
- AlicenseNot gradedqualityDmaintenanceA thin stdio-to-HTTP bridge that forwards MCP messages to the hosted Proxycept server, enabling stdio-only MCP clients to access Proxycept's tool catalog.12 npmMIT
- AlicenseNot gradedqualityCmaintenanceConnects AI clients to workspace context and enabled tools in the Ikuna app on macOS through a local stdio bridge.31 npmMIT