What can you do with this server?

The Rancher MCP Server is a Model Context Protocol server that provides AI assistants with tools to manage Rancher ecosystem components including Harvester HCI, Kubernetes clusters, Helm releases, and Fleet GitOps deployments. Harvester Management * List, get, create, update, and delete VMs; perform actions like start/stop/restart * Manage VM snapshots, backups, and images (create from URLs) * List and create PersistentVolumeClaims (Longhorn-backed volumes) * Manage VM networks (NetworkAttachmentDefinition), KubeOVN VPCs and subnets * List hosts/nodes and manage maintenance mode * List/get cluster settings (e.g. backup-target) and addons (enable/disable) Rancher Management * List clusters and projects with detailed info (health, version, node count) * Get an overview of cluster and project counts Kubernetes Operations * List, get, describe, create, patch, and delete resources by apiVersion/kind * Get pod logs, list namespace events, and view node capacity/allocatable resources Helm Management * List, get, and view history of Helm releases * Install, upgrade, rollback, and uninstall Helm charts * List configured chart repositories Fleet GitOps Control * List, get, create, delete, and clone Fleet GitRepos * Perform actions on GitRepos (pause, unpause, force update, toggle polling) * List Fleet Bundles and clusters; detect drift in BundleDeployments Security & Configuration * Defaults to read-only mode; write and destructive operations must be explicitly enabled * Sensitive data masking * Configurable via CLI flags, environment variables, or YAML/TOML config files * Supports stdio and Streamable HTTP transports * Cross-platform (macOS, Linux, Windows); single Rancher token enables multi-cluster access

Which integrations are available for this server?

Allows managing Helm releases, including listing, installing, upgrading, rolling back, and uninstalling charts, as well as managing Helm repositories across clusters. Provides tools to list, get, create, patch, and delete Kubernetes resources, view resource descriptions and events, and monitor cluster capacity. Enables multi-cluster management through Rancher, providing capabilities to list clusters and projects, retrieve cluster details, and access management API overviews.

de en es ja ko ru zh

Rancher MCP Server

by mrostamii

Overview Schema Related Servers Score Discussions

Remote

rancher-mcp-server

GitHub License npm GitHub release (latest SemVer) Build MCP Badge

rancher-mcp-server banner

Model Context Protocol (MCP) server for the Rancher ecosystem: multi-cluster Kubernetes, Harvester HCI (VMs, storage, networks), and Fleet GitOps.

Demo

A walkthrough of how this MCP server works (example in Cursor).

https://github.com/user-attachments/assets/7d8fb814-e504-47b4-956d-28f43aeea3b8

Features

Harvester toolset: List/get VMs, images, volumes, networks, hosts; VM actions; addon list/switch (enable/disable)
Rancher toolset: Clusters and projects via Steve (management proxy); Norman management API (/v3) for schemas, users, tokens, auth configs, global role bindings, cluster registration tokens, node drivers, cloud credentials, catalogs, cluster repos, feature flags, settings, audit (when exposed); support bundle and generic actions when writes are enabled
Kubernetes toolset: List/get/create/patch/delete resources by apiVersion/kind; describe (resource + events), events, capacity
Helm toolset: List/get/history of releases; install, upgrade, rollback, uninstall; repo list
Fleet toolset: GitRepo list/get/create; Bundle list; Fleet cluster list; drift detection
Rancher APIs: Same Bearer token for Steve (/k8s/clusters/...) and Norman (/v3/...); no CLI wrappers
Security: Read-only default, disable-destructive, sensitive data masking (Norman token/credential fields redacted unless --show-sensitive-data)
Config: Flags, env (RANCHER_MCP_*), or file (YAML/TOML)

Related MCP server: OpsLevel MCP

Quick start

Install

npm install -g rancher-mcp-server

Cursor

Add to .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "rancher": {
      "command": "npx",
      "args": [
        "-y", "rancher-mcp-server",
        "--rancher-server-url", "https://rancher.example.com",
        "--rancher-token", "token-xxxxx:yyyy",
        "--toolsets", "harvester,rancher,kubernetes,fleet"
      ]
    }
  }
}

