Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ncloud_list_cache_instances

Read-only

List Cloud DB for Cache (Redis/Valkey) instances in the current region, with optional filters for VPC, subnet, zone, DBMS type, and more to find specific cache resources.

Instructions

List all Cloud DB for Cache (Redis/Valkey) instances in the current region

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vpcNoNoFilter by VPC number
pageNoNoPage number (0-based). Requires pageSize
pageSizeNoPage size (min 1). Required when pageNo is given
subnetNoNoFilter by subnet number
zoneCodeNoFilter by zone code (e.g. KR-1, KR-2)
regionCodeNoRegion code (e.g., KR, JPN, SGN)
generationCodeNoFilter by server generation: G2 | G3
cloudCacheDbmsCodeNoFilter by DBMS type: Redis | Valkey
cloudCacheServerNameNoFilter by Cache server name
cloudCacheServiceNameNoFilter by Cache service name
cloudCacheInstanceNoListNoFilter by Cache instance numbers
cloudCacheServerInstanceNoListNoFilter by Cache server instance numbers

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.15.0
    • addedInput schema / properties / cloudCacheDbmsCode
      Added value: +{
+  "description": "Filter by DBMS type: Redis | Valkey",
+  "enum": [
+    "Redis",
+    "Valkey"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / cloudCacheServerInstanceNoList
      Added value: +{
+  "description": "Filter by Cache server instance numbers",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / cloudCacheServerName
      Added value: +{
+  "description": "Filter by Cache server name",
+  "type": "string"
+}
    • addedInput schema / properties / generationCode
      Added value: +{
+  "description": "Filter by server generation: G2 | G3",
+  "enum": [
+    "G2",
+    "G3"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / pageNo / description
      Previous value: -"Page number for pagination"New value: +"Page number (0-based). Requires pageSize"
    • addedInput schema / properties / pageNo / minimum
      Added value: +0
    • changedInput schema / properties / pageSize / description
      Previous value: -"Page size for pagination"New value: +"Page size (min 1). Required when pageNo is given"
    • addedInput schema / properties / pageSize / minimum
      Added value: +1
    • addedInput schema / properties / regionCode
      Added value: +{
+  "description": "Region code (e.g., KR, JPN, SGN)",
+  "type": "string"
+}
    • addedInput schema / properties / subnetNo
      Added value: +{
+  "description": "Filter by subnet number",
+  "type": "string"
+}
    • addedInput schema / properties / vpcNo
      Added value: +{
+  "description": "Filter by VPC number",
+  "type": "string"
+}
    • addedInput schema / properties / zoneCode
      Added value: +{
+  "description": "Filter by zone code (e.g. KR-1, KR-2)",
+  "type": "string"
+}
  2. First observedv1.10.1

TDQS

A4/5.0
Behavior4/5

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

The description adds the scoping constraint 'current region', which is useful behavioral context beyond the readOnlyHint annotation. It does not disclose pagination behavior or return format, but given the read-only nature and simplicity, this is acceptable.

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 a single, concise sentence with no wasted words. It front-loads the action and resource, making it easy for an agent to quickly grasp the tool's purpose.

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?

For a list operation with full schema coverage and a readOnlyHint annotation, the description is sufficiently complete. It does not describe the return structure, but no output schema exists, and the operation's purpose is clear. Minor details like pagination dependencies are already in the schema.

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 coverage is 100%, so all parameters are described in the schema. The description does not add any parameter-specific meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 verb 'List', the resource 'Cloud DB for Cache (Redis/Valkey) instances', and the scope 'current region'. This distinguishes it from sibling tools like ncloud_list_cache_backups or ncloud_get_cache_instance_detail without ambiguity.

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 provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The purpose is inferable from the name, but there is no direct statement about when not to use it or when to prefer a sibling tool.

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

Deploy Server

Other Tools