Skip to main content
Glama
sjk4425

ncloud-mcp-server

by sjk4425
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ncloud_delete_monitor_group_force

DestructiveIdempotent

Force delete Naver Cloud monitoring target groups with all related event rules. Use for irreversible cleanup of groups and rules returned by ncloud_get_rules_by_monitor_group.

Instructions

⚠️ Destructive: Force delete monitoring target groups together with ALL event rules related to them. Pass the groups as returned by ncloud_get_rules_by_monitor_group. This is irreversible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupsYesMonitor groups and their related event rules ([{id, ruleGroupItemDtoList}], from ncloud_get_rules_by_monitor_group)
confirmNoMust be true to execute force deletion.
prodKeyYesProduct key (cw_key)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.0.1
    • addedInput schema / properties / groups
      Added value: +{
+  "description": "Monitor groups and their related event rules ([{id, ruleGroupItemDtoList}], from ncloud_get_rules_by_monitor_group)",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "description": "Monitor group or metrics group ID to delete",
+        "type": "string"
+      },
+      "ruleGroupItemDtoList": {
+        "description": "Event Rules related to the group (RuleGroupItemDto[], as returned by ncloud_get_rules_by_metrics_group / ncloud_get_rules_by_monitor_group)",
+        "items": {
+          "additionalProperties": {},
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "id",
+      "ruleGroupItemDtoList"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • removedInput schema / properties / monitorGroupId
      Removed value: -{
-  "description": "Monitor group ID whose related rules will be deleted",
-  "type": "string"
-}
    • addedInput schema / properties / prodKey
      Added value: +{
+  "description": "Product key (cw_key)",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "monitorGroupId"
-]New value: +[
+  "prodKey",
+  "groups"
+]
  2. First observedv1.10.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered; the description nonetheless adds real value by disclosing the cascade ('ALL event rules related to them') and explicit irreversibility. It slightly under-specifies by not mentioning that the confirm flag must be set (though the schema documents it).

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 short sentences, front-loaded with the destructive warning and ending on the irreversibility constraint. Nothing is wasted and the most important caveat leads.

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, no-output-schema tool whose annotations already signal destructiveness and idempotency, the description covers scope, irreversibility, and input provenance. The remaining gap is the missing contrast with the non-force delete tool, which matters given how many similar delete siblings exist.

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 baseline is 3. The sentence about sourcing groups 'as returned by ncloud_get_rules_by_monitor_group' reinforces the schema's own description of the nested rule list but adds no new format or constraint detail beyond it, and prodKey/confirm receive no elaboration.

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?

Specifies a concrete verb and resource (force delete monitoring target groups) plus the cascade scope ('together with ALL event rules related to them'), which is genuinely differentiating information. However, it never names the non-force sibling ncloud_delete_monitor_group, so the agent must infer why 'force' is needed rather than being told.

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?

Usage is only implied: 'Force' and the cascade wording hint at when this is appropriate, and 'Pass the groups as returned by ncloud_get_rules_by_monitor_group' tells the agent how to source input, not when to choose this over ncloud_delete_monitor_group or the metrics-group equivalents. No explicit when-to-use or when-not guidance is given.

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