Restart Cursor after saving. Check Settings → Tools & MCP that rancher is listed and enabled.

Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "rancher": {
      "command": "npx",
      "args": [
        "-y", "rancher-mcp-server",
        "--rancher-server-url", "https://rancher.example.com",
        "--rancher-token", "token-xxxxx:yyyy",
        "--toolsets", "harvester,rancher,kubernetes,fleet"
      ]
    }
  }
}

With env vars instead of args

If you prefer to keep the token out of the JSON config:

{
  "mcpServers": {
    "rancher": {
      "command": "npx",
      "args": ["-y", "rancher-mcp-server"],
      "env": {
        "RANCHER_MCP_RANCHER_SERVER_URL": "https://rancher.example.com",
        "RANCHER_MCP_RANCHER_TOKEN": "token-xxxxx:yyyy",
        "RANCHER_MCP_TOOLSETS": "harvester,rancher,kubernetes"
      }
    }
  }
}

Enable write operations

For VM create, snapshots, backups, image/volume create, addon switch, host maintenance mode, VPC create/update/delete, Kubernetes create/patch/delete, Helm install/upgrade/rollback, Fleet gitrepo create/delete, and Norman writes (tokens, users, auth configs, role bindings, cluster registration tokens, cloud credentials, catalog refresh, feature flags, settings, rancher_norman_action, support bundle), add --read-only=false. Delete operations (Norman tokens/bindings/registration tokens/cloud credentials, plus existing toolset deletes) also require --disable-destructive=false (default).

{
  "mcpServers": {
    "rancher": {
      "command": "npx",
      "args": [
        "-y", "rancher-mcp-server",
        "--rancher-server-url", "https://rancher.example.com",
        "--rancher-token", "token-xxxxx:yyyy",
        "--toolsets", "harvester,rancher,kubernetes,helm,fleet",
        "--read-only=false"
      ]
    }
  }
}

Streamable HTTP transport

For web clients or remote access (e.g. Claude Code claude mcp add -t http), add --transport and --port:

{
  "mcpServers": {
    "rancher": {
      "command": "npx",
      "args": [
        "-y", "rancher-mcp-server",
        "--rancher-server-url", "https://rancher.example.com",
        "--rancher-token", "token-xxxxx:yyyy",
        "--transport", "http",
        "--port", "8080"
      ]
    }
  }
}

The server uses the MCP Streamable HTTP transport. The default MCP path is /mcp; connect to http://localhost:8080/mcp (or your server base URL + /mcp). Best supported with Claude Code; Cursor support may vary.

Build from source

If you prefer to build the Go binary yourself:

go build -o rancher-mcp-server ./cmd/rancher-mcp-server

Then reference the binary directly in your MCP config:

{
  "mcpServers": {
    "rancher": {
      "command": "/absolute/path/to/rancher-mcp-server",
      "args": [
        "--rancher-server-url", "https://rancher.example.com",
        "--rancher-token", "token-xxxxx:yyyy",
        "--toolsets", "harvester,rancher,kubernetes,fleet"
      ]
    }
  }
}

Configuration

Option	Env	Default	Description
`--rancher-server-url`	`RANCHER_MCP_RANCHER_SERVER_URL`	—	Rancher server URL (required)
`--rancher-token`	`RANCHER_MCP_RANCHER_TOKEN`	—	Bearer token (required)
`--tls-insecure`	`RANCHER_MCP_TLS_INSECURE`	false	Skip TLS verification
`--read-only`	`RANCHER_MCP_READ_ONLY`	true	Disable write operations
`--disable-destructive`	`RANCHER_MCP_DISABLE_DESTRUCTIVE`	false	Disable delete operations
`--show-sensitive-data`	`RANCHER_MCP_SHOW_SENSITIVE_DATA`	false	Show Norman token/credential fields without redaction (use with care)
`--toolsets`	`RANCHER_MCP_TOOLSETS`	harvester	Toolsets to enable: harvester, rancher, kubernetes, helm, fleet
`--transport`	`RANCHER_MCP_TRANSPORT`	stdio	Transport: stdio or http (Streamable HTTP; default path `/mcp`)
`--port`	`RANCHER_MCP_PORT`	0	Port for HTTP (0 = stdio only)

Harvester tools

