kranix-mcp

MCP server — expose Kranix to Claude, GPT, and any MCP-compatible AI agent.

kranix-mcp is a Model Context Protocol (MCP) server that makes the full Kranix platform accessible to AI agents. It translates MCP tool calls into kranix-api requests, allowing agents like Claude or GPT to deploy workloads, inspect cluster state, stream logs, and analyze failures — all within safe, audited boundaries.

This is the AI-native layer of the Kranix ecosystem and its primary differentiator from conventional Kubernetes tooling.

---

What it does

• Runs an MCP-compatible server (stdio or HTTP/SSE transport)
• Exposes a curated set of Kranix operations as MCP tools
• Translates agent tool calls into authenticated kranix-api requests
• Tool chaining — compose multiple tools into a single logical operation (chain_tools)
• Context-aware suggestions — recommends next actions based on cluster state and session history
• Agent impersonation guard — binds authenticated agent identity; rejects spoofed agent_id claims
• Workload rollback — revert deployments to any previous revision (rollback_workload)
• Cost estimation — estimate deployment cost before applying changes (estimate_deployment_cost)
• Real-time event subscription — poll cluster SSE events for push-style notifications (subscribe_cluster_events)
• Approval gate — require human confirmation before destructive actions (request_approval, resolve_approval)
• KranixApp template generation — generate full kranix.io/v1alpha1 manifests from descriptions (generate_kranixapp_template)
• MCP tool versioning — expose v1 and v2 tools side by side with version metadata in tools/list
• Namespace scoping — restrict agents to specific namespaces with enforced validation
• Enforces safety boundaries — agents can observe and act, but cannot delete namespaces or modify cluster RBAC
• Emits structured audit logs for every agent action

---

Architecture position

AI agents (Claude, GPT, custom)
           │
     MCP protocol
           │
       kranix-mcp
           │
       kranix-api  ──►  kranix-core

kranix-mcp has no direct knowledge of Docker or Kubernetes. It only speaks to kranix-api.

---

Exposed MCP tools

These are the tools AI agents can call:

Tool	Description
deploy_workload	Deploy an application from an image or manifest
list_workloads	List all running workloads in a namespace
get_workload	Get the spec and status of a workload
restart_workload	Restart a workload
rollback_workload	Revert a workload to a previous revision (defaults to prior version)
list_workload_revisions	List available rollback revisions for a workload
delete_workload	Remove a workload (requires explicit confirmation flag)
list_pods	List pods for a given workload
stream_logs	Stream logs from a pod (returns last N lines)
create_namespace	Create a new namespace
list_namespaces	List all available namespaces
analyze_workload	Run AI-powered failure analysis on a workload
generate_manifest	Generate a Kubernetes manifest from plain text (v1, deprecated)
generate_kranixapp_template	Generate a full KranixApp manifest from a description (v1)
generate_kranixapp_template_v2	Generate KranixApp with explicit fields, profiles, and feature flags (v2)
deploy_workload_v2	Deploy with extended spec — resources, tags, optional manifest (v2)
get_cluster_health	Summary of overall cluster health
chain_tools	Compose multiple MCP tools into one sequential operation
suggest_actions	Get context-aware recommendations for the next tool to call
estimate_deployment_cost	Estimate monthly cost for a proposed deployment before applying
subscribe_cluster_events	Collect real-time cluster events from kranix-api SSE (workload changes, deletions)
request_approval	Request human confirmation before a destructive tool call
check_approval	Check status of a pending or resolved approval gate
list_pending_approvals	List approvals awaiting operator action
resolve_approval	Approve or deny a pending gate (human operator)
natural_language_deploy	Deploy using natural language (e.g., "deploy api-server v2 to prod with 5 replicas")
get_healing_status	Get autonomous healing mode status
get_healing_history	Get history of autonomous healing actions
reset_healing_count	Reset restart count for a workload
Multi-Agent Coordination
create_task	Create a new task for multi-agent coordination
delegate_task	Delegate a task to another agent
get_task	Get details of a specific task
list_tasks	List all tasks, optionally filtered by agent or status
update_task_status	Update the status of a task
create_subtask	Create a sub-task for a parent task
claim_task	Claim a pending task for the current agent
Dry-Run Mode
set_dryrun_mode	Set the dry-run mode (disabled, preview, log)
get_dryrun_mode	Get the current dry-run mode
get_dryrun_preview	Get a preview of actions that would be executed in dry-run mode
clear_dryrun_actions	Clear all recorded dry-run actions
Incident Response
list_runbooks	List all available incident response runbooks
get_runbook	Get details of a specific runbook
execute_runbook	Execute an incident response runbook
get_execution	Get details of a runbook execution
list_executions	List all runbook executions, optionally filtered by runbook or status
cancel_execution	Cancel a running runbook execution
create_runbook	Create a new incident response runbook
Agent Session Memory
set_memory_context	Store context data in the agent's session memory
get_memory_context	Retrieve context data from the agent's session memory
get_all_memory_context	Retrieve all context data from the agent's session memory
get_session_history	Get the tool call history for the agent's session
clear_session_history	Clear the tool call history for the agent's session
Per-Agent Audit Log
get_agent_audit_log	Retrieve audit log entries for a specific agent
get_agent_summary	Get a summary of agent activity including total calls, success rate, tools used
list_all_agents	List all unique agent IDs that have performed actions
export_audit_log	Export audit log as JSON for a specific agent or all agents
Scheduled Agent Tasks
create_scheduled_task	Create a new scheduled task to run on a cron schedule
list_scheduled_tasks	List all scheduled tasks
get_scheduled_task	Get details of a specific scheduled task
update_scheduled_task	Update an existing scheduled task
delete_scheduled_task	Delete a scheduled task
enable_scheduled_task	Enable a scheduled task
disable_scheduled_task	Disable a scheduled task
get_task_results	Get execution results for a scheduled task
get_scheduler_stats	Get scheduler statistics including total tasks, executions, etc.

