ncloud-gov-mcp-server

ncloud_ses_list_clusters

Read-only

List all Elasticsearch/OpenSearch clusters in the current region, with optional filters for VPC, name keyword, and pagination to manage results.

Instructions

List all Search Engine Service (Elasticsearch/OpenSearch) clusters in the current region

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ncloud_ses_list_clusters"
  }
}

Input Schema

Name	Required	Description
`pageNo`	No	Page number (default: 1)
`vpcName`	No	VPC name to filter (exact match)
`pageSize`	No	Page size (default: 10)
`inputText`	No	Search keyword to filter cluster names

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Aug 2, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context about region scoping and the service type, but it does not disclose pagination behavior, potential large result sets, or that 'all' might require iterating pages. With annotations covering safety, this is adequate but not rich.

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?

A single, front-loaded sentence with no redundancy. It states the action, resource, and scope efficiently. Every word contributes to understanding.

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

Completeness4/5

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

The tool is a straightforward list operation with readOnly annotation and fully documented optional parameters. While there is no output schema, the description covers the essential scope and resource type. The only minor gap is not explicitly stating the return format, but for a list tool this is largely implied and pagination is handled by documented parameters.

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?

Schema description coverage is 100%, with each parameter (pageNo, vpcName, pageSize, inputText) having a clear description including defaults and matching semantics. The tool description adds no parameter-specific details, but the schema fully carries that burden, so baseline 3 applies.

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 uses a specific verb ('List') and identifies the exact resource ('Search Engine Service clusters') with clarifying parenthetical '(Elasticsearch/OpenSearch)'. It also specifies scope ('in the current region'), distinguishing it from sibling list tools like ncloud_cdss_list_clusters and ncloud_hadoop_list_clusters.

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 clearly conveys what the tool does (lists all clusters in the current region), providing enough context for an agent to know when to use it. However, it does not explicitly mention alternatives or exclusion criteria (e.g., when to use ncloud_ses_get_cluster_detail instead), so it stops short of a 5.

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

Deploy Server