# Clanker Cloud Agent Capabilities

Canonical endpoint: https://clankercloud.ai/agent-capabilities

Use this file as the agent-facing capability map for the Clanker Cloud desktop app MCP server.

## Required Startup Order

1. Open or launch Clanker Cloud.
2. In the desktop app, choose **Settings → MCP Server → Copy Client Config** and use the whole per-launch authenticated configuration. Keep its capability out of chat, logs, tickets, source control, and shared dotfiles.
3. Call `clanker_cloud_account_status`.
4. If the user asked the agent to install or use Clanker Cloud and no account is ready, call `clanker_cloud_create_account`.
5. Call `clanker_cloud_setup_check`.
6. Use hosted Clanker Cloud LLM by default. If no provider is selected and a Clanker Cloud account token exists, the app uses `provider: "clanker-cloud"`. To make the default explicit or test it, call `clanker_cloud_configure_llm` with `provider: "clanker-cloud"` and `test: true`.
7. Install only missing local dependencies required for the user's providers, then rerun `clanker_cloud_setup_check`.
8. Call `clanker_cloud_start_scan` and wait for it to finish. Prefer `mode: "headless"` for a completed backend snapshot. Treat `clanker_cloud_startup_snapshot` as the scan fallback on older builds.
9. Only after the scan returns, use infrastructure chat, Kubernetes chat, deep research, security scanning, UI navigation, ticketing, or provider-specific tools.

## Credential Boundary

- Do not ask the user to paste cloud credentials, kubeconfigs, database credentials, provider tokens, or LLM keys into chat.
- Use saved local Clanker Cloud settings and profiles.
- Only save an API key or token through MCP when the user explicitly provides it for local saving.
- Tool results redact secret-looking values and do not expose the Clanker Cloud account token.
- Cloud provider credentials remain on the user's machine.

## Core App Tools

- `clanker_cloud_app_status`: detect whether the desktop backend and MCP endpoint are running.
- `clanker_cloud_launch_app`: launch the desktop app and optionally wait for the backend.
- `clanker_cloud_backend_status`: get backend health, API base URL, profile, and settings DB path.
- `clanker_cloud_startup_snapshot`: one-call fallback for health, resources, regional scan context, provider status, Kubernetes refs, cost, and scan/auth issues.
- `clanker_cloud_setup_check`: run the redacted setup doctor for account, provider credentials, dependencies, bundled CLI, and next actions.
- `clanker_cloud_get_settings`: read local app settings with redaction.
- `clanker_cloud_set_settings`: update local app settings.
- `clanker_cloud_call_backend_api`: call a local `/api/*` route when no higher-level tool covers the exact read.

## Account And LLM Tools

- `clanker_cloud_account_status`: check signed-in account and pending local agent-session import state.
- `clanker_cloud_create_account`: create or reuse a local-first Clanker Cloud agent account and leave the app login handoff pending locally.
- `clanker_cloud_configure_llm`: select or test the LLM provider. Defaults to hosted Clanker Cloud for agents. Supported providers are `clanker-cloud`, `openai`, `anthropic`, `gemini`, `deepseek`, `cohere`, `minimax`, `github`, `local`, and `coding-agent`.

## Scan, Research, Security, And Chat

- `clanker_cloud_start_scan`: start infrastructure discovery and wait for a completed result by default.
- `clanker_cloud_ask`: ask natural-language infrastructure questions using saved profile/model/provider settings.
- `clanker_cloud_deep_research`: run read-only estate-wide research after the scan.
- `clanker_cloud_security_scan`: run read-only exposure, auth gap, credential leak, misconfiguration, and attack-path analysis after the scan.

Agents should not run deep research, security scans, or chat before the initial scan finishes unless the scan fails with a blocker that must be reported first.

## UI Control

- `clanker_cloud_ui_targets`: list app views and command targets.
- `clanker_cloud_ui_navigate`: open app views, resource detail panels, Kubernetes panels, logs windows, deep research, security, Cerebro, settings, and related UI targets.
- `clanker_cloud_ui_command_status`: check or wait for a queued UI command.
- `clanker_cloud_ui_screenshot`: capture the running app UI for visual context.