Tool	Description
`harvester_vm_list`	List VMs with status, namespace, spec/status
`harvester_vm_get`	Get one VM (full spec and status)
`harvester_vm_action`	start, stop, restart, pause, unpause, migrate
`harvester_vm_create`	Create VM (when not read-only). Supports network, interface_type (managedtap/bridge/masquerade), subnet for KubeOVN VPC.
`harvester_vm_snapshot`	Create/list/restore/delete VM snapshots
`harvester_vm_backup`	Create/list/restore VM backups (Backup Target)
`harvester_image_list`	List VM images (VirtualMachineImage)
`harvester_image_create`	Create VM image from URL (when not read-only)
`harvester_volume_list`	List PVCs (Longhorn-backed volumes)
`harvester_volume_create`	Create volume/PVC (optionally from image)
`harvester_network_list`	List VM networks (NetworkAttachmentDefinition)
`harvester_network_create`	Create VM network - KubeOVN overlay or VLAN (when not read-only)
`harvester_network_update`	Update VM network config (when not read-only)
`harvester_network_delete`	Delete VM network (when destructive allowed)
`harvester_subnet_list`	List KubeOVN Subnets (requires kubeovn-operator)
`harvester_subnet_create`	Create Subnet in VPC for VM network (when not read-only)
`harvester_subnet_update`	Update Subnet namespaces/NAT (when not read-only)
`harvester_subnet_delete`	Delete Subnet (when destructive allowed)
`harvester_host_list`	List nodes (Harvester hosts)
`harvester_host_action`	Enable/disable maintenance mode on a host (cordon/uncordon)
`harvester_settings`	List or get Harvester cluster settings (backup-target, etc.)
`harvester_addon_list`	List Harvester addons (enabled/disabled state)
`harvester_addon_switch`	Enable or disable an addon (when not read-only)
`harvester_vpc_list`	List KubeOVN VPCs (requires kubeovn-operator addon)
`harvester_vpc_create`	Create a KubeOVN VPC (when not read-only)
`harvester_vpc_update`	Update a KubeOVN VPC namespaces (when not read-only)
`harvester_vpc_delete`	Delete a KubeOVN VPC (when destructive allowed)

List tools accept cluster (required), namespace, format (json|table), limit (default 100), continue (pagination token for next page). Write tools require read_only: false.

Creating a VM on KubeOVN VPC with external internet

Use harvester_vm_create with:

network: Name of the overlay network (NAD) linked to a KubeOVN subnet. Create via harvester_network_create (type=kubeovn) then harvester_subnet_create with provider={network}.{namespace}.ovn, vpc=<vpc-name>, and nat_outgoing=true.
interface_type: managedtap (recommended for KubeOVN) or bridge. Uses Multus as primary network.
subnet: Optional KubeOVN subnet name for ovn.kubernetes.io/logical_switch annotation.

Example: VM on network vswitch1 in namespace default, managedTap interface, subnet vswitch1-subnet:

harvester_vm_create cluster=<cluster-id> namespace=default name=testvm image=<image> network=vswitch1 interface_type=managedtap subnet=vswitch1-subnet

Rancher tools

Rancher tools use the management cluster (local). There is no cluster parameter on these tools.

Steve API (management resources)

Tool	Description
`rancher_cluster_list`	List Rancher clusters (management)
`rancher_cluster_get`	Get one cluster (health, version, node count)
`rancher_project_list`	List Rancher projects
`rancher_overview`	Overview: cluster count and project count

Norman API (`https://<rancher>/v3/...`)

Norman tools call Rancher’s JSON management API. Discover types and collection URLs for your server with rancher_norman_schema_list / rancher_norman_schema_get (schema ids such as user, token, cluster).

Read-only (always registered with the rancher toolset)

