The investigation path is the strongest thing here: URL to deployment, deployment to task, task to a grep over the activity log — no id extraction, and no dragging a whole log into the conversation. Permissions are worth deciding before you install rather than after: writes are enabled by default and can create releases and trigger deployments, so production installs generally want --read-only, and DELETE stays off unless --allow-deletes is passed. Method gating is enforced by the server rather than by the model's stated intent, and a handful of destructive paths stay blocked regardless of flags.
Octopus Deploy's own MCP server. Curated tools cover spaces, projects, environments, releases, deployments, tenants, infrastructure and audit; a structured REST backstop reaches everything else, with read, write and delete classified server-side by HTTP method.
- Paste a deployment or task URL and get the object back — get_deployment_from_url returns the task id needed for logs, get_task_from_url returns task details and state
- grep_task_log searches a task's activity log with grep semantics — pattern, case insensitivity, inverted match, before and after context, max count — instead of pulling the whole log into the session
- Spaces, projects, environments and deployments listed with partial-name filters, and deployments filtered by project, environment, channel, tenant and task state
- find_releases works three ways depending on what you pass: a release id, a project, or a version search; find_runbooks covers both database-backed and Git-backed projects
- create_release with channel, packages, Git ref, release notes and version; deploy_release to one or more environments, tenanted or not, with scheduled run time, skipped steps, excluded machines and guided failure
- run_runbook executes an operational process against environments and tenants, with the same scheduling and step-skipping controls
- find_interruptions surfaces manual interventions, guided failures and pending approvals, filtered to those pending or assigned to you
- get_variables returns project and library variable set values; get_tenant_variables reads them per tenant by type, and get_missing_tenant_variables lists the ones with no value — the usual cause of a tenanted deployment failing
- get_kubernetes_live_status reports live Kubernetes resource status for a project and environment
- find_deployment_targets, find_certificates and find_accounts inspect infrastructure by id or by filter, and find_events searches the audit log by user, project, tenant, date range and event group
- find_feature_toggles reports per-environment state and rollout percentages, and update_feature_toggle flips an environment or changes a percentage
- get_deployment_process and get_branches read the process and Git branches for version-controlled projects, and read_resource fetches any octopus:// URI another tool returned
- grep_llms_txt searches the Octopus API catalog, and execute then calls that REST endpoint — the documented path from "no tool for this" to the call itself
An Octopus Deploy instance reachable over HTTPS and a credential in the environment — OCTOPUS_API_KEY for interactive use, or OCTOPUS_ACCESS_TOKEN for short-lived automated tokens, which takes precedence when both are set. Credentials are never accepted as command-line flags. OCTOPUS_SERVER_URL names the instance, or --server-url does. Node.js v20.0.0 or higher for npx -y @octopusdeploy/mcp-server, or the octopusdeploy/mcp-server Docker image. Write tools are on by default and gated by an elicitation prompt: clients without elicitation must pass confirm: true, and OCTOPUS_SKIP_ELICITATION=true removes the gate for unattended runs. --read-only disables the write tools and blocks POST, PUT, PATCH and DELETE through execute; --allow-deletes is needed for DELETE and is off by default. Most tools work against Octopus Server 2021.1 and later; --list-tools-by-version prints which ones need more.
One command plus a key — npx -y @octopusdeploy/mcp-server, then supply credentials