## Kubernetes

- `clanker_cloud_k8s_inventory`: discover Kubernetes clusters and optionally include resource summaries.
- `clanker_cloud_k8s_investigate`: first-choice cluster investigation tool. Discovers/selects a cluster, reads live resources, opens the UI by default, and runs best-effort telemetry, cost, audit, and autoscaler checks.
- `clanker_cloud_k8s_get_resources`: return raw Kubernetes nodes, pods, services, PVCs, ConfigMaps, ingresses, and related payloads.
- `clanker_cloud_k8s_get_telemetry`: get cluster, node, namespace, pod, or container telemetry.
- `clanker_cloud_k8s_get_logs`: fetch logs for pod, deployment, node, namespace, cluster, or container scopes.
- `clanker_cloud_k8s_query_logs`: run a natural-language log query.
- `clanker_cloud_k8s_analyze_logs`: run the K8s log analysis stream for a failure symptom.
- `clanker_cloud_k8s_chat_logs`: chat about selected Kubernetes logs.
- `clanker_cloud_k8s_chat_cluster`: chat about cluster state.
- `clanker_cloud_k8s_workload_cost`: get per-workload cost attribution.
- `clanker_cloud_k8s_workload_audit`: get workload health audit findings.
- `clanker_cloud_k8s_karpenter_recommendations`: get Karpenter/autoscaler recommendations.

## Tickets

- `clanker_cloud_list_tickets`: list local/provider-backed tickets.
- `clanker_cloud_create_ticket`: create a ticket from findings or resources.
- `clanker_cloud_update_ticket`: update ticket status, labels, assignee, priority, or body.
- `clanker_cloud_attach_resources_to_ticket`: attach Clanker Cloud resources to a ticket.

Ticket mutations are write actions. Explain the change and get user approval first unless the user already asked for the ticket operation.

## Vercel

- `clanker_vercel_list_projects`
- `clanker_vercel_get_project`
- `clanker_vercel_list_deployments`
- `clanker_vercel_list_env_vars`
- `clanker_vercel_create_env_var`
- `clanker_vercel_delete_env_var`
- `clanker_vercel_cancel_deployment`
- `clanker_vercel_redeploy`
- `clanker_vercel_get_usage`

Environment variable creation/deletion, deployment cancellation, and redeploy are write or operational actions.

## Fly.io

- `clanker_flyio_list_apps`
- `clanker_flyio_get_app`
- `clanker_flyio_list_machines`
- `clanker_flyio_start_machine`
- `clanker_flyio_stop_machine`
- `clanker_flyio_restart_machine`
- `clanker_flyio_list_secrets`
- `clanker_flyio_create_secret`
- `clanker_flyio_list_volumes`
- `clanker_flyio_ask`

Machine lifecycle and secret creation are write or operational actions.

## Railway

- `clanker_railway_list_projects`
- `clanker_railway_get_project`
- `clanker_railway_list_deployments`
- `clanker_railway_cancel_deployment`
- `clanker_railway_redeploy_deployment`
- `clanker_railway_list_variables`
- `clanker_railway_upsert_variable`
- `clanker_railway_delete_variable`
- `clanker_railway_get_usage`

Deployment cancellation/redeploy and variable updates/deletes are write or operational actions.

## Tencent Cloud

- `clanker_tencent_inventory`
- `clanker_tencent_cost_by_product`
- `clanker_tencent_expiry`
- `clanker_tencent_security_scan`
- `clanker_tencent_security_scan_all`
- `clanker_tencent_maker_plan`

Security and inventory tools are read-only. Maker plans should remain review-before-apply.

## Verda

- `clanker_verda_verify_credentials`
- `clanker_verda_get_balance`
- `clanker_verda_list_locations`
- `clanker_verda_list_instance_types`
- `clanker_verda_list_instances`
- `clanker_verda_get_instance`
- `clanker_verda_list_clusters`
- `clanker_verda_get_cluster`

## Operating Rule

Start with the highest-level read-only tool that matches the task. Summarize the result. Drill into lower-level tools only for missing evidence. Treat write, delete, deploy, restart, secret, ticket mutation, and apply operations as user-approved actions.