ncloud-mcp-server

ncloud_register_external_certificate

Register an external SSL certificate from a third-party CA by providing its name, private key, public key certificate, and certificate chain.

Instructions

Register an external SSL certificate issued by a third-party CA (e.g. Let's Encrypt, ZeroSSL, DigiCert). certificateName: 3-20 chars, starts with a letter, letters/digits/'-' only (validated before the call).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "certificateName": "<certificateName>",
      "privateKey": "<privateKey>",
      "publicKeyCertificate": "<publicKeyCertificate>",
      "certificateChain": "<certificateChain>"
    },
    "name": "ncloud_register_external_certificate"
  }
}

Input Schema

Name	Required	Description
`privateKey`	Yes	PEM-encoded private key (must be decrypted, not encrypted)
`certificateName`	Yes	Certificate name: 3-20 chars, must start with a letter, English letters/digits/'-' only, unique within the account (limit reduced from 30 to 20 chars on 2026-09-17)
`certificateChain`	Yes	PEM-encoded certificate chain (intermediate CA certificates)
`publicKeyCertificate`	Yes	PEM-encoded certificate body (public key certificate)

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.16.0Sep 23, 2026

changedInput schema / properties / certificateName / description

Previous value: -"Certificate name (3-30 chars, alphanumeric and '-', no duplicates)"New value: +"Certificate name: 3-20 chars, must start with a letter, English letters/digits/'-' only, unique within the account (limit reduced from 30 to 20 chars on 2026-09-17)"

addedInput schema / properties / certificateName / maxLength
```
Added value: +20
```
addedInput schema / properties / certificateName / minLength
```
Added value: +3
```

First observedv1.10.1Jul 29, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations only declare destructiveHint: false, which is useful but doesn't fully characterize the operation. The description adds a small note that certificateName is 'validated before the call', which hints at input validation behavior, but it doesn't disclose any other behavioral traits such as whether registration replaces an existing certificate, if the operation is idempotent, or any permission requirements. For a registration action with minimal annotation coverage, this is a notable gap.

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 exceptionally concise: a single action sentence followed by a brief validation constraint. No fluff or redundant phrasing, and the primary purpose is front-loaded. While the validation note duplicates some schema info, it adds a unique behavioral nuance ('validated before the call') that justifies its inclusion. It earns a high score for efficiency.

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 four required parameters Skapa and no output schema, the description needs to provide more context for an agent to invoke the tool correctly. It lacks information about the expected result (does it return a certificate ID?), any prerequisites, and the effect on existing certificates (e.g., name uniqueness is in schema but not in description). The description is too sparse to be considered complete for a mutation operation, even with annotations covered.

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 provides 100% description coverage for all four parameters, including formats (PEM-encoded, decrypted) and constraints (3-20 chars, unique). The description adds no substantive meaning beyond what the schema already offers; the only extra is 'validated before the call', which is a minor behavioral note rather than parameter semantics. Per the baseline, a score of 3 is appropriate when the schema fully documents parameters.

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 action ('Register an external SSL certificate') and identifies the resource as a certificate from a third-party CA, with concrete examples (Let's Encrypt, ZeroSSL, DigiCert). This is specific and avoids tautology myself. However, it does not explicitly distinguish from sibling tools like ncloud_pca_issue_end_cert or ncloud_edge_provision_certificate, though the term 'external' subtly differentiates it from internal CA offerings.

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 offers no explicit guidance on when to use this tool versus alternatives, nor any exclusions or preconditions. The word 'external' implies this is for third-party CAs, but there's no statement like 'for internal certificates use PCA tools' or 'use this when you have a certificate from a public CA'. An agent must infer usage context from the name and description, which is insufficient.

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

Deploy Server