Tool schema example

{
  "name": "deploy_workload",
  "description": "Deploy an application workload to a namespace",
  "inputSchema": {
    "type": "object",
    "required": ["name", "image", "namespace"],
    "properties": {
      "name":      { "type": "string", "description": "Workload name" },
      "image":     { "type": "string", "description": "Container image (e.g. nginx:latest)" },
      "namespace": { "type": "string", "description": "Target namespace" },
      "replicas":  { "type": "integer", "default": 1 },
      "env":       { "type": "object", "description": "Environment variables" }
    }
  }
}

---

Safety boundaries

Not everything is exposed. By design, agents cannot:

• Delete or modify namespaces (read-only)
• Modify cluster RBAC or service accounts
• Exec into running containers
• Access secrets directly
• Perform bulk deletes

New Features

Autonomous Healing Mode

The autonomous healing mode continuously monitors cluster health and automatically fixes issues without being prompted. It can:

• Detect failing workloads and pods
• Automatically restart crashed services
• Scale up workloads experiencing crash loop backoff
• Track restart counts to prevent restart loops
• Operate in three modes: disabled, observe, or auto

Configuration:

healing:
  enabled: true
  mode: "observe"           # disabled | observe | auto
  check_interval: 30s
  max_restarts_per_hour: 10
  restart_cooldown: 5m
  auto_scale_enabled: true
  min_replicas: 1
  max_replicas: 10
  namespaces: []            # Empty means all namespaces

Tools:

• get_healing_status - Check current healing mode status
• get_healing_history - View history of healing actions
• reset_healing_count - Reset restart counter after fixing issues

Natural Language Deploys

Deploy workloads using plain English commands. The NLP parser understands commands like:

• "deploy api-server v2 to prod with 5 replicas"
• "launch nginx:latest to staging with env PORT=8080"
• "scale workload frontend to 10 replicas in production"

Usage:

{
  "command": "deploy api-server v2 to prod with 5 replicas",
  "execute": false  // Set to true to actually deploy
}

Tools:

• natural_language_deploy - Parse and execute natural language deployment commands

Multi-Agent Coordination

The multi-agent coordination system enables agents to delegate sub-tasks to other agents, enabling complex workflows and parallel execution:

Features:

• Task Creation: Agents can create tasks with priorities, descriptions, and assign them to specific agents
• Task Delegation: Reassign tasks between agents as needed
• Sub-task Support: Break down complex tasks into hierarchical sub-tasks
• Task Claiming: Agents can claim pending tasks from a shared queue
• Status Tracking: Real-time task status updates (pending, in_progress, completed, failed)

Usage Example:

{
  "title": "Deploy database migration",
  "description": "Run database schema migration for new feature",
  "assigned_to": "database-agent",
  "priority": "high",
  "inputs": {
    "migration_script": "migrations/v2_add_users.sql"
  }
}

Configuration:

coordination:
  enabled: true
  max_concurrent_tasks: 10
  task_timeout: 30m

Dry-Run Mode

Dry-run mode allows agents to preview exactly what would happen before executing actions, providing safety and predictability:

