Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ncloud_ses_run_import

Start a data import job from Object Storage into a Search Engine Service cluster. For bulk files, verify each line has _index to avoid no documents being imported.

Instructions

Start a data import job from Object Storage into a Search Engine Service cluster. ⚠️ With isBulkFormat=true the index parameter is ignored — each line's own _index decides the destination, so a bulk file without _index imports nothing. The import history does not report why a job produced no documents, so check the file's format first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYesTarget index name. Ignored when isBulkFormat=true — the file's own _index wins
objectKeyYesObject key (path) of the file in the bucket
bucketNameYesObject Storage bucket name (from ncloud_ses_get_import_buckets)
dataSourceYesData source type
isBulkFormatNoWhether the file is in Elasticsearch bulk format. If true, every line must carry its own _index
serviceGroupInstanceNoYesCluster instance number

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.15.0
    • changedInput schema / properties / bucketName / description
      Previous value: -"Object Storage bucket name"New value: +"Object Storage bucket name (from ncloud_ses_get_import_buckets)"
    • addedInput schema / properties / dataSource
      Added value: +{
+  "description": "Data source type",
+  "type": "string"
+}
    • removedInput schema / properties / filePath
      Removed value: -{
-  "description": "File path in the bucket",
-  "type": "string"
-}
    • addedInput schema / properties / index
      Added value: +{
+  "description": "Target index name. Ignored when isBulkFormat=true — the file's own _index wins",
+  "type": "string"
+}
    • removedInput schema / properties / indexName
      Removed value: -{
-  "description": "Target index name",
-  "type": "string"
-}
    • addedInput schema / properties / isBulkFormat
      Added value: +{
+  "description": "Whether the file is in Elasticsearch bulk format. If true, every line must carry its own _index",
+  "type": "boolean"
+}
    • addedInput schema / properties / objectKey
      Added value: +{
+  "description": "Object key (path) of the file in the bucket",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "serviceGroupInstanceNo",
-  "bucketName",
-  "filePath",
-  "indexName"
-]New value: +[
+  "serviceGroupInstanceNo",
+  "bucketName",
+  "objectKey",
+  "index",
+  "dataSource"
+]
  2. First observedv1.10.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations are empty, so the description carries the full burden. It discloses two important behavioral traits: in bulk format the index parameter is ignored and each line's _index decides the destination, and the import history will not explain why a job produced no documents. This goes well beyond a generic start-action, though it does not cover async behavior, return value, or permissions.

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?

Three sentences, front-loaded with the core action, followed by a high-value warning and a practical pre-check. There is no filler, and the warning earns its place because it prevents a silent failure mode.

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

Completeness3/5

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

The description covers the main pitfall and gives a pre-flight check, but leaves gaps: no mention that the job is likely asynchronous, no pointer to monitoring via ncloud_ses_get_import_history, and no clarification that the schema-required index parameter must still be supplied even when it is ignored. With no output schema, return behavior is also unspecified.

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?

The schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds real value by explaining the consequence of isBulkFormat=true ('imports nothing' without _index) and the diagnostic limitation, reinforcing and extending the schema's index description.

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 exactly what the tool does: start a data import job from Object Storage into a Search Engine Service cluster. The verb 'Start' and the resource 'data import job' are specific and self-explanatory, distinguishing it from sibling get/stop operations even without naming them.

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?

There is no guidance on when to use this tool versus related tools like ncloud_ses_get_import_buckets, ncloud_ses_get_import_history, or ncloud_ses_stop_import. The description implies usage by describing the action and advises checking the file format first, but offers no selection criteria, prerequisites, or exclusions.

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