Skip to main content
Glama
OctopusDeploy

Octopus Deploy MCP Server

Official

get_certificate

Read-only

Retrieve certificate details by ID from Octopus Deploy to inspect configuration and troubleshoot deployment issues.

Instructions

Get details for a specific certificate by its ID

This tool retrieves detailed information about a specific certificate using its ID. The space name and certificate ID are both required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spaceNameYes
certificateIdYesThe ID of the certificate to retrieve

Implementation Reference

  • The handler function that executes the tool logic: creates an Octopus Deploy client from environment config, resolves the space ID, fetches the certificate resource by ID, maps it to a custom type, and returns it as JSON text content.
      async ({ spaceName, certificateId }) => {
        const configuration = getClientConfigurationFromEnvironment();
        const client = await Client.create(configuration);
        const spaceId = await resolveSpaceId(client, spaceName);
    
        const response = await client.get<CertificateResource>(
          "~/api/{spaceId}/certificates/{id}",
          {
            spaceId,
            id: certificateId,
          }
        );
    
        const certificate = mapCertificateResource(response);
    
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(certificate),
            },
          ],
        };
      }
    );
  • Input schema using Zod: requires spaceName (string) and certificateId (string).
    {
      spaceName: z.string(),
      certificateId: z.string().describe("The ID of the certificate to retrieve"),
    },
  • Main registration function that calls server.tool() to register the 'get_certificate' tool on the MCP server, including description, input schema, output metadata, and handler.
    export function registerGetCertificateTool(server: McpServer) {
      server.tool(
        "get_certificate",
        `Get details for a specific certificate by its ID
    
    This tool retrieves detailed information about a specific certificate using its ID. The space name and certificate ID are both required.`,
        {
          spaceName: z.string(),
          certificateId: z.string().describe("The ID of the certificate to retrieve"),
        },
        {
          title: "Get a specific certificate by ID from an Octopus Deploy space",
          readOnlyHint: true,
        },
        async ({ spaceName, certificateId }) => {
          const configuration = getClientConfigurationFromEnvironment();
          const client = await Client.create(configuration);
          const spaceId = await resolveSpaceId(client, spaceName);
    
          const response = await client.get<CertificateResource>(
            "~/api/{spaceId}/certificates/{id}",
            {
              spaceId,
              id: certificateId,
            }
          );
    
          const certificate = mapCertificateResource(response);
    
          return {
            content: [
              {
                type: "text",
                text: JSON.stringify(certificate),
              },
            ],
          };
        }
      );
    }
  • Self-registration of the tool definition into the TOOL_REGISTRY, specifying toolset 'certificates' and read-only, for conditional registration in src/tools/index.ts.
    registerToolDefinition({
      toolName: "get_certificate",
      config: { toolset: "certificates", readOnly: true },
      registerFn: registerGetCertificateTool,
    });
Behavior4/5

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

The description adds useful context beyond the annotations: it clarifies that both parameters are required (though this is also in the schema) and specifies the tool retrieves 'detailed information' rather than just basic data. The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation, but the description reinforces this with 'retrieves' language.

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 appropriately sized with two sentences that each serve a purpose: the first states the core functionality, the second clarifies parameter requirements. No redundant information is present, though it could be slightly more front-loaded by combining the ideas more efficiently.

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 read-only tool with annotations covering safety but no output schema, the description adequately covers the basic operation but lacks details about the return format, error conditions, or what constitutes 'detailed information.' Given the complexity is moderate (single resource retrieval), it meets minimum viability 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?

With 50% schema description coverage (only certificateId has a description), the description adds minimal parameter semantics. It mentions both parameters are required but doesn't explain what 'spaceName' represents or provide format/context for either parameter beyond what's already in the schema. The baseline is appropriate given the partial schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('retrieves') and resource ('detailed information about a specific certificate'), distinguishing it from sibling tools like 'list_certificates' which would return multiple certificates. However, it doesn't explicitly contrast with other get_* tools that retrieve 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 Guidelines3/5

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

The description implies usage context by specifying that both space name and certificate ID are required, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'list_certificates' or other get_* tools. No when-not-to-use scenarios or prerequisite conditions are mentioned.

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