Provides comprehensive MySQL database management capabilities including CRUD operations, health monitoring, performance analysis, SQL optimization, lock detection, and database structure querying with role-based access control
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MySQL MCP Server Pro analyze the health of our production database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp_mysql_server_pro is not just about MySQL CRUD operations, but also includes database anomaly analysis capabilities and makes it easy for developers to extend with custom tools.
Supports all Model Context Protocol (MCP) transfer modes (STDIO, SSE, Streamable Http)
Supports OAuth2.0
Supports multiple SQL execution, separated by ";"
Supports querying database table names and fields based on table comments
Supports SQL execution plan analysis
Supports Chinese field to pinyin conversion
Supports table lock analysis
Supports database health status analysis
Supports permission control with three roles: readonly, writer, and admin
"readonly": ["SELECT", "SHOW", "DESCRIBE", "EXPLAIN"], # Read-only permissions
"writer": ["SELECT", "SHOW", "DESCRIBE", "EXPLAIN", "INSERT", "UPDATE", "DELETE"], # Read-write permissions
"admin": ["SELECT", "SHOW", "DESCRIBE", "EXPLAIN", "INSERT", "UPDATE", "DELETE",
"CREATE", "ALTER", "DROP", "TRUNCATE"] # Administrator permissionsSupports prompt template invocation
Related MCP server: MCP MySQL Server
Tool Name | Description |
execute_sql | SQL execution tool that can execute ["SELECT", "SHOW", "DESCRIBE", "EXPLAIN", "INSERT", "UPDATE", "DELETE", "CREATE", "ALTER", "DROP", "TRUNCATE"] commands based on permission configuration |
get_chinese_initials | Convert Chinese field names to pinyin initials |
get_db_health_running | Analyze MySQL health status (connection status, transaction status, running status, lock status detection) |
get_table_desc | Search for table structures in the database based on table names, supporting multi-table queries |
get_table_index | Search for table indexes in the database based on table names, supporting multi-table queries |
get_table_lock | Check if there are row-level locks or table-level locks in the current MySQL server |
get_table_name | Search for table names in the database based on table comments and descriptions |
get_db_health_index_usage | Get the index usage of the currently connected mysql database, including redundant index situations, poorly performing index situations, and the top 5 unused index situations with query times greater than 30 seconds |
optimize_sql | Professional SQL performance optimization tool, providing expert optimization suggestions based on MySQL execution plans, table structure information, table data volume, and table indexes. |
use_prompt_queryTableData | Use built-in prompts to let the model construct a chain call of tools in mcp (not a commonly used fixed tool, you need to modify the code to enable it, see this class for details) |
Prompt Name | Description |
analyzing-mysql-prompt | This is a prompt for analyzing MySQL-related issues |
query-table-data-prompt | This is a prompt for querying table data using tools. If description is empty, it will be initialized as a MySQL database query assistant |
Install Package
pip install mysql_mcp_server_proConfigure Environment Variables
Create a .env file with the following content:
# MySQL Database Configuration
MYSQL_HOST=localhost
MYSQL_PORT=3306
MYSQL_USER=your_username
MYSQL_PASSWORD=your_password
MYSQL_DATABASE=your_database
# Optional, default is 'readonly'. Available values: readonly, writer, admin
MYSQL_ROLE=readonlyRun Service
# SSE mode
mysql_mcp_server_pro --mode sse --envfile /path/to/.env
## Streamable Http mode (default)
mysql_mcp_server_pro --envfile /path/to/.env
# Streamable Http oauth Authentication
mysql_mcp_server_pro --oauth true
mcp client
go to see see "Use uv to start the service" ^_^
Note:
The .env file should be placed in the directory where you run the command or use --envfile parameter to specify the path
You can also set these variables directly in your environment
Make sure the database configuration is correct and can connect
This method can be used directly in MCP-supported clients, no need to download the source code. For example, Tongyi Qianwen plugin, trae editor, etc.
{
"mcpServers": {
"mysql": {
"command": "uvx",
"args": [
"--from",
"mysql_mcp_server_pro",
"mysql_mcp_server_pro",
"--mode",
"stdio"
],
"env": {
"MYSQL_HOST": "192.168.x.xxx",
"MYSQL_PORT": "3306",
"MYSQL_USER": "root",
"MYSQL_PASSWORD": "root",
"MYSQL_DATABASE": "a_llm",
"MYSQL_ROLE": "admin"
}
}
}
}Use uv to start the service
Add the following content to your mcp client tools, such as cursor, cline, etc.
mcp json as follows:
{
"mcpServers": {
"mysql_mcp_server_pro": {
"name": "mysql_mcp_server_pro",
"type": "streamableHttp",
"description": "",
"isActive": true,
"url": "http://localhost:3000/mcp/"
}
}
}Modify the .env file content to update the database connection information with your database details:
# MySQL Database Configuration
MYSQL_HOST=192.168.xxx.xxx
MYSQL_PORT=3306
MYSQL_USER=root
MYSQL_PASSWORD=root
MYSQL_DATABASE=a_llm
MYSQL_ROLE=adminStart commands:
# Download dependencies
uv sync
# Start
uv run -m mysql_mcp_server_pro.server
# Custom env file location
uv run -m mysql_mcp_server_pro.server --envfile /path/to/.env
# oauth Authentication
uv run -m mysql_mcp_server_pro.server --oauth trueUse uv to start the service
Add the following content to your mcp client tools, such as cursor, cline, etc.
mcp json as follows:
{
"mcpServers": {
"mysql_mcp_server_pro": {
"name": "mysql_mcp_server_pro",
"description": "",
"isActive": true,
"url": "http://localhost:9000/sse"
}
}
}Modify the .env file content to update the database connection information with your database details:
# MySQL Database Configuration
MYSQL_HOST=192.168.xxx.xxx
MYSQL_PORT=3306
MYSQL_USER=root
MYSQL_PASSWORD=root
MYSQL_DATABASE=a_llm
MYSQL_ROLE=adminStart commands:
# Download dependencies
uv sync
# Start
uv run -m mysql_mcp_server_pro.server --mode sse
# Custom env file location
uv run -m mysql_mcp_server_pro.server --mode sse --envfile /path/to/.envAdd the following content to your mcp client tools, such as cursor, cline, etc.
mcp json as follows:
{
"mcpServers": {
"operateMysql": {
"isActive": true,
"name": "operateMysql",
"command": "uv",
"args": [
"--directory",
"/Volumes/mysql_mcp_server_pro/src/mysql_mcp_server_pro", # Replace this with your project path
"run",
"-m",
"mysql_mcp_server_pro.server",
"--mode",
"stdio"
],
"env": {
"MYSQL_HOST": "localhost",
"MYSQL_PORT": "3306",
"MYSQL_USER": "root",
"MYSQL_PASSWORD": "123456",
"MYSQL_DATABASE": "a_llm",
"MYSQL_ROLE": "admin"
}
}
}
} Add a new tool class in the handles package, inherit from BaseHandler, and implement get_tool_description and run_tool methods
Import the new tool in init.py to make it available in the server
Start the authentication service. By default, it uses the built-in OAuth 2.0 password mode authentication. You can modify your own authentication service address in the env file.
uv run -m mysql_mcp_server_pro.server --oauth trueVisit the authentication service at http://localhost:3000/login. Default username and password are configured in the env file.
Copy the token and add it to the request headers, for example:
{
"mcpServers": {
"mysql_mcp_server_pro": {
"name": "mysql_mcp_server_pro",
"type": "streamableHttp",
"description": "",
"isActive": true,
"url": "http://localhost:3000/mcp/",
"headers": {
"authorization": "bearer TOKEN_VALUE"
}
}
}
}Create a new table and insert data, prompt format as follows:
# Task
Create an organizational structure table with the following structure: department name, department number, parent department, is valid.
# Requirements
- Table name: department
- Common fields need indexes
- Each field needs comments, table needs comment
- Generate 5 real data records after creation
Query data based on table comments, prompt as follows:
Search for data with Department name 'Executive Office' in Department organizational structure tableAnalyze slow SQL, prompt as follows:
select * from t_jcsjzx_hjkq_cd_xsz_sk xsz
left join t_jcsjzx_hjkq_jcd jcd on jcd.cddm = xsz.cddm
Based on current index situation, review execution plan and provide optimization suggestions in markdown format, including table index status, execution details, and optimization recommendationsAnalyze SQL deadlock issues, prompt as follows:
update t_admin_rms_zzjg set sfyx = '0' where xh = '1' is stuck, please analyze the causeAnalyze the health status prompt as follows
Check the current health status of MySQL在MySQL数据库上执行SQL (支持多条SQL语句，以分号分隔)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 要执行的SQL语句 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions support for multiple SQL statements separated by semicolons, which adds some context beyond the basic 'execute SQL' purpose. However, it fails to disclose critical behavioral traits such as whether this is a read/write operation, potential side effects (e.g., data modification), authentication requirements, error handling, or rate limits. For a database tool with mutation potential, this is a significant gap.
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 and front-loaded: a single sentence that directly states the tool's purpose and key capability (support for multiple statements). There is no wasted verbiage, and every word earns its place by conveying essential information efficiently.
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 the complexity of a database SQL execution tool with no annotations and no output schema, the description is incomplete. It lacks information about return values (e.g., result sets, error messages), behavioral constraints (e.g., read-only vs. write operations, transaction handling), and how it differs from sibling tools. For a tool that could perform destructive operations, this is inadequate.
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 description coverage is 100%, with the single parameter 'query' documented as '要执行的SQL语句' (SQL statement to execute). The description adds minimal value beyond the schema by implying the query can contain multiple statements separated by semicolons, but it doesn't elaborate on syntax, constraints, or examples. Given the high schema coverage, the baseline score of 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 tool's purpose: '在MySQL数据库上执行SQL' (execute SQL on MySQL database). It specifies the verb ('执行' - execute) and resource ('SQL'), and mentions support for multiple statements separated by semicolons. However, it doesn't explicitly differentiate from sibling tools like optimize_sql or get_table_name, which prevents a score of 5.
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. It doesn't mention when to use execute_sql versus optimize_sql (for optimization) or get_table_name (for querying metadata), nor does it specify any prerequisites or exclusions. This lack of contextual guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建表结构时，将中文字段名转换为拼音首字母字段
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要获取拼音首字母的汉字文本，以“,”分隔 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it describes the conversion function, it doesn't mention important behavioral aspects like whether this is a read-only operation, what format the output takes, error handling for non-Chinese text, or performance characteristics. The description is functional but lacks operational 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?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple transformation tool and gets straight 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?
For a single-parameter transformation tool with no output schema, the description adequately explains what the tool does. However, it lacks information about the output format (what the pinyin initials look like) and doesn't address edge cases or limitations, which would be helpful given the absence of annotations.
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 the parameter 'text' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides about the comma-separated Chinese text input. This meets the baseline for high schema coverage.
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: converting Chinese field names to pinyin initials during table structure creation. It specifies both the action ('转换' - convert) and the resource ('中文字段名' - Chinese field names), though it doesn't explicitly differentiate from sibling tools like get_table_name or get_table_desc.
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. It mentions '创建表结构时' (during table structure creation) which gives some context, but doesn't specify prerequisites, limitations, or when other tools might be more appropriate given the sibling tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前连接的mysql库的索引使用情况,包含冗余索引情况、性能较差的索引情况、未使用索引且查询时间大于30秒top5情况(Get the index usage of the currently connected mysql database, including redundant index situations, poorly performing index situations, and the top 5 unused index situations with query times greater than 30 seconds)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what information the tool returns but doesn't mention important behavioral aspects: whether this is a read-only operation (implied but not stated), whether it requires specific database permissions, potential performance impact on the database, or how current the data is (real-time vs cached). The description focuses on output content rather than tool 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?
The description is efficiently structured in a single sentence that clearly states the tool's purpose and the three specific types of index usage information it provides. The bilingual format (Chinese then English) adds some redundancy but doesn't significantly impact clarity. Every part of the description serves a 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?
Given the tool's complexity (analyzing multiple aspects of index usage) with no annotations and no output schema, the description provides adequate but incomplete context. It specifies what information will be returned but doesn't describe the format, structure, or potential limitations of the output. For a diagnostic tool with potentially complex output, more detail about the return format would be helpful.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly focuses on what the tool does rather than parameter details.
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: 'Get the index usage of the currently connected mysql database' with specific details about what information it provides (redundant indexes, poorly performing indexes, top 5 unused indexes with query times >30 seconds). It distinguishes from siblings like get_table_index (which likely shows index structure) and get_db_health_running (which likely shows current running queries). However, it doesn't explicitly contrast with these siblings in the text.
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 context (when analyzing MySQL database performance issues related to indexes) but doesn't provide explicit guidance on when to use this tool versus alternatives like get_table_index or optimize_sql. No exclusions or prerequisites are mentioned, though the tool name suggests it's part of a database health monitoring suite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前mysql的健康状态(Analyze MySQL health status )
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it indicates this is a read operation (get/analyze status), it doesn't describe what 'health status' includes, whether it requires specific permissions, if it impacts database performance, what format the output takes, or any error conditions. For a diagnostic tool with zero annotation coverage, this leaves significant behavioral gaps.
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 just one bilingual sentence that states the core purpose. There's no wasted text or unnecessary elaboration. However, the bilingual format (Chinese followed by English translation in parentheses) is slightly redundant rather than optimally structured, though both parts contribute to clarity.
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 the tool's diagnostic nature, absence of annotations, and lack of output schema, the description is insufficiently complete. It doesn't explain what constitutes 'health status', what metrics or information are returned, whether this is a lightweight check or intensive analysis, or how results should be interpreted. For a health monitoring tool that likely returns complex status information, more context is needed.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters since none exist. It focuses correctly on what the tool does rather than parameter details, earning a baseline 4 for parameter semantics when no parameters need explanation.
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 as '获取当前mysql的健康状态' (Get current MySQL health status) with the English translation 'Analyze MySQL health status'. It specifies the verb (get/analyze) and resource (MySQL health status), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like get_db_health_index_usage, which suggests this might be a general health check while others focus on specific aspects.
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. With sibling tools like get_db_health_index_usage, get_table_lock, and optimize_sql that also relate to database health or performance, there's no indication of when this general health check is appropriate versus more specific diagnostics. The description lacks any context about use cases, prerequisites, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据表名搜索数据库中对应的表字段,支持多表查询(Search for table structures in the database based on table names, supporting multi-table queries)
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要搜索的表名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for table structures and supports multi-table queries, but doesn't describe what 'table structures' include (e.g., field names, types, constraints), how results are formatted, whether it's read-only, or any limitations like rate limits or authentication needs. This leaves significant gaps for a tool that interacts with a database.
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, efficient sentence in both Chinese and English that conveys the core functionality without unnecessary details. It's front-loaded with the main purpose and includes a key feature (multi-table support), making it appropriately sized and zero-waste.
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 the complexity of database operations, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'table structures' entail, how results are returned, or any behavioral traits like safety or performance. For a tool with one parameter but significant implied functionality, more context is needed to guide effective use.
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, with the parameter 'text' documented as '要搜索的表名' (table names to search). The description adds value by clarifying that this supports multi-table queries, implying 'text' can contain multiple table names, but doesn't specify the format (e.g., comma-separated, wildcards). Given the high schema coverage, a baseline score of 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 tool's purpose: searching for table structures based on table names, with support for multi-table queries. It specifies the verb ('search for table structures'), resource ('database'), and scope ('based on table names'), but doesn't explicitly differentiate from sibling tools like get_table_name or get_table_index.
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 is provided on when to use this tool versus alternatives. The description mentions multi-table query support but doesn't clarify when this is preferable over single-table queries or how it relates to sibling tools like get_table_name (which might retrieve table names rather than structures) or execute_sql (which could query table data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据表名搜索数据库中对应的表索引,支持多表查询(Search for table indexes in the database based on table names, supporting multi-table queries)
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要搜索的表名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality and multi-table support but fails to describe critical traits such as whether this is a read-only operation, potential performance impacts, error handling, or the format of returned results. For a database query tool, this leaves significant gaps in understanding its 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?
The description is a single, efficient sentence in both Chinese and English, front-loaded with the core purpose and key feature (multi-table support). There is no redundant information or unnecessary elaboration, making it highly concise and well-structured for quick understanding.
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 the tool's complexity as a database search function with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like (e.g., index details, error messages), usage limits, or integration with sibling tools. For a tool that likely returns structured data, more context is needed to be 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?
The input schema has 100% description coverage, with the parameter 'text' documented as '要搜索的表名' (table names to search). The description adds value by specifying that it supports multi-table queries, implying the parameter can handle multiple names, but doesn't detail syntax (e.g., comma-separated) or constraints beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.
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 as searching for table indexes based on table names, with the specific capability of supporting multi-table queries. It distinguishes itself from siblings like get_table_desc (descriptions) and get_table_name (names) by focusing on indexes. However, it doesn't explicitly contrast with get_table_lock (locks) or optimize_sql (optimization), leaving some sibling differentiation incomplete.
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 needing to find table indexes, particularly for multiple tables, but provides no explicit guidance on when to use this tool versus alternatives like get_table_desc for descriptions or execute_sql for direct queries. It lacks any mention of prerequisites, exclusions, or specific scenarios favoring this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前mysql服务器行级锁、表级锁情况(Check if there are row-level locks or table-level locks in the current MySQL server )
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what information the tool retrieves but doesn't describe how it behaves: whether it requires specific permissions, if it's read-only or has side effects, what format the output takes, or any performance characteristics. For a diagnostic tool with zero annotation coverage, this leaves significant behavioral gaps.
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 - a single sentence that directly states the tool's purpose with no wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration. This represents optimal conciseness for a simple diagnostic tool.
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 diagnostic tool with no annotations and no output schema, the description is insufficiently complete. It states what information the tool retrieves but provides no context about output format, data structure, interpretation of results, or how the information might be used. Given the complexity of lock diagnostics and the lack of structured metadata, the description should provide more operational 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?
The tool has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. With no parameters, the baseline score is 4 as the description doesn't need to compensate for any parameter documentation gaps.
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: '获取当前mysql服务器行级锁、表级锁情况' (Check if there are row-level locks or table-level locks in the current MySQL server). It uses specific verbs ('获取'/'Check') and identifies the resource (MySQL server locks). However, it doesn't explicitly distinguish this from sibling tools like get_db_health_running, which might also provide server status information.
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. It doesn't mention prerequisites, timing considerations, or how it differs from sibling tools like get_db_health_running or execute_sql. The agent receives no usage context beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据表中文名或表描述搜索数据库中对应的表名(Search for table names in the database based on table comments and descriptions )
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要搜索的表中文名、表描述，仅支持单个查询 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the search functionality but lacks details on behavioral traits such as whether it's read-only (implied but not stated), performance characteristics, error handling, or output format. For a tool with no annotation coverage, this is a significant gap in disclosing how it behaves beyond basic purpose.
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, consisting of a single bilingual sentence that directly states the tool's purpose. There is no wasted verbiage or unnecessary details, making it efficient and easy to parse for an AI agent.
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 the tool's moderate complexity (search operation with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or error handling. It meets the minimum viable standard but has clear gaps in providing a complete context for effective use.
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 description coverage is 100%, with the parameter 'text' well-documented as '要搜索的表中文名、表描述，仅支持单个查询' (table Chinese name or description to search, single query only). The description adds minimal value beyond this, restating the purpose without providing additional syntax, examples, or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
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: searching for table names based on table comments/descriptions. It specifies both the action ('search') and resource ('table names'), and distinguishes it from siblings like 'get_table_desc' (which presumably gets descriptions rather than searches by them). However, it doesn't explicitly differentiate from 'execute_sql' or other search-related tools, keeping it at 4 rather than 5.
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 context by stating it searches 'based on table comments and descriptions,' suggesting it should be used when you have descriptive text but not the exact table name. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_table_desc' or 'execute_sql' for similar queries, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
专业的SQL性能优化工具，基于MySQL执行计划、表结构信息、表数据量、表索引提供专家级优化建议。该工具能够分析SQL语句的执行效率，识别性能瓶颈，并提供具体的优化方案，包括索引优化、查询重写建议等，帮助提升数据库查询性能。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要优化的sql |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool does (analyzes SQL, provides optimization suggestions) but lacks critical behavioral details: whether it requires specific database permissions, if it executes the SQL (potentially read-only vs. destructive), expected response format, or any rate limits. The description is functional but incomplete for safe agent invocation.
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 appropriately concise (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first defines the tool's function and scope, the second elaborates on analysis and optimization types. There's no redundant information, though it could be slightly more structured (e.g., bullet points for optimization types).
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 the tool's complexity (performance analysis with multiple factors like execution plans, indexes) and lack of annotations/output schema, the description is insufficient. It doesn't explain what the optimization suggestions look like (e.g., structured output, text report), how comprehensive the analysis is, or dependencies on other tools (e.g.,是否需要先获取表结构). For a tool with no structured output and behavioral unknowns, more context is needed.
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 one parameter ('text' described as '要优化的sql'), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides—it doesn't clarify SQL dialect requirements (e.g., MySQL-specific), input format expectations, or examples. The description's mention of 'SQL语句' aligns with the schema but doesn't enhance it.
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: '专业的SQL性能优化工具...提供专家级优化建议' (professional SQL performance optimization tool providing expert optimization suggestions). It specifies the exact function (analyze SQL efficiency, identify bottlenecks, provide optimization solutions) and distinguishes itself from siblings like execute_sql (which executes SQL) or get_table_index (which retrieves index information).
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. While it mentions analyzing SQL statements for performance optimization, it doesn't specify prerequisites (e.g., when you have a slow query), exclusions (e.g., not for DDL statements), or direct comparisons to siblings like get_db_health_index_usage (which might provide index usage insights). Usage is implied but not explicitly stated.
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.1execute_sqlget_chinese_initialsget_db_health_index_usageget_db_health_runningget_table_descget_table_indexget_table_lockget_table_nameoptimize_sqlMost tools have distinct purposes, such as execute_sql for running queries, get_table_desc for table structures, and optimize_sql for performance tuning. However, some tools like get_db_health_index_usage and get_db_health_running could be confused as both relate to database health, though their specific focuses differ (index usage vs. general health status).
The naming follows a consistent verb_noun pattern with snake_case, such as execute_sql, get_table_desc, and optimize_sql. There is a minor deviation with get_chinese_initials, which uses a different verb style (get_chinese instead of something like convert_chinese_initials), but overall the pattern is clear and readable.
With 9 tools, the count is well-scoped for a MySQL database management server. Each tool serves a specific function, from basic SQL execution to advanced health monitoring and optimization, covering essential operations without being overwhelming or sparse.
The toolset provides strong coverage for database operations, including query execution, schema exploration, health monitoring, and performance optimization. A minor gap exists in CRUD operations for data manipulation (e.g., insert, update, delete), but the core database management and analysis workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Ask questions in plain language, get answers from your business database. No SQL required.
GibsonAI MCP server: manage your databases with natural language
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xucodeboy/mysql_mcp_server_pro'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
