Skip to main content
Glama
deenesjakoruzh
aliyun

Alibaba Cloud DMS MCP Server

Official
by aliyun
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

AlibabaCloud DMS MCP Server

AI-Era Data Security Access Gateway ｜Intelligent Data Query Engine｜Supports 40+ Data Sources

Core Features

Secure Access

  • Account and Password Security Management：Safely manage database account passwords without manual maintenance, effectively preventing sensitive information leakage.

  • Intranet Access Support：Enables database access through an internal network, keeping data within the premises and significantly enhancing data security and privacy protection.

  • Fine-grained Permission Control：Supports instance, database, table, field, and row-level access control, precisely restricting caller permissions to prevent unauthorized operations and ensure data security.

  • High-risk SQL Identification and Blocking: Built-in rich rule engine that identifies and blocks potential high-risk SQL in real time to mitigate security risks.

  • SQL Audit Trail: Records all SQL operation logs, supporting full traceability and compliance audits to meet regulatory requirements.

Intelligent Data Inquiry

  • Built-in NL2SQL Algorithm: Based on natural language input questions, it intelligently matches data tables, understands business semantics within tables, generates and executes SQL queries, and quickly obtains results.

  • Personalized Knowledge Base: Built-in metadata and knowledge base for data inquiry, supports custom business knowledge and query patterns to build tailored intelligent data inquiry capabilities aligned with business scenarios.

Multi-data Source Support

  • Wide Range of Data Source Support: Supports over 40 mainstream databases/data warehouses, enabling unified access and integration from multiple sources.

  • Unified Management Across Environments: Supports centralized management of database instances across development, testing, and production environments to improve operational efficiency.

  • Seamless Integration Across Platforms: Covers major cloud platforms such as Alibaba Cloud and AWS, as well as self-built databases/data warehouses, effectively reducing maintenance costs.

Related MCP server: MCP TapData Server

Supported Ecosystem

  • Supports all Alibaba Cloud data sources: RDS, PolarDB, ADB series, Lindorm series, TableStore series, Maxcompute series.

  • Supports mainstream databases/data warehouses: MySQL, MariaDB, PostgreSQL, Oracle, SQLServer, Redis, MongoDB, StarRocks, Clickhouse, SelectDB, DB2, OceanBase, Gauss, BigQuery, etc.

Core Architecture

Usage Methods

DMS MCP Server currently supports two usage modes.

Mode One: Multi-instance Mode

  • Supports adding instances to DMS, allowing access to multiple database instances.

  • Suitable for scenarios where managing and accessing multiple database instances is required.

Scenario Example:

You are a company DBA who needs to manage and access various types of database instances (e.g., MySQL, Oracle, PostgreSQL) in production, test, and development environments. With DMS MCP Server, you can achieve unified access and centralized management of these heterogeneous databases.

Typical Question Examples:

  • Which of my instances are in the production environment?

  • Get a list of all databases named test.

  • Retrieve details of the test_db database from the myHost:myPort instance.

  • What tables are in the test_db database?

  • Use a tool to query data from the test_db database and answer: "What is today's user traffic?"

Mode Two: Single Database Mode

  • Directly specify the target database by configuring the CONNECTION_STRING parameter in the server (format: dbName@host:port).

  • Suitable for scenarios that focus on accessing a single database.

Scenario Example 1:

You are a developer who frequently accesses a fixed database (e.g., mydb@192.168.1.100:3306) for development and testing. Set the CONNECTION_STRING parameter in the DMS MCP Server configuration as follows: 

CONNECTION_STRING = mydb@192.168.1.100:3306

Afterward, every time the service starts, the DMS MCP Server will directly access this specified database without needing to switch instances.

Typical Question Examples:

  • What tables do I have?

  • Show the field structure of the test_table table.

  • Retrieve the first 20 rows from the test_table table.

  • Use a tool to answer: "What is today's user traffic?"

Scenario Example 2:

You are a data analyst at an e-commerce company, needing to frequently query and analyze business data such as orders, users, and products. The company's core business database is located at ecommerce@10.20.30.40:3306.

Configure the following parameters in DMS MCP Server:

CONNECTION_STRING = ecommerce@10.20.30.40:3306

Simply ask questions in natural language, and DMS MCP will parse the question into SQL and return the results.

Typical Question Examples:

  • What is the total number of orders today?

  • How are the order counts ranked by province?

  • What is the number of new users each day over the past 7 days?

  • Which product category has the highest sales revenue?

Tool List

Tool Name

Description

Applicable Mode

addInstance

Adds an instance to DMS. Only Aliyun instances are supported.

Multi-instance Mode

listInstances

Search for instances from DMS.

Multi-instance Mode

getInstance

