ncloud-mcp-server

ncloud_cdss_add_nodes

Add broker nodes to a CDSS cluster by specifying how many to add; this count is incremental, not the final total. Broker count cannot be reduced later.

Instructions

Add broker nodes to a CDSS cluster. ⚠️ newBrokerNodeCount is HOW MANY TO ADD, not the resulting total — a cluster with 3 brokers given newBrokerNodeCount=4 ends up with 7. The SES counterpart (ncloud_ses_add_node) behaves the same way. ⚠️ Broker count cannot be reduced afterwards: CDSS has no scale-down operation, so the only way back from adding too many is deleting the cluster.

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": {
      "serviceGroupInstanceNo": "<serviceGroupInstanceNo>",
      "newBrokerNodeCount": "<newBrokerNodeCount>"
    },
    "name": "ncloud_cdss_add_nodes"
  }
}

Input Schema

Name	Required	Description	Default
`newBrokerNodeCount`	Yes	How many broker nodes to ADD (1-10). This is a delta, not the resulting total
`serviceGroupInstanceNo`	Yes	Cluster instance number

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.15.0Sep 20, 2026
- changedInput schema / properties / newBrokerNodeCount / description
```
Previous value: -"Number of broker nodes to add (1-10)"New value: +"How many broker nodes to ADD (1-10). This is a delta, not the resulting total"
```
- addedInput schema / properties / newBrokerNodeCount / maximum
```
Added value: +10
```
- addedInput schema / properties / newBrokerNodeCount / minimum
```
Added value: +1
```
First observedv1.10.1Jul 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses critical behavioral traits: newBrokerNodeCount is a delta, the operation is effectively irreversible, and over-adding can only be undone by deleting the cluster. This is valuable context an agent would not otherwise know.

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 compact and front-loaded, with the core action first and warnings organized clearly. Every sentence earns its place: the delta semantics, the sibling comparison, and the irreversibility warning are all essential operational facts.

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?

For a two-parameter mutation tool with no output schema, the description covers everything an agent needs to avoid a costly mistake: what the operation does, how the count parameter behaves, and the lack of scale-down. No critical operational details are missing.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by giving a concrete worked example ('3 brokers + 4 = 7') and linking the parameter to an irreversible outcome, which strengthens agent understanding of the parameter's real effect.

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 states a specific action and resource: 'Add broker nodes to a CDSS cluster.' This clearly differentiates it from siblings like ncloud_cdss_change_node_spec and ncloud_cdss_delete_cluster, and the focus on CDSS distinguishes it from the SES counterpart.

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

Usage Guidelines4/5

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

The description gives clear contextual guidance by explaining the delta semantics and warning that broker count cannot be reduced afterward, with deletion as the only reversal path. It does not explicitly state when-not-to-use or name alternatives, but the context strongly implies cautious use for scaling up, which is sufficient.

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

Deploy Server