Modes:

• disabled: Execute actions normally (default)
• preview: Record and preview actions without executing them
• log: Execute actions while logging all operations for audit

Features:

• Predictive output for common operations
• Human-readable preview of planned actions
• Action history and clearing
• Per-tool prediction functions

Usage:

{
  "mode": "preview"
}

Then execute tools normally and call get_dryrun_preview to see what would happen.

Configuration:

dryrun:
  enabled: true
  mode: "disabled"  # disabled | preview | log
  max_actions: 100

Incident Response Tool

The incident response tool enables agents to read and execute runbooks for automated on-call responses:

Features:

• Runbook Management: Load runbooks from JSON files in a configured directory
• Step Execution: Execute sequential steps with configurable failure handling
• Context Injection: Pass runtime context to runbook steps
• Execution Tracking: Monitor runbook execution status and results
• Cancellation Support: Cancel running runbook executions

Runbook Structure:

{
  "name": "Database Service Restart",
  "category": "database",
  "severity": "high",
  "steps": [
    {
      "name": "Check Database Status",
      "tool": "get_workload",
      "inputs": {
        "name": "{{database_name}}",
        "namespace": "{{namespace}}"
      },
      "on_failure": "stop"
    },
    {
      "name": "Restart Database",
      "tool": "restart_workload",
      "inputs": {
        "name": "{{database_name}}",
        "namespace": "{{namespace}}"
      },
      "on_failure": "stop"
    }
  ]
}

Configuration:

incident:
  enabled: true
  runbook_path: "./runbooks"
  auto_load: true
  default_timeout: 5m

Sample Runbooks:

• database-restart.json: Automated database service recovery
• pod-crashloop-recovery.json: Handle CrashLoopBackoff scenarios
• cluster-health-check.json: Comprehensive cluster diagnostics

Agent Permission Scopes

Fine-grained access control per agent identity with three scopes:

• readonly - Can only read cluster state (list, get, analyze)
• write - Can deploy, restart, create namespaces (cannot delete)
• admin - Full access including delete operations

Configuration:

safety:
  default_scope: "write"     # Default scope for unknown agents
  agents:
    claude-desktop:
      scope: "write"
      api_key: ""            # optional: bind this agent to a specific API key
      namespaces: []         # Empty means all namespaces
      allowed_tools: []      # Empty means all tools based on scope
    production-bot:
      scope: "admin"
      namespaces: ["production", "staging"]
    read-only-agent:
      scope: "readonly"

Namespace Scoping:

Agents can be restricted to specific namespaces via safety.agents.<id>.namespaces. When a list is configured, enforcement applies to all namespace-bound tools:

• Required namespace — scoped agents must supply namespace on tools like deploy_workload, list_workloads, rollback_workload, and estimate_deployment_cost
• Auto-injection — if an agent has exactly one allowed namespace and omits namespace, it is injected automatically
• Filtered listing — list_namespaces returns only allowed namespaces for scoped agents
• Denied access — operations targeting a namespace outside the allowlist are rejected with a clear error

safety:
  agents:
    staging-bot:
      scope: "write"
      namespaces: ["staging"]       # only staging — namespace required on mutating tools
    production-bot:
      scope: "admin"
      namespaces: ["production", "staging"]
    platform-reader:
      scope: "readonly"
      namespaces: []                # empty = all namespaces (read-only)

Real-time event subscription

Agents can receive cluster push notifications by calling subscribe_cluster_events. The tool opens a short-lived connection to kranix-api's GET /api/sse endpoint and returns a batch of events collected during the poll window.

Event types: workload.changed, workload.created, workload.deleted (and custom broadcasts)

Example flow:

1. Agent calls subscribe_cluster_events with namespaces: ["production"], timeout_seconds: 30
2. Another agent or operator deploys a workload → kranix-api broadcasts via SSE
3. The subscription returns matching events in a ClusterEventBatch

{
  "namespaces": ["staging"],
  "event_types": ["workload.changed"],
  "timeout_seconds": 15,
  "max_events": 20
}

Approval gate

Destructive tools (delete_workload, rollback_workload, execute_runbook, cancel_execution, create_runbook) require explicit confirmation before execution:

1. Human approval flow — call request_approval with the target tool and inputs → operator calls resolve_approval → agent retries the tool with approval_id
2. Direct confirm — pass confirm: true for simple cases (e.g. delete_workload)

approval:
  enabled: true   # validate approval_id against kranix-api when set