Retrieves detailed information about an instance based on host and port.

Multi-instance Mode

searchDatabase

Searches databases based on schemaName.

Multi-instance Mode

getDatabase

Retrieves detailed information about a specific database.

Multi-instance Mode

listTables

Lists tables under a specified database.

Multi-instance Mode & Single Database Mode

getTableDetailInfo

Retrieves detailed information about a specific table.

Multi-instance Mode & Single Database Mode

executeScript

Executes an SQL script and returns the result.

Multi-instance Mode & Single Database Mode

createDataChangeOrder

Creates a data change order in DMS.

Multi-instance Mode & Single Database Mode

getOrderInfo

Retrieves order information from DMS.

Multi-instance Mode & Single Database Mode

submitOrderApproval

Submits the order for approval in DMS.

Multi-instance Mode & Single Database Mode

approveOrder

Approves or rejects an order in DMS.

Multi-instance Mode & Single Database Mode

generateSql

Converts natural language questions into SQL queries.

Multi-instance Mode

askDatabase

Natural language querying of a database (NL2SQL + execute SQL).

Single Database Mode

fixSql

Analyzes and fixes SQL errors.

Multi-instance Mode & Single Database Mode

answerSqlSyntax

Answers SQL syntax-related questions.

Multi-instance Mode & Single Database Mode

optimizeSql

Analyzes and optimizes SQL performance.

Multi-instance Mode & Single Database Mode

Supported Data Sources

DataSource/Tool

NL2SQL nlsql

Execute script executeScript

Show schema getTableDetailInfo

Access control default

Audit log default

MySQL

✅

✅

✅

✅

✅

MariaDB

✅

✅

✅

✅

✅

PostgreSQL

✅

✅

✅

✅

✅

Oracle

✅

✅

✅

✅

✅

SQLServer

✅

✅

✅

✅

✅

Redis

❌

❌

✅

✅

✅

MongoDB

❌

❌

✅

✅

✅

StarRocks

✅

✅

✅

✅

✅

Clickhouse

✅

✅

✅

✅

✅

SelectDB

✅

✅

✅

✅

✅

DB2

✅

✅

✅

✅

✅

OceanBase

✅

✅

✅

✅

✅

Gauss

✅

✅

✅

✅

✅

BigQuery

✅

✅

✅

✅

✅

PolarDB

✅

✅

✅

✅

✅

PolarDB-X

✅

✅

✅

✅

✅

AnalyticDB

✅

✅

✅

✅

✅

Lindorm

✅

✅

✅

✅

✅

TableStore

❌

❌

✅

✅

✅

Maxcompute

✅

✅

✅

✅

✅

Hologres

✅

✅

✅

✅

✅

Prerequisites

Pre-configuration

Before accessing a database instance via DMS, you must first add the instance to DMS.

There are two methods to add an instance:

Method One: Use the addInstance tool provided by DMS MCP to add an instance
The DMS MCP Server provides the addInstance tool for quickly adding an instance to DMS.
For more details, see the description of the addInstance tool in the "Tool List."

Method Two: Add an instance via the DMS console

  1. Log in to the DMS Console.

  2. On the home page of the console, click the Add Instance icon in the database instance area on the left.

  3. On the Add Instance page, enter the instance information (e.g., instance address, port, username, password).

  4. Click Submit to complete the instance addition.

Getting Started

Option 1: Run from Source Code

Download the Code

git clone https://github.com/aliyun/alibabacloud-dms-mcp-server.git

Configure MCP Client

Add the following content to the configuration file:

Multi-instance Mode

{
  "mcpServers": {
    "dms-mcp-server": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/alibabacloud-dms-mcp-server/src/alibabacloud_dms_mcp_server",
        "run",
        "server.py"
      ],
      "env": {
        "ALIBABA_CLOUD_ACCESS_KEY_ID": "access_id",
        "ALIBABA_CLOUD_ACCESS_KEY_SECRET": "access_key",
        "ALIBABA_CLOUD_SECURITY_TOKEN": "sts_security_token optional, required when using STS Token"
      }
    }
  }
}

Single Database Mode

{
  "mcpServers": {
    "dms-mcp-server": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/alibabacloud-dms-mcp-server/src/alibabacloud_dms_mcp_server",
        "run",
        "server.py"
      ],
      "env": {
        "ALIBABA_CLOUD_ACCESS_KEY_ID": "access_id",
        "ALIBABA_CLOUD_ACCESS_KEY_SECRET": "access_key",
        "ALIBABA_CLOUD_SECURITY_TOKEN": "sts_security_token optional, required when using STS Token",
        "CONNECTION_STRING": "dbName@host:port"
      }
    }
  }
}

Option 2: Run via PyPI Package

Multi-instance Mode

