Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ncloud_ncs_list_buckets

Read-only

List Ncloud Storage buckets with optional prefix filtering and pagination to manage S3-compatible object storage in Naver Cloud.

Instructions

[Ncloud Storage] List Ncloud Storage buckets (GET / on kr.ncloudstorage.com). Ncloud Storage is the newer S3-compatible object storage at {bucket}.kr.ncloudstorage.com (KR only) and is a separate service from the legacy Object Storage with its own bucket namespace — for Object Storage buckets use ncloud_list_buckets and the other ncloud_* tools without the ncs_ prefix.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prefixNoOnly buckets whose name starts with this prefix
maxBucketsNoBuckets per page (1–10,000)
continuationTokenNoPagination: continuationToken from the previous response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.15.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / continuationToken
      Added value: +{
+  "description": "Pagination: continuationToken from the previous response",
+  "type": "string"
+}
    • addedInput schema / properties / maxBuckets
      Added value: +{
+  "description": "Buckets per page (1–10,000)",
+  "maximum": 10000,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / prefix
      Added value: +{
+  "description": "Only buckets whose name starts with this prefix",
+  "type": "string"
+}
  2. First observedv1.10.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, but the description adds real context: read-only GET semantics, the {bucket}.kr.ncloudstorage.com host pattern, KR-only availability, and that it is a separate service with its own bucket namespace. It does not mention response shape or pagination behavior, but the safety/scope profile is well covered.

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?

Two sentences, front-loaded with the action and endpoint before the service-distinction context. Slightly dense in the second sentence with host-pattern and namespace detail, but every clause carries routing value.

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 no-arg list tool with no output schema, the description supplies everything needed: identity, endpoint family, region scope, and the sibling routing rule. Return values are out of scope since no output schema exists and pagination is handled by a schema-documented parameter.

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%, so prefix, maxBuckets, and continuationToken are already documented in the schema. The description adds nothing about the parameters (e.g. that prefix filters bucket names, or that continuationToken drives pagination), 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?

States a specific verb and resource ("List Ncloud Storage buckets") plus the underlying API call (GET / on kr.ncloudstorage.com). It explicitly distinguishes itself from the near-identical sibling ncloud_list_buckets, which is the main disambiguation risk in this namespace.

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

Usage Guidelines5/5

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

Explicitly names the alternative ("for Object Storage buckets use ncloud_list_buckets and the other ncloud_* tools without the ncs_ prefix"), giving the agent a clear rule for when to pick this tool versus its sibling. No inference required.

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