ncloud-mcp-server

ncloud_create_mysql_recovery

Restore a Cloud DB for MySQL instance by creating a recovery server from a backup file or a specific point-in-time.

Instructions

Create a Recovery server instance for a Cloud DB for MySQL instance. Restores from backup file or point-in-time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cloudMysqlInstanceNo": "<cloudMysqlInstanceNo>",
      "cloudMysqlRecoveryServerName": "<cloudMysqlRecoveryServerName>"
    },
    "name": "ncloud_create_mysql_recovery"
  }
}

Input Schema

Name	Required	Description
`fileName`	No	Backup file name for restore (getCloudMysqlBackupDetailList). If specified, recoveryTime is ignored. One of fileName or recoveryTime is required.
`subnetNo`	No	Subnet number for Recovery server. Required when isMultiZone=true. Ignored when isMultiZone=false.
`regionCode`	No	Region code (default: first region)
`recoveryTime`	No	Point-in-time recovery (yyyy-MM-dd HH:mm). If specified, fileName is ignored. One of fileName or recoveryTime is required.
`cloudMysqlInstanceNo`	Yes	Cloud MySQL instance number (getCloudMysqlInstanceList)
`cloudMysqlRecoveryServerName`	Yes	Recovery server name prefix (3-20 chars, starts with letter, ends with letter/number, allows '-')

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.10.1Jul 29, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations only provide `destructiveHint: false`, which the description does not contradict (creating a recovery server is non-destructive to the source instance). The description adds the key behavioral detail that the tool restores from backup or point-in-time, which is useful beyond the annotation. However, it does not disclose any potential side effects, prerequisites (e.g., needing `cloudMysqlInstanceNo` already exist), or what happens to the original instance. With annotations covering the safety profile, the description adds modest context but not rich behavioral transparency.

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?

The description is two short sentences, front-loaded with the action and resource. Every word earns its place: 'Create a Recovery server instance' identifies the operation, and 'Restores from backup file or point-in-time' clarifies the method. There is no redundancy or filler, making it extremely concise and structured.

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?

Given the tool has 6 parameters and no output schema, the description is reasonably complete: it states the core action and restore methods, while the schema handles parameter details. It does not mention the return value or how to monitor the operation, but for a creation tool that is often acceptable, especially with sibling tools like `ncloud_get_mysql_instance_detail` available for post-creation checks. The description covers the essential decision points, though it could briefly mention the need to specify either `fileName` or `recoveryTime` or reference the prerequisite `cloudMysqlInstanceNo` to be slightly more self-contained.

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 the baseline is 3. The description does not add much beyond the schema: it mentions 'backup file or point-in-time', which loosely maps to `fileName` and `recoveryTime`, but the schema already provides detailed semantics (e.g., mutual exclusivity, format, references to helper tools). Since the schema descriptions are comprehensive and the description adds no new parameter-level meaning, a score of 3 is appropriate.

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 clearly states the tool's action: 'Create a Recovery server instance for a Cloud DB for MySQL instance.' It uses a specific verb ('Create') and a specific resource ('Recovery server instance'), distinguishing it from sibling tools like `ncloud_create_mysql_instance` or `ncloud_create_mysql_slave`. The additional phrase 'Restores from backup file or point-in-time' adds specificity about the recovery purpose, making the tool's function unambiguous.

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

Usage Guidelines4/5

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

The description provides a clear context for when to use this tool: when recovering a Cloud DB for MySQL from a backup or point-in-time. While it does not explicitly name alternatives or exclusions, the phrase 'Restores from backup file or point-in-time' implies the appropriate use case. Given the sibling list includes `ncloud_create_mysql_instance` (creating a new instance) and `ncloud_create_mysql_slave` (creating a replica), the recovery-specific wording serves as sufficient implicit guidance, though it lacks explicit 'when-not' direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server