{
  "mcpServers": {
    "dms-mcp-server": {
      "command": "uvx",
      "args": [
        "alibabacloud-dms-mcp-server@latest"
      ],
      "env": {
        "ALIBABA_CLOUD_ACCESS_KEY_ID": "access_id",
        "ALIBABA_CLOUD_ACCESS_KEY_SECRET": "access_key",
        "ALIBABA_CLOUD_SECURITY_TOKEN": "sts_security_token optional, required when using STS Token"
      }
    }
  }
}

Single Database Mode

{
  "mcpServers": {
    "dms-mcp-server": {
      "command": "uvx",
      "args": [
        "alibabacloud-dms-mcp-server@latest"
      ],
      "env": {
        "ALIBABA_CLOUD_ACCESS_KEY_ID": "access_id",
        "ALIBABA_CLOUD_ACCESS_KEY_SECRET": "access_key",
        "ALIBABA_CLOUD_SECURITY_TOKEN": "sts_security_token optional, required when using STS Token",
        "CONNECTION_STRING": "dbName@host:port"
      }
    }
  }
}

Contact us

For any questions or suggestions, join the Alibaba Cloud DMS MCP Group (DingTalk Group ID: 129600002740) .

Security

Network Binding

This MCP Server only binds to 127.0.0.1 (localhost). It does not support remote network access. All connections must originate from the local machine. This design ensures that even if the server is accidentally started, it will not be exposed to the network.

SQL Execution Disclaimer

IMPORTANT: This tool is designed to provide full SQL execution capabilities, including SELECT, INSERT, UPDATE, DELETE, and DDL statements.

By using this MCP Server, you acknowledge and accept the following:

  1. You are solely responsible for ensuring that the AK/SK (AccessKey) used has appropriate, minimal permissions configured in Alibaba Cloud RAM.

  2. It is strongly recommended to enable DMS Safe Hosting Mode for your database instances, which provides built-in SQL review, risk identification, and approval workflows.

  3. The maintainers of this project are not responsible for any data loss, corruption, or security incidents resulting from SQL execution through this tool.

  4. Best practices:

    • Use read-only AK/SK for query-only scenarios

    • Enable DMS fine-grained permission control

    • Enable SQL audit logging for compliance

    • Regularly review and rotate access credentials

Security Design

  • No command injection risk: The codebase does not use subprocess, os.system, eval(), or exec(). All operations are performed through the Alibaba Cloud SDK.

  • No SSRF risk: All network requests are sent to a fixed Alibaba Cloud endpoint (dms-enterprise.cn-hangzhou.aliyuncs.com) via the SDK. No user-controlled URLs are fetched.

  • Input validation: Search interfaces validate input length and reject potentially dangerous SQL patterns to prevent injection through non-SQL-execution interfaces.

License

This project is licensed under the Apache 2.0 License.

Agent Skills (Independent of MCP)

In addition to the MCP Server, this project also hosts AI Agent skills for DMS Enterprise. These skills enable any AI agent (Codex, ChatGPT, Cursor, etc.) to manage DMS resources directly via OpenAPI — no MCP protocol required.

Quick Start (Skills)

  1. Read the skill definition:
    skills/database/dms/alicloud-database-dms-enterprise/SKILL.md

  2. Discover available APIs:

    python3 skills/database/dms/alicloud-database-dms-enterprise/scripts/list_openapi_meta_apis.py

  3. Configure AccessKey:

    export ALICLOUD_ACCESS_KEY_ID="your-ak"
export ALICLOUD_ACCESS_KEY_SECRET="your-sk"
export ALICLOUD_REGION_ID="cn-hangzhou"

Skill Capabilities

Category

Operations

Instance Management

Register, list, update, delete database instances

SQL Execution & Audit

Execute scripts, NL2SQL, SQL review & optimization

Permission Management

Create permission orders, grant/revoke user permissions

Data Security

Sensitive column identification, data masking, audit logs

Task Orchestration

Create, execute, monitor task flows (DAG)

Metadata Knowledge

Get/edit table business knowledge

Prompt Examples

See skills/examples/prompts/ for DMS scenario-based prompt templates:

  • Instance management & resource query

  • SQL execution & audit

  • Permission & security management

  • Task orchestration & data changes

  • API discovery & metadata

Skill Index

Category

Skill

Description

Path

database/dms

alicloud-database-dms-enterprise

Manage Alibaba Cloud Data Management Service (DMS Enterprise) via OpenAPI. Use for database instance management, SQL audit, data security, task orchestration, sensitive data protection, permission management, and database operation workflows.

skills/database/dms/alicloud-database-dms-enterprise

For agent-specific guidelines, see AGENTS.md.

Available Tools

