MySQL MCP Server Pro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation4/5
Most 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).
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '在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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取当前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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '专业的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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose 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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mysql_mcp_server_pro MCP server](https://glama.ai/mcp/servers/xucodeboy/mysql_mcp_server_pro/badges/card.svg)](https://glama.ai/mcp/servers/xucodeboy/mysql_mcp_server_pro)

Score Badge

Copy to your README.md:

[![mysql_mcp_server_pro MCP server](https://glama.ai/mcp/servers/xucodeboy/mysql_mcp_server_pro/badges/score.svg)](https://glama.ai/mcp/servers/xucodeboy/mysql_mcp_server_pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xucodeboy/mysql_mcp_server_pro'

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