Tool	Description
`rancher_norman_schema_list`	List API schemas (`/v3/schemas`)
`rancher_norman_schema_get`	Get one schema by id
`rancher_user_list` / `rancher_user_get`	Users
`rancher_auth_config_list` / `rancher_auth_config_get`	Auth providers (local, OIDC, etc.)
`rancher_token_list` / `rancher_token_get`	API tokens (values redacted unless `--show-sensitive-data`)
`rancher_global_role_binding_list` / `rancher_global_role_binding_get`	Global role bindings
`rancher_cluster_registration_token_list` / `rancher_cluster_registration_token_get`	Cluster registration tokens
`rancher_node_driver_list`	Node drivers
`rancher_cloud_credential_list` / `rancher_cloud_credential_get`	Cloud credentials (secrets redacted unless `--show-sensitive-data`)
`rancher_catalog_list` / `rancher_catalog_get`	Legacy Norman catalogs (`/v3/catalogs`)
`rancher_cluster_repo_list` / `rancher_cluster_repo_get`	App catalog cluster repos (see note below)
`rancher_feature_flag_list` / `rancher_feature_flag_get`	Feature flags (`/v3/features`)
`rancher_setting_list` / `rancher_setting_get`	Global settings (`/v3/settings`)
`rancher_audit_log_list`	`GET /v3/auditlogs` when supported (often 404/405; see note below)

When --read-only=false

Tool	Description
`rancher_norman_action`	`POST` a Norman `?action=` on a resource path under `/v3`
`rancher_token_create`	Create API token
`rancher_auth_config_update`	Replace an auth config (`PUT`)
`rancher_user_create`	Create user
`rancher_user_disable` / `rancher_user_enable`	User enable/disable actions
`rancher_global_role_binding_create`	Create global role binding
`rancher_cluster_registration_token_create`	Create registration token
`rancher_cloud_credential_create`	Create cloud credential
`rancher_catalog_refresh`	Refresh legacy catalog (`?action=refresh`)
`rancher_feature_flag_set`	Update feature flag (`PUT`)
`rancher_setting_update`	Update setting (`PUT`)
`rancher_supportbundle_generate`	Request support bundle (`generateSupportBundle` on a cluster)

When --read-only=false and --disable-destructive=false

Tool	Description
`rancher_token_delete`	Delete API token
`rancher_global_role_binding_delete`	Delete global role binding
`rancher_cluster_registration_token_delete`	Delete registration token
`rancher_cloud_credential_delete`	Delete cloud credential

Norman responses: catalog, cluster repos, audit

rancher_cluster_repo_list / rancher_cluster_repo_get: Tries Norman /v3/clusterrepos first. If that returns 404 (common), falls back to catalog.cattle.io/v1 ClusterRepo on the local cluster via Steve/Kubernetes, trying namespaces cattle-global-data, fleet-default, fleet-local, cattle-fleet-system. Success JSON includes "_source":"kubernetes_api_fallback". If nothing works, the tool still returns 200-style JSON with "_source":"unavailable" and per-attempt errors—not a hard MCP error—so automation can continue.
rancher_catalog_list / rancher_catalog_get: If Norman /v3/catalogs is not registered (404), returns JSON with "_source":"unavailable" instead of failing.
rancher_audit_log_list: If the server returns 404 or 405 (GET not supported), returns JSON with "_source":"unavailable" and _http_status; audit may be disabled or exposed outside Norman.

For catalog data when ClusterRepo is unavailable everywhere, use kubernetes_list on cluster local with api_version catalog.cattle.io/v1 and kind ClusterRepo, or Helm / Fleet tools as appropriate.

Helm tools

Tool	Description
`helm_list`	List Helm releases (optionally by namespace, deployed/failed/pending)
`helm_get`	Get release details (manifest, values, notes)
`helm_history`	Get revision history for a release
`helm_repo_list`	List configured Helm chart repositories (from local config)
`helm_install`	Install a Helm chart (when not read-only)
`helm_upgrade`	Upgrade a Helm release (when not read-only)
`helm_rollback`	Rollback a release to a previous revision (when not read-only)
`helm_uninstall`	Uninstall a release (when destructive allowed)

All tools take cluster (Rancher cluster ID). Install/upgrade require chart, release; optional repo_url, version, values (JSON).

Fleet tools

Tool	Description
`fleet_gitrepo_list`	List Fleet GitRepos (GitOps sources)
`fleet_gitrepo_get`	Get one GitRepo (spec, status)
`fleet_gitrepo_create`	Create a GitRepo (when not read-only)
`fleet_gitrepo_delete`	Delete a GitRepo (when destructive allowed)
`fleet_gitrepo_action`	Pause, unpause, disablePolling, enablePolling, forceUpdate
`fleet_gitrepo_clone`	Clone a GitRepo to a new name (copy spec)
`fleet_bundle_list`	List Fleet Bundles (deployment units from GitRepos)
`fleet_cluster_list`	List Fleet clusters (downstream clusters registered with Fleet)
`fleet_drift_detect`	Report BundleDeployments with Modified state (drift)