16 tools
addInstanceA

Add an instance to DMS. The username and password are required. Only Aliyun instances are supported. Either instance_resource_id or host and port must be provided. The region is optional, but it's recommended to include it.If the instance already exists, it will return the existing instance information.

ParametersJSON Schema
NameRequiredDescriptionDefault
db_userYesThe username used to connect to the database
db_passwordYesThe password used to connect to the database
instance_resource_idNoAliyun instance resource ID
hostNoThe hostname of the database instance
portNoThe connection port number
regionNoThe region (e.g., 'cn-hangzhou')

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses important behavioral traits: it is an upsert (returns existing instance if already exists), and it only supports Aliyun instances. Annotations indicate it is not read-only and not destructive, which aligns with the description. No contradictions.

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 concise (two sentences) and front-loaded with the primary action. Every sentence provides valuable information without redundancy.

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

Completeness5/5

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

The description covers all necessary aspects for an add tool: behavior (upsert), required parameters, parameter alternatives, and constraints. With no output schema, it adequately explains the return behavior. The six parameters are all addressed.

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 description adds meaning beyond the schema by explaining the combinatorial requirement ('Either instance_resource_id or host and port must be provided') and the optionality of region. Schema coverage is 100%, but the description clarifies usage constraints.

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 'Add an instance to DMS' and specifies required fields, supported cloud (Aliyun only), and alternative parameter combinations. It distinguishes from siblings like getInstance and listInstances by focusing on creation/upsert.

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 clear context on when to use: for adding Aliyun instances, with required username/password, and two mutually exclusive parameter sets. It does not explicitly mention when not to use or name alternatives, but the context is sufficient for an agent to infer.

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

answerSqlSyntaxA
Read-only

Answer syntax-related questions for the corresponding database engine based on the database ID.If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
questionYesNatural language question
modelNoOptional: if a specific model is desired, it can be specified here

TDQS

A3.9/5.0
Behavior3/5

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

The description confirms the non-destructive nature (consistent with readOnlyHint annotation) but adds minimal behavioral detail beyond that. It does not discuss response format, constraints, or potential side effects, relying heavily on the annotation for safety disclosure.

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 compact and well-structured: a single introductory sentence followed by a clear bulleted decision tree. Every sentence contributes value, and there is no redundant or extraneous information.

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?

While the description explains how to get the database_id, it does not describe what the answer looks like (e.g., format, length, examples) or mention limitations. Given the lack of an output schema and the tool's Q&A nature, additional completeness would be beneficial.

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?

The input schema covers all three parameters with descriptions (100% coverage), but the descriptions are terse. The tool description adds context that the question should be about syntax for the given database engine, which enhances meaning beyond the schema. However, it does not detail parameter formats or expected values significantly.

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 purpose: answering syntax-related questions for a specific database engine based on a database ID. This distinguishes it from sibling tools like fixSql or generateSql, which handle different tasks.

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 explicit steps for obtaining the required database_id via getDatabase or searchDatabase, including decision criteria. While it doesn't contrast against sibling tools for when to use this tool itself, the guidance for prerequisites is clear and actionable.

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

approveOrderB

Approve or reject an order in DMS. The workflow_instance_id can be obtained from getOrderInfo.

ParametersJSON Schema
NameRequiredDescriptionDefault
workflow_instance_idYesApproval workflow ID, can be obtained from getOrderInfo API
approval_typeYesApproval action: AGREE (approve), CANCEL (cancel), REJECT (reject)
commentNoComment for the approval actionOrder approved via MCP

TDQS

B3.3/5.0
Behavior2/5

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

Annotations already indicate readOnlyHint=false, and the description confirms a mutating action. However, it adds no further behavioral context such as success/failure outcomes, idempotency, or permission requirements. Without annotations, the description would be insufficient.

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 extremely concise with two sentences, the first stating the purpose and the second providing a useful hint. No redundant information.

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?

For a simple approval tool, the description covers the basics. However, it lacks any mention of return values or side effects, and the sibling submitOrderApproval might require differentiation. Given no output schema, more detail could help.

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?

The schema already describes all parameters with 100% coverage. The description adds only a single hint about the source of workflow_instance_id. Since baseline is 3 for high coverage, this is adequate but not additive.

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?

The description clearly states the tool approves or rejects an order in DMS, specifying the action and resource. It does not explicitly differentiate from the sibling tool 'submitOrderApproval', but the purpose is specific and unambiguous.

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 description provides a useful hint that workflow_instance_id comes from getOrderInfo, guiding usage. However, it offers no guidance on when to prefer this tool over alternatives like submitOrderApproval, and does not mention any conditions or prerequisites.

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

createDataChangeOrderA
Destructive

