jabali-mcp: run your hosting panel from any AI assistant

Every hosting panel gives you the same clicks. Log in, open Domains, add a subdomain, open DNS, add an A record, open SSL, wait for Let’s Encrypt, open Applications, install WordPress, open Mail, create a mailbox, open Cron, add a job. Nine tabs to stand up a site — and if something breaks a week later, another five tabs to find out why. The panel is faster than SSHing around a bare Debian box, but it’s still a lot of clicks per outcome.

Today we’re shipping something that changes that: jabali-mcp, an open-source Model Context Protocol server that lets an AI assistant drive Jabali Panel end-to-end. Ask for what you want; the assistant does it through the panel’s own API.

What MCP is, in one paragraph

The Model Context Protocol is an open standard for connecting AI assistants to external tools. An MCP server exposes a set of tool calls (functions with typed parameters); an MCP client (Claude, Codex, Kimicode, OpenCode, and others) launches the server on demand and calls those tools during a conversation. jabali-mcp is a small Go binary that wraps Jabali Panel’s REST API as 75+ MCP tools — list_domains, get_ssl_status, diagnose_domain, list_mailboxes, get_cron_log, and so on.

The point is that the tool surface is huge but the server is thin. It re-implements no auth, no validation, no scoping. Your API token acts as your user, and the panel enforces ownership on every endpoint — exactly as it does for any other API client. A tenant token can only ever touch that tenant’s resources.

What it looks like

The most common prompt during our internal beta was the same one every panel operator types five times a week: “why is X down?”

Without jabali-mcp, that means: open the panel, find the domain, check SSL, check DNS, tail nginx errors, check the reconciler status. Six tabs and a handful of terminals.

With jabali-mcp, it’s a single sentence. The assistant runs one diagnose_domain call (which internally gathers config, SSL status, DNS records, recent nginx errors, and bandwidth), reads the JSON, and tells you the answer:

You: why is example.com down? Claude calls diagnose_domain(domain: "example.com"). Claude: The A record for example.com points at 203.0.113.9, but this server’s IP is 203.0.113.4. DNS was changed 2 hours ago. Update the A record and it comes back.

Other things people used it for in beta:

• “Set up mail for my new domain: two mailboxes and a catch-all forwarder.” — creates the mailboxes and forwarder in one turn.
• “Add an A record for vpn pointing at 203.0.113.5, TTL 300.” — validated against the panel’s DNS rules before anything is sent.
• “Enable Let’s Encrypt on every domain that doesn’t have it.” — checks each domain’s SSL status, issues certificates where missing.
• “Create a database and user for the shop app, read-write.” — database, user, and grant in one conversation; the password is shown once.
• “Something’s wrong with SSL issuance — file a bug.” — report_issue drafts a GitHub issue with live diagnostics attached, and you review it before anything is posted.

Safety model

A hosting panel is a control plane, not a chatbot demo. We shipped jabali-mcp with four guardrails on by default. All four:

1. Read-only by default. Mutating tools are not registered unless you opt in with JABALI_MCP_ALLOW_WRITE=1. Without it, an assistant that tries to call a write tool sees the tool doesn’t exist — not an error, no way for a prompt-injected instruction to talk it into trying.
2. Two-step destructive actions. Deletes, restores, and password rotations return a preview first. The tool executes only when re-called with confirm: true. An assistant cannot destroy anything in one call.
3. Dry-run everything. JABALI_MCP_DRY_RUN=1 (or per-call dry_run: true) shows the exact REST request the tool would send, without sending it. Useful when you’re about to enable writes and want to see exactly what a prompt will do.
4. Token boundary. Ownership is enforced server-side by the panel on every endpoint. The MCP server can’t reach anything your token can’t. A tenant token is scoped to that tenant’s resources only — the assistant sees only that tenant’s domains, mailboxes, databases.

Every tool call is a normal REST request in your panel’s audit trail. Whatever an assistant does with jabali-mcp, you can see it in Audit Log with the token id captured in the actor metadata.

Which AI clients work

Any MCP-capable client. As of v0.4.0 we’ve verified:

• Claude Code (claude mcp add jabali -- jabali-mcp)
• Claude Desktop (paste an mcpServers block into the config JSON)
• OpenAI Codex (Codex CLI + Codex IDE integrations)
• Kimicode
• OpenCode
• Any other client speaking the Model Context Protocol

Nothing about the server is Claude-specific.

Setup in five minutes

Install the binary (prebuilt release or go install):

go install github.com/shukiv/jabali-mcp/cmd/jabali-mcp@latest

Log in to your Jabali Panel as the tenant you want the assistant to manage, go to API Tokens → MCP, and let the wizard generate a config block with your token pre-filled. Everything happens in the browser.

Register with Claude Code:

claude mcp add jabali -- jabali-mcp

For other clients, drop this into their mcpServers config:

{
  "mcpServers": {
    "jabali": {
      "command": "jabali-mcp",
      "env": {
        "JABALI_PANEL_URL": "https://panel.example:8443/api/v1",
        "JABALI_API_TOKEN": "jat_…"
      }
    }
  }
}

Start read-only. Turn writes on later with JABALI_MCP_ALLOW_WRITE=1, and keep JABALI_MCP_DRY_RUN=1 in the env until you trust the flows you’re using it for.

Why now, and what’s next

MCP is a new protocol — it landed in late 2024 and picked up serious client adoption through 2025 and 2026. We built jabali-mcp once it was clear the protocol wasn’t tied to one vendor: Anthropic wrote the spec, but Codex, Kimicode, OpenCode, and other clients speak it too. Building against an open standard means the same server works everywhere, forever, without us maintaining a matrix of vendor SDKs.

The roadmap is open. Bulk operations across many domains, webhook-driven proactive alerts, and per-app scopes for the Applications registry are all under active discussion. Drop ideas in github.com/shukiv/jabali-panel/discussions/963.

For the full write-up — safety model, environment variables, tool surface, troubleshooting — see the platform docs or the feature page. Source is at github.com/shukiv/jabali-mcp.