All tools use the Rancher management cluster (local). Optional namespace (default: fleet-default). List tools support format, limit, continue (pagination). fleet_gitrepo_create requires name, repo; optional branch, paths. fleet_gitrepo_action supports: pause, unpause, disablePolling, enablePolling, forceUpdate. fleet_gitrepo_clone copies spec from an existing GitRepo to a new name.

Kubernetes tools

Tool	Description
`kubernetes_list`	List resources by apiVersion/kind (e.g. v1 Pod, apps/v1 Deployment)
`kubernetes_get`	Get one resource by apiVersion, kind, namespace, name
`kubernetes_describe`	Get resource + recent events
`kubernetes_logs`	Get recent pod logs (tail only; container, tailLines, sinceSeconds)
`kubernetes_events`	List events in a namespace (optional involvedObject filter)
`kubernetes_capacity`	Node capacity/allocatable summary per node
`kubernetes_create`	Create resource from JSON (when not read-only)
`kubernetes_patch`	Patch resource with JSON (when not read-only)
`kubernetes_delete`	Delete resource (when destructive allowed)

All tools take cluster (Rancher cluster ID). List/get support namespace, format (json|table), limit, continue (pagination). Create/patch/delete are gated by read_only and disable_destructive. kubernetes_logs does not support follow (streaming); use tail_lines and since_seconds to limit output. In some Rancher/proxy setups pod logs can return 503 or stream errors; see Troubleshooting.

Setup: Rancher token & Harvester cluster ID

Get a Rancher API token

Log in to your Rancher UI.
Click your profile/avatar (top right) → Account & API Keys (or API & Keys).
Click Create API Key, name it (e.g. mcp-server), then Create.
Copy the token once (format like token-abc12:xyz...). Use it as --rancher-token or RANCHER_MCP_RANCHER_TOKEN.

Find your Harvester cluster ID

Harvester tools require the cluster ID (e.g. c-tx8rn) on each call.

From Rancher UI: Go to Cluster Management → open your Harvester cluster. The URL contains the cluster ID: .../c/<cluster-id>/....
From API (Steve): curl -s -H "Authorization: Bearer YOUR_TOKEN" "https://YOUR_RANCHER_URL/k8s/clusters/local/v1/management.cattle.io.clusters" | jq '.data[] | {name: .metadata.name}'
Norman schemas: curl -s -H "Authorization: Bearer YOUR_TOKEN" "https://YOUR_RANCHER_URL/v3/schemas" | jq '.data[0:5].id'

Docker (Streamable HTTP)

For HTTP server mode, use the container image from GitHub Container Registry (ghcr.io). For Cursor/Claude with stdio, use npm (see Quick start).

Run the server and expose the port:

docker run -d -p 8080:8080 \
  -e RANCHER_MCP_RANCHER_SERVER_URL=https://rancher.example.com \
  -e RANCHER_MCP_RANCHER_TOKEN="token-xxxxx:yyyy" \
  -e RANCHER_MCP_TRANSPORT=http \
  -e RANCHER_MCP_PORT=8080 \
  ghcr.io/mrostamii/rancher-mcp-server:latest

Connect clients to the MCP endpoint: `http://localhost:8080/mcp` (Streamable HTTP; default path is `/mcp`). Example: `claude mcp add -t http rancher http://localhost:8080/mcp`

Supported platforms

macOS (Apple Silicon & Intel)
Linux (x64 & ARM64)
Windows (x64)

Troubleshooting