Execute SQL changes through a data change order, and a corresponding order ID will be returned. Prefer using the executeScript tool for SQL execution;only use this tool when explicitly instructed to perform the operation via a order.If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesRequired DMS databaseId. Obtained via getDatabase tool
scriptYesSQL script to execute
logicNoWhether to use logical execution mode
commentNoBusiness context for the data change orderData correct order submitted by MCP

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds that an order ID is returned and includes prerequisite steps. No contradiction with 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?

Description is concise and front-loaded with purpose, then structured with numbered guidelines. Every sentence adds value without redundancy.

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?

Covers when to use, how to prepare inputs, and what output to expect. Lacks details on error handling or output structure, but sufficient given 4 parameters and no output schema.

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 coverage is 100% with clear descriptions. The description adds marginal value by linking database_id to getDatabase/searchDatabase tools, but adds little beyond the schema for other parameters.

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 executes SQL changes through a data change order and returns an order ID. It distinguishes from sibling 'executeScript' by specifying when to use each.

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

Usage Guidelines5/5

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

Explicitly states to prefer 'executeScript' for general SQL execution and to use this only when instructed to operate via an order. Also provides step-by-step guidance for obtaining the required database_id.

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

executeScriptA
Destructive

Execute SQL script against a database in DMS and return structured results.If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesRequired DMS databaseId. Obtained via getDatabase tool
scriptYesSQL script to execute
logicNoWhether to use logical execution mode

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already indicate destructiveHint=true, so the description's lack of additional safety warnings is acceptable. However, it does not mention potential long execution time or error behavior, relying on the structured results claim.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the purpose, followed by clear numbered steps. Minor redundancy but overall well-structured.

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?

No output schema exists, so the description's vague 'structured results' leaves some ambiguity. Also lacks details on error handling or performance implications, but the step-by-step ID retrieval helps compensate.

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 input schema has 100% description coverage for all parameters. The description adds value by explaining how to obtain the database_id via other tools, supplementing the schema's 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 clearly states the tool executes a SQL script against a database and returns structured results, distinguishing it from sibling tools like getDatabase and searchDatabase which retrieve database IDs.

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

Usage Guidelines5/5

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

Provides explicit step-by-step guidance on obtaining the databaseId using getDatabase or searchDatabase, including handling multiple search results and asking the user for missing info.

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

fixSqlA
Read-only

Analyze and fix the SQL error based on the provided SQL statement, error message, and database ID.If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
questionNoNatural language question
sqlYesThe SQL that caused an error
errorYesSQL error message
modelNoOptional: if a specific model is desired, it can be specified here

TDQS

A4.2/5.0
Behavior4/5

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

Annotations set readOnlyHint=true, and the description does not contradict. It adds context about using getDatabase/searchDatabase but does not explicitly state the tool only returns a fixed SQL without modification. Still clear enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with numbered steps that are front-loaded. Could be slightly more concise, but every sentence adds value.

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?

Covers core usage and prerequisite tools, but misses explaining optional parameters and does not describe the output (fixed SQL). With no output schema, this is a gap.

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 coverage is 100%, so the baseline is 3. The description mentions database ID, SQL, and error but does not add new information about the optional question or model parameters beyond what schema provides.

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 'Analyze and fix the SQL error' with specific resources (SQL statement, error message, database ID). This distinguishes it from siblings like generateSql or optimizeSql.

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

Usage Guidelines5/5

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

Provides explicit steps for retrieving databaseId using getDatabase or searchDatabase, including when to ask the user. This guides the agent on prerequisites and alternative tools.

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

generateSqlA
Read-only

Generate SELECT-type SQL queries from natural language input.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
questionYesNatural language question
knowledgeNoOptional: additional context
modelNoOptional: if a specific model is desired, it can be specified here

TDQS

A3.7/5.0
Behavior3/5

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

No annotation contradiction. Description mentions generation of SELECT SQL, but does not disclose whether queries are executed or just returned, nor any behavioral traits like required permissions or side effects. Annotations provide readOnlyHint but description adds minimal context.

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?

Single sentence clearly front-loads the purpose. No unnecessary words or information, every word earns its place.

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?

No output schema, so description should compensate. It does not explain what the tool returns (e.g., SQL string, results). Despite 4 parameter descriptions in schema, the description lacks completeness about the tool's overall behavior and return format.

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% for all parameters. The description adds no additional meaning beyond what the input schema already provides, resulting in baseline score.

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?

Description clearly states the tool generates SELECT-type SQL queries from natural language, specifying verb, resource, and constraint. It distinguishes from siblings like fixSql or optimizeSql.

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?

No explicit guidance on when to use this tool versus alternatives like fixSql or answerSqlSyntax. The description implies use for natural language to SQL generation, but lacks when-not-to or context of sibling tools.

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

