AI Admin (MCP)

The MCP server transforms Danube cluster management into a conversation. Instead of memorizing CLI syntax, describe what you want in natural language, your AI assistant calls the right tools, follows safety workflows, and explains what it finds.

Quick Start

danube-admin serve --mode mcp --broker-endpoint http://localhost:50051

The server communicates over stdio using the Model Context Protocol. Connect it to any MCP-compatible AI assistant.

IDE Configuration

Claude Code auto-discovers MCP servers from a project-level config file:

{
  "mcpServers": {
    "danube-admin": {
      "command": "/usr/local/bin/danube-admin",
      "args": ["serve", "--mode", "mcp", "--broker-endpoint", "http://localhost:50051"],
      "env": {
        "NO_COLOR": "1",
        "RUST_LOG": "error"
      }
    }
  }
}

Or add globally via claude mcp add:

claude mcp add danube-admin -- /usr/local/bin/danube-admin serve --mode mcp --broker-endpoint http://localhost:50051

Antigravity discovers MCP servers from its settings file:

{
  "mcpServers": {
    "danube-admin": {
      "command": "/usr/local/bin/danube-admin",
      "args": ["serve", "--mode", "mcp", "--broker-endpoint", "http://localhost:50051"],
      "env": {
        "NO_COLOR": "1",
        "RUST_LOG": "error"
      }
    }
  }
}

Add to Cursor’s MCP configuration:

{
  "mcpServers": {
    "danube-admin": {
      "command": "/usr/local/bin/danube-admin",
      "args": ["serve", "--mode", "mcp", "--broker-endpoint", "http://localhost:50051"],
      "env": {
        "NO_COLOR": "1",
        "RUST_LOG": "error"
      }
    }
  }
}

Add to VS Code’s settings or Copilot MCP configuration:

{
  "servers": {
    "danube-admin": {
      "type": "stdio",
      "command": "/usr/local/bin/danube-admin",
      "args": ["serve", "--mode", "mcp", "--broker-endpoint", "http://localhost:50051"],
      "env": {
        "NO_COLOR": "1",
        "RUST_LOG": "error"
      }
    }
  }
}

What You Can Do

The MCP server exposes 58 tools across 8 categories and 4 guided workflow prompts.

Cluster & Brokers

14 tools: broker lifecycle, namespaces, Raft membership, load balancing, and rebalancing.

Topics

12 tools: topic CRUD, subscriptions, schema binding, validation policies, and failure policies.

Schema Registry

9 tools: register, evolve, and manage schemas with compatibility checks and subject listing.

Security

10 tools: RBAC roles and bindings, offline JWT token creation and validation.

Diagnostics

3 tools: health check, consumer lag analysis, and prioritized recommendations.

Metrics

4 tools: cluster, broker, and topic metrics via Prometheus, plus raw PromQL queries.

Logs

6 tools: broker logs, Docker container logs, and Kubernetes pod logs.

Usage Examples

Everyday Operations

You: "Show me the cluster health"
AI:  [Calls health_check, list_brokers, get_cluster_balance]
     → 3 brokers active, CV 12% (well balanced), 42 topics, no issues

You: "Create a reliable topic for payment events with 4 partitions"
AI:  [Calls create_topic with name="/default/payment-events", partitions=4, dispatch_strategy="reliable"]
     → Topic created successfully

You: "What schemas are registered?"
AI:  [Calls list_subjects]
     → 5 subjects: user-events (v3), orders (v2), payments (v1), ...

Guided Workflows

Prompts orchestrate multi-step operations with built-in safety gates:

You: "I need to rebalance the cluster"
AI:  [Loads prepare_cluster_rebalance prompt]
     Step 1: Checks Raft quorum is healthy
     Step 2: Runs health_check — all brokers active
     Step 3: Checks CV — 38% (imbalanced, proceed)
     Step 4: Dry-run — 3 topics would move, shows plan
     Step 5: "Shall I execute?" — waits for approval
     Step 6: Executes rebalance
     Step 7: Verifies CV dropped to 15%

You: "Set up security for our production cluster"
AI:  [Loads secure_cluster_setup prompt]
     Step 1: TLS certificate guidance
     Step 2: Broker configuration
     Step 3: Creates admin token (offline)
     Step 4: Creates service account tokens
     Step 5: Creates roles (producer, consumer, operator)
     Step 6: Creates bindings at correct scopes
     Step 7: Verification checklist

Guided Workflow Prompts

The 4 prompts encode domain knowledge that matters for safety and correctness:

Prompt	Arguments	What it does
`cluster_health_check`	—	Raft consensus → broker status → load balance → security audit → recommendations
`prepare_cluster_rebalance`	`max_moves`	Quorum check → health gate → CV assessment → dry-run → approval → execute → verify
`manage_schema_evolution`	`subject`, `schema_type`	Discovery → compatibility check → register → verify; encodes subject vs. topic policy rules
`secure_cluster_setup`	`environment`	TLS → JWT → roles → bindings → verify; adapts to development or production

Advanced Configuration

For log access and Prometheus metrics, create a config file:

broker_endpoint: http://localhost:50051
prometheus_url: http://localhost:9090

deployment:
  type: docker    # docker | kubernetes | local
  docker:
    container_mappings:
      - id: "broker1"
        container: "danube-broker1"
      - id: "broker2"
        container: "danube-broker2"

danube-admin serve --mode mcp --config /path/to/mcp-config.yml

Tips

Discovery first: ask the AI to check state before making changes (“What topics exist?” before deleting)
Use prompts for risky operations: rebalancing, schema evolution, and security setup have safety gates built in
Dry-run everything: rebalancing and broker unloads support dry_run: true to preview changes
Security tools work offline: create_token and validate_token don’t need a broker connection

Limitations

The MCP server can	The MCP server cannot
Read and manage cluster state (brokers, topics, schemas)	Publish or consume messages
Create and configure topics, namespaces, and schemas	Modify broker configuration files
Manage RBAC security (roles, bindings, tokens)	Access data beyond Prometheus retention
Trigger rebalancing and broker maintenance	Execute arbitrary shell commands
Access logs from Docker, Kubernetes, or local brokers	Handle TLS certificate generation