Skip to main content
Glama
OctopusDeploy

Octopus Deploy MCP Server

Official

Get task details from an Octopus Deploy URL

get_task_from_url
Read-onlyIdempotent

Get full task details from an Octopus Deploy task URL, including execution logs and state. Automatically resolves space names and validates task IDs.

Instructions

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 octopus://spaces/{spaceName}/tasks/{taskId}/details resource — no need to dereference the URI afterward. If you only need lightweight metadata for polling (state, timing, completion flags) use the smaller octopus://spaces/{spaceName}/tasks/{taskId} resource instead.

Accepts task URLs like: https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456

Key features:

  • Returns full task details including execution logs

  • Handles space ID to space name resolution automatically

  • Validates task ID format

For deployment URLs: If you have a deployment URL, use this workflow:

  1. Call get_deployment_from_url with the deployment URL

  2. Use the returned taskResourceUri (structured tree) or call grep_task_log with the returned taskId to search the raw log

Tasks represent background operations in Octopus Deploy, such as deployments, health checks, and system maintenance. Each task has a unique ID and can be monitored for status and progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesFull Octopus Deploy task URL containing a task ID (e.g., https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456)

Implementation Reference

  • Core handler function that extracts a task ID from an Octopus Deploy URL, resolves the space name, fetches full task details via SpaceServerTaskRepository.getDetails(), and returns the task along with URL info.
    export async function getTaskFromUrl(client: Client, params: GetTaskFromUrlParams) {
      const { url } = params;
    
      if (!url) {
        throw new Error("URL is required");
      }
    
      const urlParts = parseOctopusUrl(url);
    
      if (!urlParts.spaceId) {
        throw new Error("Could not extract space ID from URL. URL must contain a space identifier like 'Spaces-1234'");
      }
    
      const spaceName = await resolveSpaceNameFromId(client, urlParts.spaceId);
    
      const taskId = extractTaskId(url);
    
      if (!taskId) {
        throw new Error(
          `Could not extract task ID from URL. ` +
          `URL must contain a task identifier (ServerTasks-XXXXX). ` +
          `If you have a deployment URL, use get_deployment_from_url first to resolve the task ID, ` +
          `then fetch octopus://spaces/{spaceName}/tasks/{taskId}/details for the structured activity tree, or call grep_task_log to search the raw log.`
        );
      }
    
      validateEntityId(taskId, 'task', ENTITY_PREFIXES.task);
    
      const serverTaskRepository = new SpaceServerTaskRepository(client, spaceName);
      const response = await serverTaskRepository.getDetails(taskId);
    
      return {
        task: response,
        resolvedSpaceName: spaceName,
        resolvedTaskId: taskId,
        urlInfo: {
          originalUrl: url,
          extractedSpaceId: urlParts.spaceId,
          extractedTaskId: taskId,
          resourceType: urlParts.resourceType,
        }
      };
    }
  • MCP tool registration with input schema (url: string), description, and the async handler that creates a client, calls getTaskFromUrl(), and returns the JSON result.
    export function registerGetTaskFromUrlTool(server: McpServer) {
      server.registerTool(
        'get_task_from_url',
        {
          title: 'Get task details from an Octopus Deploy URL',
          description: `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 \`octopus://spaces/{spaceName}/tasks/{taskId}/details\` resource — no need to dereference the URI afterward. If you only need lightweight metadata for polling (state, timing, completion flags) use the smaller \`octopus://spaces/{spaceName}/tasks/{taskId}\` resource instead.
    
    Accepts task URLs like:
    https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456
    
    Key features:
    - Returns full task details including execution logs
    - Handles space ID to space name resolution automatically
    - Validates task ID format
    
    For deployment URLs:
    If you have a deployment URL, use this workflow:
    1. Call get_deployment_from_url with the deployment URL
    2. Use the returned taskResourceUri (structured tree) or call grep_task_log with the returned taskId to search the raw log
    
    ${tasksDescription}`,
          inputSchema: {
            url: z.string()
              .describe("Full Octopus Deploy task URL containing a task ID (e.g., https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456)")
          },
          annotations: READ_ONLY_TOOL_ANNOTATIONS,
        },
        async (args) => {
          const { url } = args as GetTaskFromUrlParams;
    
          if (!url) {
            throw new Error("URL is required");
          }
    
          const configuration = getClientConfigurationFromEnvironment();
          const client = await Client.create(configuration);
    
          const result = await getTaskFromUrl(client, { url });
    
          return {
            content: [
              {
                type: "text",
                text: JSON.stringify(result, null, 2),
              },
            ],
          };
        }
      );
    }
  • TypeScript interface defining the input parameter: a single 'url' string.
    export interface GetTaskFromUrlParams {
      url: string;
    }
  • Self-registration via registerToolDefinition, marking the tool as part of the 'tasks' toolset and read-only.
    registerToolDefinition({
      toolName: "get_task_from_url",
      config: { toolset: "tasks", readOnly: true },
      registerFn: registerGetTaskFromUrlTool,
    });
  • Side-effect import that triggers the self-registration of the get_task_from_url tool when the tools module is loaded.
    import "./getTaskFromUrl.js";
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context: it returns same body as a specific resource, handles space ID resolution automatically, validates task ID format. No contradictions.

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 structured with opening sentence, usage differentiation paragraph, key features list, deployment workflow, and task definition. It is front-loaded with core purpose. Slightly lengthy but well-organized.

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

Completeness5/5

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

No output schema exists, but description explains return includes full details, execution logs, and state. Covers URL format, auto-resolution, and provides cross-tool workflow context. Complete for a URL-to-ID resolver.

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 has 100% coverage with a description for the url parameter. Description adds a concrete example of the URL format and explains that space ID to space name resolution happens automatically, which adds value beyond 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 resolves a task URL to return full task details including execution logs and state. It distinguishes from the lightweight metadata resource and sibling tools like get_deployment_from_url and grep_task_log, providing specific verb and resource.

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

Usage Guidelines5/5

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

Explicit when-to-use: for full details from URL; alternative for lightweight metadata is mentioned. Also provides a step-by-step workflow for deployment URLs, directing to other tools. This covers when-not-to-use and alternatives clearly.

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

Install Server

Other Tools

Latest Blog Posts

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/OctopusDeploy/mcp-server'

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