getDatabaseB
Read-only

Obtain detailed information about a specific database in DMS when the host and port are provided.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYesHostname or IP of the database instance
portYesConnection port number
schema_nameYesName of the database schema
sidNoRequired for Oracle like databases

TDQS

B3.3/5.0
Behavior3/5

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

Annotations declare readOnlyHint=true, so the description's 'obtain detailed information' is consistent and signals a read operation. No additional behavioral traits disclosed (e.g., error handling, data freshness). With annotations covering safety, a 3 is appropriate.

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?

Single sentence that is front-loaded and contains no fluff. Every word is necessary and directly states the tool's purpose.

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?

No output schema, so description should hint at return values, but only says 'detailed information'. For a tool with 4 parameters and no output schema, more completeness would be expected (e.g., what fields are returned). Adequate but not complete.

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?

Input schema has 100% description coverage for all parameters, so the schema already provides semantic meaning. The description does not add any param-specific details beyond what is in the schema.

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?

The description clearly states it obtains detailed information about a specific database, using host and port. It differentiates from sibling tools like getInstance and listInstances by focusing on a specific database connection, but does not explicitly name alternatives.

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?

No guidance on when to use this tool vs alternatives like searchDatabase or listInstances. The only usage hint is that host and port are required, which is already in the schema. Missing when-not-to-use context.

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

getInstanceA
Read-only

Retrieve detailed instance information from DMS using the host and port.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYesThe hostname of the database instance
portYesThe connection port number
sidNoRequired for Oracle like databases

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description adds some context ('from DMS', 'using host and port') but does not elaborate on return format, error behavior, or the meaning of 'detailed'.

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 a single, concise sentence of 10 words with no redundant phrases. It is appropriately front-loaded.

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?

Given no output schema, the description could hint at return style (e.g., JSON object), but it does not. It adequately covers the input requirements but lacks detail on output format.

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 coverage is 100%, so baseline is 3. The description mentions host and port but not the optional sid parameter; it adds minimal semantic value beyond what the schema descriptions already provide.

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 action ('Retrieve'), resource ('detailed instance information'), and source ('from DMS'), distinguishing it from sibling tools like listInstances (which lists) and addInstance (which creates).

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?

The description provides no guidance on when to use this tool versus alternatives such as listInstances or getDatabase. It does not mention prerequisites or exclude scenarios.

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

getOrderInfoA
Read-only

Retrieve order information from DMS using the order ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
order_idYesDMS order ID

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description's 'Retrieve' aligns. No additional behavioral details are provided (e.g., error handling, response format), but the burden is lower due to 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?

A single, front-loaded sentence with zero wasted words. Every part is essential.

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 simple retrieval tool with one parameter, the description is sufficient. It could optionally mention the return type, but without an output schema, it's not required.

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% with 'DMS order ID'. The description's mention of 'using the order ID' adds no new meaning beyond the schema. Baseline 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 verb ('Retrieve'), the resource ('order information from DMS'), and the key input ('using the order ID'). This distinguishes it from sibling tools that handle other order operations like approval or creation.

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 description implies usage when you have an order ID, but does not provide explicit guidance on when to choose this tool over alternatives or mention any prerequisites or limitations.

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

getTableDetailInfoA
Read-only

Retrieve detailed metadata information about a specific database table including schema and index details. If you don't know the table_guid parameter, retrieve it using listTables.

ParametersJSON Schema
NameRequiredDescriptionDefault
table_guidYesUnique table identifier (format: dmsTableId.schemaName.tableName),Example: IDB_1567890.mySchema.myTable

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the description's 'retrieve' claim is consistent and adds no additional behavioral insights (e.g., performance, permissions). Minimal extra value beyond structured fields.

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 sentences: first states purpose, second provides actionable guidance. No filler, information is front-loaded.

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?

No output schema, but the description mentions specific details (schema, index). Could further describe return format, but given single simple parameter and sibling reference, it is sufficiently complete.

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 coverage is 100% with a detailed description and example for table_guid. The description adds only a usage hint for the parameter, not additional semantic meaning beyond the schema.

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 uses a clear verb ('Retrieve') and resource ('detailed metadata information about a specific database table including schema and index details'). It distinguishes from sibling 'listTables' by explicitly providing guidance to use listTables if the guid is unknown.

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 directs the agent to use listTables when the parameter is unknown, offering clear context. It lacks explicit 'when not to use' guidance, but the cross-reference is sufficient for effective selection.

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

listInstancesC
Read-only

Search for instances from DMS.

