Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425

ncloud_datafence_reject_file_export

Destructive

Reject a Naver Cloud Datafence file export request with a required reason. Set confirm=true to execute the destructive rejection.

Instructions

⚠️ Destructive: Reject a file export request with a reason. Set confirm=true to execute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
boxIdYesBox number (see ncloud_datafence_list_boxes)
fileIdYesExport request number (see ncloud_datafence_list_file_exports)
confirmNoMust be true to actually execute the destructive operation
fenceIdYesDatafence number (see ncloud_datafence_get_datafence)
rejectReasonYesReason for the rejection (1-1000 chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the '⚠️ Destructive' prefix is largely a restatement. The genuinely useful addition is the confirm=true gate, but the description does not say whether the rejection is irreversible, what state the export moves to, or whether permissions/approval rights are required.

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?

Two short sentences with the destructive warning and the required confirm flag front-loaded, and zero wasted text.

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 destructive mutation with full schema coverage, annotations, and no output schema, the definition covers purpose, destructive nature, and the confirm gate. It omits the effect/aftermath of a rejection and any permission prerequisites, which would round it out.

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 all five parameters (fenceId, boxId, fileId, rejectReason, confirm) are documented in the schema, including cross-references to the listing tools. The description's only parameter claim ('Set confirm=true') duplicates the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Reject a file export request') plus the mandatory reason argument, which cleanly separates it from the sibling ncloud_datafence_approve_file_export. It does not explicitly name that sibling or the cancel alternative, so it stops short of a 5.

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 context of use is implied (rejecting a pending export request) and it adds the critical execution condition 'Set confirm=true to execute.' However, it gives no explicit when-to-use versus ncloud_datafence_approve_file_export, ncloud_datafence_cancel_file_export, or ncloud_datafence_get_export_approval, and no prerequisite/approval context.

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