Issue	What to check
"rancher-server-url and rancher-token are required"	Check `--rancher-server-url` and `--rancher-token` in args, or env vars `RANCHER_MCP_RANCHER_SERVER_URL` and `RANCHER_MCP_RANCHER_TOKEN`.
401 Unauthorized	Token expired or invalid. Create a new API key in Rancher.
TLS / certificate errors	For self-signed Rancher, pass `--tls-insecure` (dev only).
"cluster not found" or empty lists	Wrong cluster ID. Get it from Rancher UI URL or API; pass it as `cluster` to Harvester/Kubernetes tools.
Cursor doesn't show tools	Restart Cursor after editing `mcp.json`; check Tools & MCP that the server is enabled.
Binary not found	Use absolute paths in `mcp.json` for `command` when building from source.
`kubernetes_logs` 503 or stream errors	Known in some Rancher/proxied setups (e.g. RKE2). Reduce `tail_lines` or try another cluster; see rancher/rancher#40711.
Norman tool returns `"_source":"unavailable"`	That collection may not exist on your Rancher version (e.g. legacy `catalogs`, `clusterrepos`, or audit via `GET`). Use `rancher_norman_schema_list` to see registered types, or `kubernetes_list` / Helm / Fleet for chart sources.
Cluster repo list shows `unavailable` or empty `data`	`catalog.cattle.io` `ClusterRepo` may not be installed or proxied for your token; try `kubernetes_list` with `catalog.cattle.io/v1` and `ClusterRepo` on cluster `local` across namespaces.

License

Apache-2.0

Available Tools

10 tools

harvester_addon_listC

Destructive

List Harvester addons with their enabled/disabled state

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items per namespace (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page; only when namespace is specified)
`namespace`	No	Namespace (empty = all common addon namespaces: harvester-system, cattle-logging-system, cattle-monitoring-system, kube-system)

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description says 'List' (read-only), but annotations set destructiveHint: true, indicating modification. This is a direct contradiction. No additional behavioral details provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no wasted words. However, it sacrifices necessary detail like usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and a contradiction, the description is incomplete. It fails to explain pagination, output format, or behavior of options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% parameter description coverage, so the description adds no extra semantic value beyond the schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (List), resource (Harvester addons), and the output (enabled/disabled state). It distinguishes itself from sibling tools like harvester_host_list and harvester_vm_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. No mention of conditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_host_listB

Destructive

List Harvester hosts (nodes) with maintenance mode and disk status

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint: true, but the description does not clarify what destructive behavior occurs (e.g., whether listing triggers side effects). The description adds minimal behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that directly states the tool's function without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is brief and lacks detail about return values or pagination behavior. While the schema covers parameters, the absence of an output schema means the description could offer more context to compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters are documented in the schema. The description mentions 'maintenance mode and disk status' which are output fields, not parameters, thus adding no new parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'Harvester hosts (nodes)', and specifies key attributes 'maintenance mode and disk status'. It distinguishes from sibling tools which target different resource types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the purpose implies it is for listing hosts, there is no mention of when not to use it or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_image_listB

Destructive

List Harvester VM images (VirtualMachineImage) with download progress

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)
`namespace`	No	Namespace (empty = all)

TDQS

B3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description describes a read-only list operation, but annotations set destructiveHint=true, indicating a contradiction. No additional behavioral context is given to resolve this conflict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 9 words, clearly states action and resource. Efficient and to the point with no unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite conciseness, the description omits critical context: no explanation of 'download progress', no clarification of the destructive hint, and no description of return value. Given no output schema, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with well-described parameters. The description adds minimal extra value (e.g., 'download progress') but does not enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List Harvester VM images (VirtualMachineImage) with download progress', using a strong verb and specific resource, distinguishing it from sibling tools like harvester_vm_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., harvester_vm_list). The description only states what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_network_listB

Destructive

List Harvester VLAN networks (NetworkAttachmentDefinition)

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)
`namespace`	No	Namespace (empty = all)

TDQS

B3.1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims a read-only listing operation, but annotations declare destructiveHint=true, creating a contradiction. The description does not disclose any behavioral traits, and the annotation mismatch undermines trust.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no wasted words. However, it may be too terse for a tool with 5 parameters and no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no output schema, and a destructiveHint annotation, the description is insufficient. It does not explain return values, pagination, or potential side effects, leaving gaps for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already documents all parameters. The description adds no extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List Harvester VLAN networks (NetworkAttachmentDefinition)' clearly specifies the action (list) and resource (Harvester VLAN networks), distinguishing it from sibling tools like harvester_subnet_list and harvester_vpc_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing VLAN networks but provides no guidance on when to use this tool instead of alternatives, nor does it mention prerequisites or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_settingsB

Destructive

List or get Harvester cluster settings (backup-target, auto-disk-provision-paths, etc.)

ParametersJSON Schema