When dry-run mode is preview, mutating tools record planned actions without executing (see Dry-Run Mode below).

KranixApp template generation

Agents can generate production-ready KranixApp CRD manifests (apiVersion: kranix.io/v1alpha1) from natural language:

{
  "description": "deploy payments-api v3 to production with 3 replicas, critical priority, and spot instances"
}

The v2 tool adds explicit overrides:

{
  "description": "payments API for checkout",
  "name": "payments-api",
  "namespace": "payments",
  "profile": "production",
  "features": ["spot", "cross-namespace-traffic"],
  "cpu": "500m",
  "memory": "1Gi"
}

Profiles: basic, production, spot, cron
Features: spot, critical, cross-namespace-traffic, circuit-breaker, warm-standby, auto-heal

MCP tool versioning

Tools are versioned with a _v2 suffix for extended schemas. Both versions are exposed simultaneously so existing agents keep working:

tools:
  versioning:
    enabled: true
    default_version: v1
    expose_versions: [v1, v2]

tools/list returns version metadata per tool:

{
  "name": "deploy_workload_v2",
  "version": "v2",
  "description": "Deploy a workload with extended spec...",
  "deprecated": false,
  "replacedBy": ""
}

v1 tools inherit safety permissions for their v2 counterparts. Agents with allowed_tools: ["deploy_workload"] may also call deploy_workload_v2.

Agent Session Memory

The session memory feature maintains context across multiple tool calls for each agent, enabling more sophisticated multi-step workflows:

Features:

• Context Storage: Store and retrieve key-value data across tool calls
• Session History: Track all tool calls made by an agent in the current session
• Automatic Cleanup: Expired sessions are automatically cleaned up based on TTL
• Per-Agent Isolation: Each agent has its own isolated memory space

Usage:

{
  "key": "current_namespace",
  "value": "production"
}

Configuration:

memory:
  enabled: true
  max_entries: 100              # Max history entries per session
  ttl: 30m                      # Session time-to-live
  cleanup_interval: 10m         # Cleanup interval for expired sessions

Tools:

• set_memory_context - Store context data
• get_memory_context - Retrieve specific context data
• get_all_memory_context - Retrieve all context data
• get_session_history - Get tool call history
• clear_session_history - Clear session history

Per-Agent Audit Log

Enhanced audit logging provides detailed per-agent tracking of all actions:

Features:

• Agent-Specific Queries: Query audit logs by agent ID
• Activity Summaries: Get summaries including total calls, success rate, tools used
• Flexible Filtering: Filter by tool name, outcome, time range
• Export Capabilities: Export audit logs as JSON
• In-Memory Storage: Fast in-memory storage with configurable limits

Usage:

{
  "agent_id": "claude-desktop",
  "limit": 50
}

Configuration:

audit:
  enabled: true
  sink: memory                  # stdout | file | memory | all

Tools:

• get_agent_audit_log - Retrieve audit log entries for a specific agent
• get_agent_summary - Get agent activity summary
• list_all_agents - List all unique agent IDs
• export_audit_log - Export audit log as JSON

Scheduled Agent Tasks

The scheduler enables agents to create and manage cron-based scheduled tasks:

Features:

• Cron Scheduling: Schedule tasks using cron expressions
• Task Management: Create, update, delete, enable, and disable tasks
• Execution Tracking: Track task execution results and history
• Tool Integration: Execute any available MCP tool on a schedule
• Statistics: Get scheduler statistics and task metrics

Usage:

{
  "id": "health-check-hourly",
  "name": "Hourly Health Check",
  "cron_expr": "0 * * * *",
  "tool_name": "get_cluster_health",
  "enabled": true
}

Configuration:

scheduler:
  enabled: true
  check_interval: 1m            # How often to check for due tasks
  max_results: 1000             # Max execution results to store

Tools:

• create_scheduled_task - Create a new scheduled task
• list_scheduled_tasks - List all scheduled tasks
• get_scheduled_task - Get details of a specific task
• update_scheduled_task - Update an existing task
• delete_scheduled_task - Delete a scheduled task
• enable_scheduled_task - Enable a scheduled task
• disable_scheduled_task - Disable a scheduled task
• get_task_results - Get execution results for a task
• get_scheduler_stats - Get scheduler statistics

Tool Chaining

Compose multiple MCP tools into a single logical operation. Each step runs through the full registry pipeline (safety, audit, session memory) — the same path as individual tool calls and runbook execution.

Features:

