AI赋能的统一数据管理网关，支持连接30+数据源，作为多云通用数据MCP服务器，一站式解决跨源数据安全访问。
支持阿里云全系列：RDS、PolarDB、ADB系列、Lindorm系列、TableStore系列、MaxCompute系列。
支持主流数据库/仓库：MySQL、MariaDB、PostgreSQL、Oracle、SQLServer、Redis、MongoDB、StarRocks、Clickhouse、SelectDB、DB2、OceanBase、Gauss、BigQuery 等。
为AI提供统一的数据访问层和元数据访问层，通过标准化接口解决：
数据源碎片化导致的维护成本
异构协议之间的兼容性问题
不受控制的账户权限和不可审计的操作带来的安全风险
MCP 的主要功能包括：
NL2SQL ：通过自然语言执行SQL，获取数据结果
代码生成：通过此服务检索模式信息以生成 DAO 代码或执行结构分析
数据检索：自动将 SQL 路由到准确的数据源以支持业务
安全性：细粒度的访问控制和可审计性
Related MCP server: MCP TapData Server
db_user （字符串，必需）：用于连接数据库的用户名。
db_password （字符串，必需）：连接数据库的密码。
instance_resource_id （字符串，可选）：实例的资源 ID，通常由云服务提供商分配。
host （字符串，可选）：实例的连接地址。
port （字符串，可选）：实例的连接端口号。
region （字符串，可选）：实例所在的区域（例如，“cn-hangzhou”）。
host （字符串，必需）：实例的连接地址。
port （字符串，必需）：实例的连接端口号。
sid （字符串，可选）：类似 Oracle 的数据库必需，默认为无。
search_key （字符串，必需）：schemaName。
page_number （整数，可选）：要检索的页码（从 1 开始），默认为 1。
page_size （整数，可选）：每页结果数（最多 1000 条），默认为 200。
host （字符串，必需）：实例的连接地址。
port （字符串，必需）：实例的连接端口号。
schema_name （字符串，必需）：数据库名称。
sid （字符串，可选）：类似 Oracle 的数据库必需，默认为无。
database_id （字符串，必需）：用于限制搜索范围的数据库 ID（通过 getDatabase 获取）。
search_name （字符串，必需）：非空字符串作为搜索关键字来匹配表名。
page_number （整数，可选）：分页页码（默认值：1）。
page_size （整数，可选）：每页的结果数（默认值：200，最大值：200）。
table_guid （字符串，必需）：表的唯一标识符（格式：dmsTableId.schemaName.tableName），通过searchTable或listTable获取。
database_id （字符串，必需）：DMS 数据库 ID（通过 getDatabase 获取）。
脚本（字符串，必需）：要执行的 SQL 脚本内容。
问题（字符串，必需）：要转换为 SQL 的自然语言问题。
database_id （整数，必需）：DMS 数据库 ID（通过 getDatabase 获取）。
知识（字符串，可选）：协助 SQL 生成的附加上下文或数据库知识。
数据源/工具 | NL2SQL nlsql | 执行脚本 executeScript | 显示架构 getTableDetailInfo | 访问控制 默认值 | 审计日志 默认 |
MySQL | ✅ | ✅ | ✅ | ✅ | ✅ |
MariaDB | ✅ | ✅ | ✅ | ✅ | ✅ |
PostgreSQL | ✅ | ✅ | ✅ | ✅ | ✅ |
甲骨文 | ✅ | ✅ | ✅ | ✅ | ✅ |
SQL服务器 | ✅ | ✅ | ✅ | ✅ | ✅ |
Redis | ✅ | ✅ | ✅ | ✅ | ✅ |
MongoDB | ✅ | ✅ | ✅ | ✅ | ✅ |
星石 | ✅ | ✅ | ✅ | ✅ | ✅ |
Clickhouse | ✅ | ✅ | ✅ | ✅ | ✅ |
选择数据库 | ✅ | ✅ | ✅ | ✅ | ✅ |
DB2 | ✅ | ✅ | ✅ | ✅ | ✅ |
OceanBase | ✅ | ✅ | ✅ | ✅ | ✅ |
高斯 | ✅ | ✅ | ✅ | ✅ | ✅ |
BigQuery | ✅ | ✅ | ✅ | ✅ | ✅ |
PolarDB | ✅ | ✅ | ✅ | ✅ | ✅ |
PolarDB-X | ✅ | ✅ | ✅ | ✅ | ✅ |
分析型数据库 | ✅ | ✅ | ✅ | ✅ | ✅ |
林多姆 | ✅ | ✅ | ✅ | ✅ | ✅ |
表格存储 | ✅ | ✅ | ✅ | ✅ | ✅ |
MaxCompute | ✅ | ✅ | ✅ | ✅ | ✅ |
霍洛格雷斯 | ✅ | ✅ | ✅ | ✅ | ✅ |
git clone https://github.com/aliyun/alibabacloud-dms-mcp-server.git在配置文件中添加以下内容：
"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"
}
}
}"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"
}
}
}有任何疑问或建议，欢迎加入阿里云DMS MCP群（钉钉群ID：129600002740）。
该项目采用 Apache 2.0 许可证授权。
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.
| Name | Required | Description | Default |
|---|---|---|---|
| db_user | Yes | The username used to connect to the database | |
| db_password | Yes | The password used to connect to the database | |
| instance_resource_id | No | Aliyun instance resource ID | |
| host | No | The hostname of the database instance | |
| port | No | The connection port number | |
| region | No | The region (e.g., 'cn-hangzhou') |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | DMS databaseId | |
| question | Yes | Natural language question | |
| model | No | Optional: if a specific model is desired, it can be specified here |
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.
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.
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.
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.
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.
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.
Approve or reject an order in DMS. The workflow_instance_id can be obtained from getOrderInfo.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_instance_id | Yes | Approval workflow ID, can be obtained from getOrderInfo API | |
| approval_type | Yes | Approval action: AGREE (approve), CANCEL (cancel), REJECT (reject) | |
| comment | No | Comment for the approval action | Order approved via MCP |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | Required DMS databaseId. Obtained via getDatabase tool | |
| script | Yes | SQL script to execute | |
| logic | No | Whether to use logical execution mode | |
| comment | No | Business context for the data change order | Data correct order submitted by MCP |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | Required DMS databaseId. Obtained via getDatabase tool | |
| script | Yes | SQL script to execute | |
| logic | No | Whether to use logical execution mode |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | DMS databaseId | |
| question | No | Natural language question | |
| sql | Yes | The SQL that caused an error | |
| error | Yes | SQL error message | |
| model | No | Optional: if a specific model is desired, it can be specified here |
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.
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.
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.
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.
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.
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.
Generate SELECT-type SQL queries from natural language input.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | DMS databaseId | |
| question | Yes | Natural language question | |
| knowledge | No | Optional: additional context | |
| model | No | Optional: if a specific model is desired, it can be specified here |
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.
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.
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.
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.
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.
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.
Obtain detailed information about a specific database in DMS when the host and port are provided.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname or IP of the database instance | |
| port | Yes | Connection port number | |
| schema_name | Yes | Name of the database schema | |
| sid | No | Required for Oracle like databases |
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.
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.
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.
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.
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.
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.
Retrieve detailed instance information from DMS using the host and port.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | The hostname of the database instance | |
| port | Yes | The connection port number | |
| sid | No | Required for Oracle like databases |
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.
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.
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.
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.
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.
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.
Retrieve order information from DMS using the order ID.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | DMS order ID |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| table_guid | Yes | Unique table identifier (format: dmsTableId.schemaName.tableName),Example: IDB_1567890.mySchema.myTable |
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.
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.
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.
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.
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.
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.
Search for instances from DMS.
| Name | Required | Description | Default |
|---|---|---|---|
| search_key | No | Optional search key (e.g., instance host, instance alias, etc.) | |
| db_type | No | Optional instanceType, or called dbType (e.g., mysql, polardb, oracle, postgresql, sqlserver, polardb-pg, etc.) | |
| env_type | No | Optional instance environment type (e.g., product, dev, test, etc. ) |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | DMS databaseId | |
| search_name | No | Optional: Search keyword for table names | |
| page_number | No | Pagination page number | |
| page_size | No | Results per page (max 200) |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | DMS databaseId | |
| question | No | Natural language question | |
| sql | Yes | SQL statement | |
| model | No | Optional: if a specific model is desired, it can be specified here |
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.
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.
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.
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.
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.
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.
Search databases in DMS by name.
| Name | Required | Description | Default |
|---|---|---|---|
| search_key | Yes | database name to search for | |
| page_number | No | Page number (starting from 1) | |
| page_size | No | Results per page (max 1000) |
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.
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.
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.
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.
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.
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.
Submit the order for approval in DMS using the order ID.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | DMS order ID |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.11approveOrdercreateDataChangeOrder1 field changedInput schema / properties / commentAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": "Data correct order submitted by MCP",
+ "description": "Business context for the data change order",
+ "title": "Comment"
+}v1.0.0answerSqlSyntaxfixSqlgenerateSql2 fields changedInput schema / properties / knowledge / descriptionPrevious value: -"Additional context"New value: +"Optional: additional context"Input schema / properties / modelAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional: if a specific model is desired, it can be specified here",
+ "title": "Model"
+}optimizeSqladdInstancecreateDataChangeOrderexecuteScriptgenerateSqlgetDatabasegetInstancegetOrderInfogetTableDetailInfolistInstanceslistTablessearchDatabasesubmitOrderApprovalEvery 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
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
