@octopusdeploy/mcp-server

Deploy a release to one or more environments in Octopus Deploy This tool supports both tenanted and untenanted deployments: - **Untenanted**: Don't provide tenants or tenantTags. Can deploy to multiple environments at once. - **Tenanted**: Provide tenants or tenantTags. Can only deploy to ONE environment, but can target multiple tenants. The tool automatically determines which deployment type to use based on the parameters provided.

List customer feature toggles in an Octopus Deploy project. Each summary includes per-environment state (isEnabled, rolloutPercentage, clientRolloutPercentage) so "where is X turned on" is answerable from the list response. Heavy fields (description, tenant lists, segments, minimum versions) live in the resource body. Dereference the returned resourceUri (octopus://spaces/{spaceName}/projects/{projectId}/featuretoggles/{slug}) for the full toggle body. Use update_feature_toggle to flip an environment on/off or change rollout percentages on an existing toggle. This MCP server does not expose toggle creation, deletion, renaming, or rollout-group management — direct customers to the Octopus UI for those.

Search the Octopus Deploy audit log (also called the Events log) — every meaningful action recorded against a space: deployments, release creations, modifications, user logins, machine registrations, variable edits, tenant changes, and so on. **Modes** (the \

Search the Octopus API catalog at octopus://api/llms.txt with grep-style semantics. The catalog is large (~300+ KB) — call this rather than reading the resource body directly. llms.txt is structured as: - Authentication and Space Selection sections (top of file) - Endpoints section: one '### {Category}' heading per resource family (Accounts, ActionTemplates, Channels, Releases, …) and one bullet per endpoint of the form \

This tool lists all projects in a given space. ${projectsDescription} The space name is required, if you can't find the space name, ask the user directly for the name of the space. Optionally filter by partial name match using partialName parameter.

Find tenants in a space - can retrieve a single tenant by ID or list all tenants This unified tool can either: - Get details for a specific tenant when tenantId is provided, including the projects and environments the tenant is associated with - List all tenants in a space when tenantId is omitted ${tenantsDescription} Optionally provide filtering and pagination parameters when listing.

Get deployment details from an Octopus Deploy deployment URL. Returns comprehensive deployment information including the task ID needed to view execution logs. Accepts deployment URLs like: https://your-octopus.com/app#/Spaces-1/projects/my-app/deployments/releases/1.0.0/deployments/Deployments-123 Returns: - Full deployment details (environment, release, project, created time) - taskIdForLogs: the ServerTasks- ID for this deployment - taskResourceUri: octopus:// URI for the structured activity tree (resources/read or read_resource) - grepTaskLogHint: pre-filled arguments for the grep_task_log tool — call it with a pattern to search the raw log without fetching the whole thing - Public URL for web portal access Recommended workflow for investigating deployment issues: 1. Call get_deployment_from_url with the deployment URL 2. Review deployment context (environment, release version, etc.) 3a. Fetch the taskResourceUri for the structured activity tree (step timings, embedded log entries by category), OR 3b. Call grep_task_log with the taskId to search the raw log for a specific error / pattern Handles space ID to space name resolution automatically.

Create a new release for an Octopus Deploy project This tool creates a new release for a project. The space name and project name are required. All other parameters are optional and will use Octopus defaults if not specified.

List environments in a space This tool lists all environments in a given space. The space name is required. Use this tool as early as possible to understand which environments are configured. Optionally filter by partial name match using partialName parameter.

Universal fetch for any 'octopus://' URI returned by any other tool. Use this whenever you see fields like 'resourceUri' or 'taskResourceUri' in a response and need the full body. How to use: - Pass the URI string verbatim. Examples: 'octopus://spaces/Default/releases/Releases-42', 'octopus://spaces/Default/tasks/ServerTasks-7', 'octopus://spaces/Default/tasks/ServerTasks-7/details'. - The response 'mimeType' tells you how to interpret 'text': 'application/json' → parse as JSON. This tool is the backstop for clients that do not natively implement the MCP 'resources/read' primitive. Clients that DO support resources/read (Claude Code, MCP Inspector) can call it directly and skip this tool. Either path returns byte-identical bodies. Tools that return resource URIs include: find_releases, get_deployment_from_url, get_task_from_url, and others. When in doubt, call read_resource on any 'octopus://' string you encounter. Note: there is intentionally no octopus://...tasks/{id}/log resource. Call the grep_task_log tool to search task logs without inhaling the full body.

Get Kubernetes live status for a project and environment This tool retrieves the live status of Kubernetes resources for a specific project and environment. Optionally include a tenant ID for multi-tenant deployments.

List deployments in a space This tool lists deployments in a given space. The space name is required. When requesting latest deployment consider which deployment state the user is interested in (successful or all). Optional filters include: projects (array of project IDs), environments (array of environment IDs), tenants (array of tenant IDs), channels (array of channel IDs), taskState (one of: Canceled, Cancelling, Executing, Failed, Queued, Success, TimedOut), and take (number of results to return).

Search a server task's activity log with grep-style semantics. Returns only matching lines (with optional symmetric context windows). This is the canonical way to inspect task logs — there is no full-log resource URI, because exposing one would tempt callers to inhale multi-megabyte bodies when grep is almost always the better primitive. Use this when you know what to look for (a specific error string, a step name, a pattern). For structured access to the activity tree (step hierarchy, categories, timing) use the octopus://spaces/{spaceName}/tasks/{taskId}/details resource instead. Parameter conventions mirror GNU grep so the schema is self-explanatory: - pattern (regex by default; set fixedString:true for literal text) - caseInsensitive (-i) - invertMatch (-v) - fixedString (-F) - beforeContext (-B) - afterContext (-A) - maxCount (-m) Response includes totalMatches (true count across the whole log), totalLines, the matched lines with 1-indexed lineNumber, optional before/after context arrays, and a taskDetailsResourceUri for the structured fall-through.

Adjust an existing customer feature toggle in an Octopus Deploy project. Narrow surface — flip an environment on/off, change rollout percentages, or update the toggle-level description / default state. Internally fetches the current toggle, applies your patches in memory, and PUTs the merged body, so unmentioned environments and unmentioned fields are preserved. Deliberately not exposed: name/slug rename, tag changes, rollout group attach/detach, tenant targeting, segments, minimum version, adding or removing environment configurations entirely. For those, use the Octopus UI. Patches that reference an environment not already configured on the toggle are rejected with reason: environment_not_configured. The tool does not add new environment configurations.

Get missing tenant variables This tool retrieves tenant variables that are missing values. Optionally filter by tenant, project, or environment.

Find deployment targets (machines) in a space - can retrieve a single target by ID or list all targets This unified tool can either: - Get detailed information about a specific deployment target when targetId is provided - List all deployment targets in a space when targetId is omitted You can optionally filter by various parameters like name, roles, health status, etc. when listing.

List all spaces in the Octopus Deploy instance. ${spacesDescription} Always use this tool first to check that the requested space exists.

Find accounts in a space - can retrieve a single account by ID or list all accounts This unified tool can either: - Get detailed information about a specific account when accountId is provided - List all accounts in a space when accountId is omitted You can optionally filter by various parameters like name, account type, etc. when listing.

This tool gets all project and library variable set variables for a given project. Projects can contain variables (specific to a project), library variable sets (shared collections of variables associated with many projects), and tenant variables (variables related to a tenants connected to the project) If you want to retrieve tenant variables for a tenant connected to the project, use the get_tenant_variables tool.

Get Git branches for a version-controlled project This tool retrieves Git branches for a specific project in a space. The space name and project ID are required. Optionally provide searchByName, skip, and take parameters for filtering and pagination.

Find releases in an Octopus Deploy space. Three modes, picked by which arguments are supplied: - releaseId → fetch the summary for that release. - projectId → list releases for that project (optionally filtered by searchByVersion). - neither → list releases across the space. Each summary includes a resourceUri for fetching the full release body (release notes, packages, build information, custom fields).

Run a runbook against one or more environments in Octopus Deploy. Runbooks execute operational processes (DB backups, smoke tests, environment refresh, etc.) against the specified environments. For tenanted runs, supply tenants and/or tenantTags. Two project kinds: - DB-backed projects: by default the runbook's published snapshot is used; pass runbookSnapshotId to pick a specific snapshot. - Config-as-Code projects: pass gitRef (branch name like 'main', tag, or commit SHA). Snapshots don't apply — the gitRef is the version pin. Use find_runbooks with the same gitRef to discover runbook names.

Get information about the current authenticated user This tool retrieves information about the currently authenticated user from the Octopus Deploy API.

Get deployment process by ID This tool retrieves a deployment process by its ID. Each project has a deployment process attached, and releases/deployments can also have frozen processes attached.

Get task details from an Octopus Deploy task URL. Returns full task details including execution logs and state. This tool is a URL-to-ID resolver that returns the **same body** as the \

Find certificates in a space - can retrieve a single certificate by ID or list all certificates This unified tool can either: - Get detailed information about a specific certificate when certificateId is provided - List all certificates in a space when certificateId is omitted You can optionally filter by various parameters like name, archived status, tenant, etc. when listing.

Find interruptions (manual interventions, guided failures, deployment approvals) in an Octopus Deploy space. Interruptions are the Octopus surface equivalent to pending approvals: a deployment or runbook run pauses and waits for a human to take action. Use this tool to enumerate them or to look up a single one. Modes (picked by which arguments you supply): - interruptionId → fetch the slim summary for that interruption. - assignedToMe → list interruptions the authenticated user can act on; resolves /users/me (cached per session). - regarding → list interruptions related to a specific entity (ServerTasks-…, Deployments-…). Native server-side filter. - (none) → list all interruptions, optionally filtered by pendingOnly (default: true) and skip/take. Each summary includes: - resourceUri → octopus://spaces/{spaceName}/interruptions/{id} for the FULL body (form definition with Markdown instructions, button options, control types, and any already-submitted values). Dereference this when the user asks for details about a specific interruption. - taskResourceUri → octopus://spaces/{spaceName}/tasks/{taskId} for the surrounding deployment/runbook task. - publicUrl → Octopus portal deep link to take action. - formElementNames → just the field names (e.g. Instructions, Notes, Result). Field values are NOT in the slim summary; fetch resourceUri for those.

Reach Octopus REST endpoints not covered by the curated tools. Use this only after grep_llms_txt has shown you the right method and path. **Method gating is hard-coded server-side, three tiers:** - GET → read tier: always allowed (subject to toolset allowlist + sensitive denylist). - POST/PUT/PATCH → write tier: blocked when --read-only is set; requires user confirmation via elicitation otherwise. - DELETE → delete tier: requires --allow-deletes (and is blocked when --read-only is set) AND a stronger user confirmation. The HTTP method enum is the gate. The tool will not honour any 'isRead' flag the agent invents — the runtime classifies based on the actual method. **Other gates** (in order): 0. Path shape: must be '/api' or start with '/api/'. Absolute URLs, '~/api/...', '/octopus/portal/...', query strings, fragments, '..' segments, and percent-encoded slashes are all rejected up front. 1. Sensitive denylist: API key endpoints and catastrophic deletes (DELETE /api/users/{id}, DELETE /api/spaces/{id}) are always blocked. 2. Path allowlist — only applied when --toolsets has narrowed the active set. With every toolset enabled (the default, or explicit --toolsets all) any path under /api is reachable subject to the other gates; when toolsets are narrowed, paths only resolve if their owning toolset is enabled so disabling a toolset (e.g. 'certificates') makes its endpoints unreachable even on GET. 3. Elicitation on every non-GET, with a stronger message for DELETE. Discover endpoints with grep_llms_txt. Use octopus://api/capabilities to see which toolsets are enabled and whether write/delete modes are on.

Get tenant variables by type This tool retrieves different types of tenant variables. Use variableType parameter to specify which type: - "all": Get all tenant variables - "common": Get common variables only - "project": Get project-specific variables only

Find runbooks in an Octopus Deploy project. Two project kinds are supported: - DB-backed projects: address runbooks by 'runbookId' (e.g. 'Runbooks-123'). The summary includes 'publishedRunbookSnapshotId', which run_runbook uses by default. - Config-as-Code (CaC) projects: pass 'gitRef' (branch name like 'main', tag, or commit SHA). Address a single runbook by 'runbookSlug'. The summary includes 'gitRef' instead of 'publishedRunbookSnapshotId'; run_runbook needs the same gitRef. Modes: - runbookId → fetch a single DB runbook. - runbookSlug + gitRef → fetch a single CaC runbook. - gitRef alone → list CaC runbooks at that ref. - neither → list DB runbooks in the project (optionally filtered by partialName). Each summary includes multiTenancyMode and environmentScope so callers can determine which environments and tenants are valid targets before invoking run_runbook.