• Sequential execution with shared context merged into step inputs
• Template substitution — use {{variable}} placeholders in step inputs (also supported in runbook steps)
• Per-step failure handling — stop (default) or continue
• Step output capture — prior step outputs are available as {{tool_name_output}} or {{step_id_output}}

Usage:

{
  "name": "diagnose-and-recover",
  "steps": [
    {
      "tool": "analyze_workload",
      "inputs": { "name": "api", "namespace": "prod" }
    },
    {
      "tool": "list_pods",
      "inputs": { "workload": "api", "namespace": "prod" },
      "on_failure": "continue"
    },
    {
      "tool": "restart_workload",
      "inputs": { "name": "api", "namespace": "prod" }
    }
  ],
  "on_failure": "stop"
}

Tool: chain_tools

Runbooks and scheduled tasks also execute tools through the registry pipeline, so chained runbook steps inherit the same safety and audit guarantees.

Context-Aware Suggestions

The MCP server recommends next actions based on live cluster state, workload status, and the agent's session history.

Features:

• Cluster health signals — degraded or critical clusters trigger inspection and recovery suggestions
• Session-aware hints — follows up on recent tool calls (e.g., suggest analyze_workload after get_workload)
• Auto-append mode — optionally append up to three suggestions to every tool response
• API-backed — uses GET /api/v1/cluster/suggestions from kranix-api when available

Usage:

{
  "namespace": "prod",
  "workload": "api"
}

Configuration:

suggestions:
  auto_append: true   # append suggestion hints to tool responses

Tools:

• suggest_actions — explicit query for next-action recommendations
• get_cluster_health — underlying cluster health signal

When auto_append is enabled, tool responses include a --- Suggested next actions --- section with prioritized hints.

Agent Impersonation Guard

Prevents agents from acting as other agents by binding a verified identity to every tool call.

How identity is resolved:

Transport	Source
stdio	KRANE_AGENT_ID env var, or API key → agent binding in config
HTTP	X-Agent-Id header, validated against config

Enforcement:

• CallTool uses CheckPermissionWithContext with the authenticated agent ID
• Tools that accept agent_id in inputs (claim_task, execute_runbook, audit queries) reject mismatched claims
• Admin-scoped agents may read other agents' audit logs but cannot perform mutating actions on their behalf
• MCP client propagates X-Agent-Id and X-Actor headers to kranix-api for consistent audit trails

Configuration:

agent:
  default_agent_id: "claude-desktop"   # fallback for stdio when KRANE_AGENT_ID is unset

safety:
  agents:
    claude-desktop:
      scope: "write"
      api_key: ""                    # optional: bind KRANE_API_KEY to this agent
      namespaces: []
      allowed_tools: []
    production-bot:
      scope: "admin"
      namespaces: ["production", "staging"]

Environment:

export KRANE_AGENT_ID=claude-desktop
export KRANE_API_KEY=krane_your_key_here

Shared contract types live in kranix-packages/auth (AgentIdentity, ValidateAgentClaim).

Workload Rollback

Revert a workload to any previous revision stored by kranix-core's rollout history.

Features:

• Previous version default — omit revision_id to roll back to the immediately prior revision
• Revision inspection — use list_workload_revisions before choosing a target
• Audit trail — rollback actions are logged and propagated to kranix-api as workload.rollback
• Suggestion integration — degraded workloads may suggest rollback_workload via suggest_actions

Usage:

{
  "name": "api",
  "namespace": "production",
  "revision_id": "a1b2c3d4"
}

Omit revision_id to revert to the previous version:

{
  "name": "api",
  "namespace": "production"
}

Tools:

• rollback_workload — revert to a specific or previous revision (write scope)
• list_workload_revisions — list stored revisions (read-only)

Requirements: kranix-core with rollback_history.enabled: true and at least one prior revision on the workload.

Cost Estimation

Estimate deployment cost before applying changes — useful when an agent needs to answer "how much will this deployment cost?"

Features:

• Pre-deploy estimates — no running workload required; accepts proposed image, replicas, and resource limits
• Shared estimator — uses kranix-packages/cost (same model as kranix-api and mock-api)
• Rightsizing hints — includes recommended CPU request/limit when utilization is low
• Duration windows — estimate for 30d (default), 7d, etc.
• Read-only tool — safe for readonly-scoped agents; still respects namespace scoping

Usage:

{
  "name": "api",
  "image": "nginx:latest",
  "namespace": "staging",
  "replicas": 3,
  "cpu_request": "100m",
  "cpu_limit": "500m",
  "memory_limit": "512Mi",
  "duration": "30d"
}