ParametersJSON Schema
NameRequiredDescriptionDefault
search_keyNoOptional search key (e.g., instance host, instance alias, etc.)
db_typeNoOptional instanceType, or called dbType (e.g., mysql, polardb, oracle, postgresql, sqlserver, polardb-pg, etc.)
env_typeNoOptional instance environment type (e.g., product, dev, test, etc. )

TDQS

C2.9/5.0
Behavior2/5

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

The readOnlyHint annotation already indicates idempotent read behavior. The description adds no further behavioral details, such as pagination, result limits, or filtering behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with purpose. Could benefit from slightly more detail without harming conciseness.

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

Completeness2/5

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

For a search tool with three optional parameters and no output schema, the description is too sparse. It does not clarify what the output is (e.g., list of instance objects), nor any ordering or default behavior.

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 schema already explains each parameter. The description adds no extra meaning beyond what the schema provides, but it does not degrade it either.

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?

The description clearly states the action ('Search') and the resource ('instances from DMS'). It distinguishes from siblings like getInstance (specific instance) and searchDatabase (different resource), though it could be more precise about what constitutes an instance.

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?

No guidance on when to use this tool versus alternatives (e.g., getInstance, searchDatabase). The description does not mention use cases, preconditions, or exclusions.

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

listTablesA
Read-only

Search for tables by databaseId and (optional) table name. If you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
search_nameNoOptional: Search keyword for table names
page_numberNoPagination page number
page_sizeNoResults per page (max 200)

TDQS

A4.4/5.0
Behavior4/5

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

Description is consistent with readOnlyHint annotation (search operation). Adds context about pagination via page_number and page_size, though these are already in schema. No mention of what happens with no results or error states, but overall adequate for a read-only tool.

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?

Description is multi-sentence but well-organized with numbered steps for different scenarios. Front-loaded with main purpose, then clear conditional guidance. No superfluous sentences.

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?

While output schema is absent, the description provides enough context for selecting and invoking the tool. It covers prerequisites (databaseId), optional filtering, and pagination. Missing explicit description of return format, but common for list operations.

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?

All 4 parameters have descriptions in the schema (100% coverage). The description does not add significant meaning beyond schema; it restates that database_id is required and search_name is optional. Baseline 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?

Clearly states 'Search for tables by databaseId and (optional) table name.' Verb 'search' and resource 'tables' are specific. Distinguishes from siblings like getDatabase and searchDatabase by explaining when to use those instead.

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

Usage Guidelines5/5

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

Provides explicit step-by-step guidance: if databaseId unknown, use getDatabase (if exact) or searchDatabase (if only name). Also warns that searchDatabase may return multiple results, recommending user confirmation. This is comprehensive and helpful.

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

optimizeSqlA
Read-only

Analyze and optimize SQL performance based on the provided SQL statement and database IDIf you don't know the databaseId, first use getDatabase or searchDatabase to retrieve it. (1) If you have the exact host, port, and database name, use getDatabase. (2) If you only know the database name, use searchDatabase. (3) If you don't know any information, ask the user to provide the necessary details. Note: searchDatabase may return multiple databases. In this case, let the user choose which one to use.

ParametersJSON Schema
NameRequiredDescriptionDefault
database_idYesDMS databaseId
questionNoNatural language question
sqlYesSQL statement
modelNoOptional: if a specific model is desired, it can be specified here

TDQS

A4.4/5.0
Behavior4/5

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

Annotations mark readOnlyHint=true, and description says 'optimize' which could imply modification; however, context suggests analysis. Lacks explicit statement that no changes are made to the database. Still mostly transparent given 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?

Concise first sentence states purpose, followed by clear bullet points for workflow. No redundant information, well-organized.

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?

Covers purpose, prerequisites, and parameter workflow. Lacks description of output/return value, which is important since no output schema exists. Otherwise complete for usage context.

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?

Input schema has 100% coverage with descriptions for all parameters. Description adds value for database_id by providing usage workflow, but does not significantly enhance semantics of other parameters beyond schema.

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?

Clearly states verb 'analyze and optimize', resource 'SQL performance', and required parameters (SQL statement and database ID). Distinguishes from siblings like fixSql, generateSql, answerSqlSyntax.

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

Usage Guidelines5/5

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

Explicit step-by-step guidance on obtaining databaseId using getDatabase or searchDatabase, including fallback to ask user. Also notes that searchDatabase may return multiple results, requiring user selection. Clearly indicates when to use this tool vs alternatives.

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

searchDatabaseA
Read-only

Search databases in DMS by name.

ParametersJSON Schema
NameRequiredDescriptionDefault
search_keyYesdatabase name to search for
page_numberNoPage number (starting from 1)
page_sizeNoResults per page (max 1000)

TDQS

A3.8/5.0
Behavior3/5

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