Name	Required	Description
`name`	No	Setting name (empty = list all)
`limit`	No	Max items when listing (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page; list mode only)

TDQS

B3.2/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description claims 'List or get' (read-only behavior), but annotations indicate readOnlyHint=false and destructiveHint=true, suggesting this tool can modify or destroy settings. This is a significant contradiction and misleads the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence that front-loads the action and includes examples. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite good schema coverage, the description fails to address the destructive potential implied by annotations, leaving the agent uninformed about risks. No output schema is provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds concrete examples of setting names (backup-target, etc.), enhancing clarity beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists or retrieves Harvester cluster settings, with examples of setting names. It is well-differentiated from sibling tools that list specific resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. Usage is only implied by the description, and no alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_subnet_listB

Destructive

List KubeOVN Subnets (requires kubeovn-operator addon). Subnets define VM network CIDRs and are linked to Networks via provider.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)

TDQS

B3.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates a list operation (read-only), but the annotations set destructiveHint=true, creating a contradiction. The description does not acknowledge or clarify this discrepancy or disclose any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the purpose and a key prerequisite without any fluff. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives basic context about what subnets are and their linkage to networks, but it does not describe the output format or behavior (e.g., pagination via continue token). The lack of output schema and the annotation contradiction reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter names and types already present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists KubeOVN Subnets, specifies the resource type, and provides context about their role (define VM network CIDRs, linked to Networks via provider). It distinguishes from sibling tools like harvester_network_list and harvester_vpc_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite (requires kubeovn-operator addon) and explains the relationship between subnets and networks, but does not provide explicit guidance on when to use this tool versus alternatives like network_list or vpc_list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_vm_getB

Destructive

Get a single virtual machine with full spec and status (metrics, disks, networks)

ParametersJSON Schema

Name	Required	Description
`name`	Yes	VM name
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`namespace`	Yes	Namespace

TDQS

B3.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description says 'Get' implying a read-only operation, but annotations indicate readOnlyHint: false and destructiveHint: true, which is a direct contradiction. No behavioral details about side effects are provided, making this a serious transparency failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the verb and resource, and is concise with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and a destructiveHint contradiction, the description is incomplete. It mentions 'full spec and status (metrics, disks, networks)' but does not explain return values or address the side effects implied by annotations. It is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides, as it only mentions 'output format' which is already documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'single virtual machine', and specifies the scope 'full spec and status (metrics, disks, networks)', which distinguishes it from sibling tools like 'harvester_vm_list' that likely list VMs without full details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when full VM details are needed, but does not explicitly state when to use it vs alternatives (e.g., listing) or provide any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_vm_listC

Destructive

List virtual machines across Harvester clusters with status, IP, node, CPU/memory

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items to return (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)
`namespace`	No	Namespace (empty = all namespaces)

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states a read-only operation ('List'), but annotations set destructiveHint=true and readOnlyHint=false, contradicting the described behavior. No additional behavioral context (e.g., side effects, required permissions) is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no fluff. It is appropriately front-loaded, though it could be expanded slightly without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should mention return fields or pagination behavior. It omits details on how to interpret the response or use pagination tokens (limit/continue), leaving gaps for complex use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented. The description adds no parameter-specific meaning beyond the schema, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List', the resource 'virtual machines across Harvester clusters', and mentions key fields returned (status, IP, node, CPU/memory), distinguishing it from sibling tools like harvester_vm_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives (e.g., harvester_vm_get for details, other list tools for different resources). It lacks explicit usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_volume_listB

Destructive

List PersistentVolumeClaims (Longhorn-backed volumes) with size and health

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID
`continue`	No	Pagination token from previous response (for next page)
`namespace`	No	Namespace (empty = all)

TDQS

B3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims a read-only list operation, but annotations set readOnlyHint=false and destructiveHint=true, implying potential write or destructive behavior. This contradiction is severe, and the description adds no behavioral context beyond the misleading annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that concisely conveys the action, resource, and key output fields. It is front-loaded and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks details on pagination behavior (e.g., how 'continue' token works), default limits, error handling, or interpretation of size and health. The contradiction with annotations further reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all 5 parameters, so the description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists PersistentVolumeClaims (Longhorn-backed volumes) with size and health, precisely specifying the resource and key output fields, distinguishing it from sibling tools that list other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided; the description does not indicate when to use this tool over alternatives, such as other list tools for different resources, nor any prerequisites or conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