Example response fields: totalCost, computeCost, monthlyCostPerReplica, rightsizing.recommendedCpuRequest, breakdown[]

Tool: estimate_deployment_cost

API: POST /api/v1/cost/estimate on kranix-api

---

Audit logging

All agent actions are logged with the agent identity, tool name, inputs, and outcome.

---

Project structure

kranix-mcp/
├── cmd/
│   └── mcp/              # Entry point
├── internal/
│   ├── server/           # MCP server (stdio, HTTP/SSE)
│   ├── tools/            # MCP tool registry and handlers
│   ├── client/           # kranix-api HTTP client
│   ├── agent/            # Agent identity resolution and impersonation guard
│   ├── chaining/         # Tool chain execution engine
│   ├── suggestions/      # Context-aware next-action recommendations
│   ├── safety/           # Permission scopes and namespace guards (namespace.go)
│   ├── incident/         # Runbook management and execution
│   └── ...
├── config/
│   └── config.yaml
├── schemas/              # JSON schema docs for MCP tools
└── runbooks/             # Sample incident response runbooks

---

Getting started

Prerequisites

• Go 1.22+
• A running kranix-api instance

---

Integration with Kranix Ecosystem

Kranix-Core Integration

The autonomous healing mode integrates with kranix-core's existing features:

• Drift Detection: Healing actions are logged as events in kranix-core's event sourcing system
• Health Gates: Healing checks respect workload health gate configurations
• Failure Prediction: Uses kranix-core's ML-based failure prediction when available

Kranix-API Integration

Agent permission scopes and identity propagation align with kranix-api's authentication system:

• Agent identities are bound to API keys or KRANE_AGENT_ID / X-Agent-Id
• Permission checks are enforced at both the MCP layer and API layer
• MCP client sends X-Agent-Id and X-Actor on every API request
• Audit logs are consistent across both systems for complete traceability
• Cluster health and suggestions are served by GET /api/v1/cluster/health and GET /api/v1/cluster/suggestions

Run locally (stdio transport)

git clone https://github.com/kranix-io/kranix-mcp
cd kranix-mcp
go mod download

KRANE_API_URL=http://localhost:8080 \
KRANE_API_KEY=krane_your_key_here \
KRANE_AGENT_ID=claude-desktop \
go run ./cmd/mcp

Run as HTTP/SSE server

KRANE_MCP_TRANSPORT=http \
KRANE_MCP_PORT=3100 \
KRANE_AGENT_ID=claude-desktop \
go run ./cmd/mcp

---

Connecting to Claude

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "kranix": {
      "command": "go",
      "args": ["run", "/path/to/kranix-mcp/cmd/mcp"],
      "env": {
        "KRANE_API_URL": "http://localhost:8080",
        "KRANE_API_KEY": "krane_your_key_here",
        "KRANE_AGENT_ID": "claude-desktop"
      }
    }
  }
}

Claude API (HTTP/SSE)

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    tools=[],   # tools are discovered from the MCP server
    mcp_servers=[
        {
            "type": "url",
            "url": "http://localhost:3100/sse",
            "name": "kranix"
        }
    ],
    messages=[
        {"role": "user", "content": "Deploy nginx:latest to the staging namespace"}
    ]
)

---

Configuration

mcp:
  transport: stdio          # stdio | http
  port: 3100                # only used if transport: http

krane_api:
  url: "http://localhost:8080"
  api_key: ""               # or set KRANE_API_KEY env var
  timeout: 30s

safety:
  allow_delete_workload: true
  allow_create_namespace: true
  readonly_mode: false       # set true to allow only read tools
  default_scope: "write"
  agents:
    claude-desktop:
      scope: "write"
      api_key: ""            # optional API key binding
      namespaces: []
      allowed_tools: []

suggestions:
  auto_append: true          # append next-action hints to tool responses

agent:
  default_agent_id: "claude-desktop"   # or KRANE_AGENT_ID env var

audit:
  enabled: true
  sink: stdout

---

Connectivity

Repo	Relationship
kranix-api	All tool calls translate into kranix-api HTTP requests; rollback, cost estimate, cluster health, and suggestions endpoints
kranix-packages	Shared MCP types, agent auth, cost estimator (cost/estimate.go), rollback types
AI agents	Consumed via MCP protocol (stdio or HTTP/SSE)

---

Contributing

See CONTRIBUTING.md. Adding a new tool requires: tool definition, JSON schema, implementation, safety classification, and integration test with a mock kranix-api.

License

Apache 2.0 — see LICENSE.