Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425

ncloud_serverless_batch_delete_logs

DestructiveIdempotent

Delete multiple log files from a Cloud Server instance in one atomic batch request. Requires confirmation to execute; BIN logs are excluded.

Instructions

⚠️ Destructive: Delete 1-10 log files of an instance atomically (POST …/logs/batch-delete → 202 Operation). BIN logs cannot be deleted. Set confirm=true to execute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
logsYesLog files to delete (1-10)
confirmNoMust be true to actually execute the destructive operation
clusterNameYesCluster name (3-30 chars, lowercase letters/digits/'-', no leading or trailing '-'; immutable after creation)
instanceNameYesInstance name ({clusterName}-{suffix}, from ncloud_serverless_list_instances)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, it opens with a destructive warning, states atomic deletion, notes that BIN logs are excluded, and requires confirm=true. It adds meaningful behavioral context not inferable from the annotations alone, and nothing contradicts the annotations.

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?

One efficient sentence front-loads the destructive warning and packs endpoint, scope, atomicity, a key exclusion, and the execution gate. There is no filler.

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?

With no output schema, the description supplies the essential 202 Operation response and the destructive/confirmation context, while the input schema covers cluster, instance, and log details. It could add how to track the resulting operation, but for a destructive tool with rich annotations this is a minor gap.

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% and the schema already documents ranges, regexes, and confirm, so the baseline is 3. The description adds important semantics by flagging that the BIN logType, though in the enum, cannot be deleted, and reinforces the 1-10 batch boundary.

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 names a specific verb ('Delete'), a resource ('log files of an instance'), a count range (1-10), and an exact API endpoint with its 202 response. It clearly differentiates the tool from sibling operations such as ncloud_serverless_list_logs and ncloud_serverless_export_logs.

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?

It gives a clear context for the operation and key restrictions ('BIN logs cannot be deleted' and confirm=true), but it never explicitly states when to choose this tool over alternatives. Usage context is implied by purpose rather than stated as routing guidance.

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