harvester_vpc_listB

Destructive

List KubeOVN VPCs (requires kubeovn-operator addon enabled)

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items (default: 100)
`format`	No	Output format: json, table (default: json)
`cluster`	Yes	Harvester cluster ID (where KubeOVN runs)
`continue`	No	Pagination token from previous response (for next page)

TDQS

B3.4/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims the tool is a read-only list operation, but annotations set readOnlyHint: false and destructiveHint: true, which contradict the described behavior. This is a significant inconsistency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that includes both the action and a critical prerequisite, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema, the description does not explain what the tool returns (e.g., VPC IDs, status). It also does not mention pagination behavior despite a 'continue' parameter. The annotation contradiction further undermines completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action 'List' and the resource 'KubeOVN VPCs', and adds a prerequisite. It clearly distinguishes from sibling tools like harvester_host_list or harvester_network_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite (kubeovn-operator addon enabled), providing clear context for when the tool can be used. However, it does not explicitly state when not to use this tool or suggest alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct Harvester resource type (addons, hosts, images, networks, settings, subnets, VMs, volumes, VPCs). The only potential overlap is between harvester_vm_get and harvester_vm_list, but they are clearly differentiated for single vs. list operations.

Naming Consistency4/5

All tools follow the pattern 'harvester_<resource>_<action>' except 'harvester_settings' which omits the '_list' suffix. This is a minor inconsistency, but overall the naming is predictable and consistent.

Tool Count5/5

10 tools is well-scoped for managing a Harvester environment. It covers major resource categories without being overwhelming or too sparse.

Completeness2/5

The tool set is almost entirely read-only (list/get), lacking create, update, or delete operations for any resource. This is a significant gap for lifecycle management, likely causing agent failures when mutations are needed.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,887
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2

Related MCP Servers

mcp-server-kubernetes
Cloud Platforms Virtualization Developer Tools
Flux159
A
license
A
quality
A
maintenance
TypeScript implementation of Kubernetes cluster operations for pods, deployments, services.
Updated 3 days ago (2026-08-31 15:59 UTC)
18
8,657
1,578
MIT
OpsLevel MCPofficial
Developer Tools Observability Monitoring
OpsLevel
A
license
Not graded
quality
C
maintenance
Model Context Protocol (MCP) server for OpsLevel
Updated 2 months ago (2026-07-10 16:15 UTC)
12
MIT
argocd-mcpofficial
Cloud Platforms Developer Tools
argoproj-labs
A
license
C
quality
C
maintenance
An implementation of Model Context Protocol (MCP) server for Argo CD.
Updated 23 days ago (2026-08-11 15:32 UTC)
14
18,149
561
Apache 2.0
MCP REST API Server
Developer Tools Code Execution
vinaykp
F
license
Not graded
quality
D
maintenance
A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
Updated a year ago (2025-06-01 03:08 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrostamii/rancher-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

rancher-mcp-server

Demo

Features

Quick start

Install

Cursor

Claude Desktop

With env vars instead of args

Enable write operations

Streamable HTTP transport

Build from source

Configuration

Harvester tools

Creating a VM on KubeOVN VPC with external internet

Rancher tools

Steve API (management resources)

Norman API (https://<rancher>/v3/...)

Norman responses: catalog, cluster repos, audit

Helm tools

Fleet tools

Kubernetes tools

Setup: Rancher token & Harvester cluster ID

Get a Rancher API token

Find your Harvester cluster ID

Docker (Streamable HTTP)

Connect clients to the MCP endpoint: http://localhost:8080/mcp (Streamable HTTP; default path is /mcp). Example: claude mcp add -t http rancher http://localhost:8080/mcp

Supported platforms

Troubleshooting

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

OpsLevel MCPofficial

argocd-mcpofficial

Latest Blog Posts

MCP directory API

Norman API (`https://<rancher>/v3/...`)

Connect clients to the MCP endpoint: `http://localhost:8080/mcp` (Streamable HTTP; default path is `/mcp`). Example: `claude mcp add -t http rancher http://localhost:8080/mcp`