The annotation readOnlyHint=true already signals a read-only operation. The description adds no additional behavioral traits beyond what annotations provide, such as potential limits on search results or pagination behavior. Since annotations cover the read-only nature, a score of 3 is appropriate.

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 a single concise sentence that front-loads the key purpose. No extraneous words; every word earns its place.

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

Completeness2/5

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

The description lacks details on what the search returns (e.g., list of database names, full details?). There is no output schema, so the description should clarify the return format. Sibling tools like getDatabase hint at richer outputs, but searchDatabase leaves the result ambiguous.

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% with all three parameters described (search_key, page_number, page_size). The description does not add extra meaning beyond the schema; it mentions 'by name' which maps to search_key, but the schema already states that. Thus baseline 3.

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 action (search), the resource (databases), and the context (by name in DMS). This distinguishes it from sibling tools like getDatabase (single database retrieval) and listInstances (list instances).

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 implies usage when searching databases by name, but does not explicitly describe when to use it over alternatives like getDatabase or listInstances, nor does it provide exclusions. The context is clear but lacks explicit guidance.

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

submitOrderApprovalA

Submit the order for approval in DMS using the order ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
order_idYesDMS order ID

TDQS

A3.5/5.0
Behavior2/5

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

Annotations indicate readOnlyHint=false, consistent with a write operation. However, the description adds no behavioral details beyond stating the action—e.g., what triggers, permissions needed, or side effects.

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?

Single sentence, no unnecessary words. Efficient and to the point.

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?

Given low complexity (1 param, no output schema), the description is minimal but lacks context about order state or workflow integration. Adequate but not thorough.

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 coverage is 100% with one parameter described as 'DMS order ID'. The description repeats this without adding new meaning. Baseline 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 action ('Submit') and the resource ('order for approval') using a specific identifier ('order ID'). It effectively distinguishes from sibling tools like 'approveOrder' and 'createDataChangeOrder'.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., 'approveOrder'). The context is implied but lacks exclusions or prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.2.11
    • AddedapproveOrder
    • ChangedcreateDataChangeOrder1 field changed
      • addedInput schema / properties / comment
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": "Data correct order submitted by MCP",
+  "description": "Business context for the data change order",
+  "title": "Comment"
+}
  2. 4 tool updatesv1.0.0
    • AddedanswerSqlSyntax
    • AddedfixSql
    • ChangedgenerateSql2 fields changed
      • changedInput schema / properties / knowledge / description
        Previous value: -"Additional context"New value: +"Optional: additional context"
      • addedInput schema / properties / model
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional: if a specific model is desired, it can be specified here",
+  "title": "Model"
+}
    • AddedoptimizeSql
  3. 12 tool updates
    • First observedaddInstance
    • First observedcreateDataChangeOrder
    • First observedexecuteScript
    • First observedgenerateSql
    • First observedgetDatabase
    • First observedgetInstance
    • First observedgetOrderInfo
    • First observedgetTableDetailInfo
    • First observedlistInstances
    • First observedlistTables
    • First observedsearchDatabase
    • First observedsubmitOrderApproval
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose: instance management, database retrieval, SQL execution, SQL analysis (fix, optimize, generate, syntax), and order processing. Overlapping tools like executeScript and createDataChangeOrder are differentiated by direct vs. order-based execution, with clear descriptions.

Naming Consistency5/5

All tools follow a verb_noun pattern in camelCase (e.g., addInstance, executeScript, getDatabase, listInstances). The naming is predictable and consistent, with no mixing of styles or unclear abbreviations.

Tool Count4/5

16 tools is slightly above the ideal 3-15 range but still well-scoped for the DMS domain. Each tool serves a specific function without redundancy, and the count reflects a comprehensive feature set without being overwhelming.

Completeness3/5

The tool set covers core operations: instance CRUD (get, list, add but no delete/update), database queries, SQL analysis, and order management. Missing operations like instance/database deletion or user management create notable gaps, but the core workflow is supported.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Superset MCP Server

    LiusCraft
    F
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol server that enables large language models to interact with Apache Superset databases through REST API, supporting database queries, table lookups, field information retrieval, and SQL execution.
    4
    5
    -
  • MCP TapData Server by tapdata

    MCP TapData Serverofficial

    tapdata
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables Large Language Models to access and interact with database connections, including viewing schemas and performing CRUD operations on connected databases.
    -
  • ExecuteAutomation Database Server by executeautomation

    ExecuteAutomation Databaseofficial

    executeautomation
    A
    license
    Not graded
    quality
    F
    maintenance
    A Model Context Protocol server that enables LLMs like Claude to interact with SQLite and SQL Server databases, allowing for schema inspection and SQL query execution.
    806
    380
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aliyun/alibabacloud-dms-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server