Enables AI agents to interact with MySQL databases, allowing queries, schema exploration, and management through natural language or structured commands.
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., "@mcp-mysql-server list tables in my_app 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.
基于 @modelcontextprotocol/sdk + mysql2 的 MySQL MCP Server，让 Claude Code 直接操作 MySQL 数据库。
git clone <repo-url> && cd mcp-mysql-server
npm install && npm run build创建 ~/.mcp-mysql/profiles.yml（推荐，支持多环境切换）：
default: dev
profiles:
dev:
host: 127.0.0.1
port: 3306
user: root
password: "your_password"
database: my_app
readonly: true
staging:
host: 192.168.1.100
user: readonly
password: "staging_password"
database: my_app没有 profiles.yml 时，可通过环境变量
MYSQL_HOST/MYSQL_USER/MYSQL_PASSWORD/MYSQL_DATABASE配置单连接。
# 用户级别注册（所有项目可用）
claude mcp add mysql node /absolute/path/to/mcp-mysql-server/dist/index.js -s user
# 或使用 npx（已发布到 npm 时）
claude mcp add mysql npx @huangcaiming5913/mcp-mysql-server -s user也可以手动编辑 ~/.claude/.mcp.json：
{
"mcpServers": {
"mysql": {
"command": "node",
"args": ["/absolute/path/to/mcp-mysql-server/dist/index.js"]
}
}
}重启 Claude Code 后，直接用自然语言操作数据库：
> 看下有哪些数据库
> dst_goods 里有什么表
> g_goods_manage 的表结构
> 查一下上架中的商品有多少个
> 切换到 staging 环境Related MCP server: MySQL MCP Server
工具 | 用途 |
| 列出所有数据库配置（脱敏，不含密码） |
| 切换数据库连接（验证连通性后才切换） |
| 查看当前使用的数据库连接 |
| 执行 SQL（受安全策略控制） |
| 列出可访问的数据库 |
| 列出表及行数、引擎、注释 |
| 查看字段定义和索引 |
| 执行计划分析 + 优化建议 |
| 生成 Markdown 表结构文档 |
| 分析表间关系（外键 + 索引推断） |
| 表数据量、存储大小、更新时间 |
所有数据工具支持可选的 profile 参数，临时使用其他环境查询而不切换当前连接。
路径：~/.mcp-mysql/profiles.yml，可通过 MYSQL_PROFILES_FILE 环境变量覆盖。
每个 profile 可单独设置：
字段 | 默认值 | 说明 |
| — | 必填，数据库地址 |
|
| 端口 |
| — | 必填，用户名 |
| — | 必填，密码 |
| — | 默认数据库 |
|
| 只读模式 |
|
| 允许 DDL（需 readonly=false） |
|
| 查询最大返回行数 |
|
| 查询超时（毫秒） |
|
| 连接池大小 |
安全建议：
不要将 profiles.yml 提交到代码仓库
Unix/macOS：chmod 600 ~/.mcp-mysql/profiles.yml
Windows：通过文件属性限制访问权限
没有 profiles.yml 时回退到环境变量：
变量 | 必填 | 默认值 | 说明 |
| 是 |
| 数据库地址 |
| 否 |
| 端口 |
| 是 | — | 用户名 |
| 是 | — | 密码 |
| 否 | — | 默认数据库 |
| 否 | — | 连接串 |
| 否 |
| 只读模式 |
| 否 |
| 允许 DDL |
| 否 |
| 最大返回行数 |
| 否 |
| 超时毫秒 |
| 否 |
| 连接池大小 |
优先级：profiles.yml > 环境变量 > DSN。
模式 | 配置 | 允许的 SQL |
只读（默认） |
| SELECT, SHOW, DESCRIBE, EXPLAIN |
DML |
| 上述 + INSERT, UPDATE, DELETE |
DDL |
| 全部 |
额外保护：
禁止多语句执行（; 分隔的多条语句会被拦截）
SELECT 无 LIMIT 时自动追加 LIMIT {maxRows}
# 数据探索
> 看下 dst_goods 数据库有哪些表
> g_goods_manage 的表结构是什么样的
> 查一下上架中的商品有多少个
# 性能分析
> 分析一下这条 SQL 的执行计划：SELECT * FROM g_goods_manage WHERE category_id = 100
# 文档生成
> 帮我生成 g_activity 相关表的表结构文档
# 多环境操作
> 切换到 staging 环境
> 看看哪些表占空间最大
> 用 dev 环境查一下 users 表有多少行（自动使用 profile 参数）src/
index.ts # 入口：McpServer + 工具注册 + stdio 传输
config.ts # 配置：profiles.yml + 环境变量 + DSN
connection.ts # MySQL 连接池管理（按 profile 缓存）
registry.ts # 运行时状态：当前 profile + 配置映射
tools/
_common.ts # resolveConn() 按 profile 解析连接
profile.ts # list_profiles / use_profile / current_profile
query.ts # query
schema.ts # list_databases / list_tables / describe_table
explain.ts # explain_query
docs.ts # generate_schema_doc
relations.ts # analyze_relations
stats.ts # table_stats
utils/
sql-guard.ts # SQL 安全校验配置修改后不生效？ 修改 profiles.yml 中的字段需重启 Claude Code；但切换 profile 不需要重启，用 use_profile 即可。
密码含特殊字符？ 用 profiles.yml 或环境变量配置，不要用 DSN（DSN 中特殊字符需 URL 编码）。
如何开启写操作？ 设置 readonly: false。DDL 还需 allowDdl: true。生产环境建议保持只读。
如何在多项目中复用？ 注册到用户级别（-s user），所有项目可用。也可在项目 .mcp.json 中单独配置不同连接。
Analyze table relationships via foreign keys and indexes
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Profile name (defaults to current profile) | |
| database | No | Database name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. The description implies read-only analysis but does not state whether it modifies data, what happens on failure, or any performance implications.
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 redundancy. Direct and to the point. Could be slightly expanded for clarity, but overall efficient.
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?
Lacks description of return values or output format, which is important since no output schema is provided. Also no guidance on when to use this tool versus siblings.
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 both parameters described. The description does not add any additional meaning beyond the schema, so baseline score of 3 applies.
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 specific verb ('Analyze') and resource ('table relationships') with method ('via foreign keys and indexes'), clearly distinguishing it from sibling tools like describe_table and query.
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 describe_table or explain_query. The description does not mention prerequisites or contexts where it is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current active database profile info
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Show', implying a read operation, but does not disclose any behavioral traits like required permissions, side effects, or output specifics. Minimal transparency.
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 with no wasted words. It is front-loaded with the core action and resource.
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 parameters, output schema, or annotations, the description is functional but could specify what 'profile info' includes (e.g., name, ID). However, it is largely complete for a simple read tool.
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?
There are zero parameters, and schema description coverage is 100%. The description adds no parameter-specific info since none exist, but it correctly implies no input needed. Baseline 4 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: showing the current active database profile info. The verb 'Show' and resource are explicit, and it distinguishes from siblings like 'list_profiles' (which lists all) and 'use_profile' (which selects).
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 (check current profile) but provides no explicit guidance on when to use it vs alternatives or when not to use it. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show table structure: columns, types, indexes
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name | |
| profile | No | Profile name (defaults to current profile) | |
| database | No | Database name |
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. While the description implies a read-only operation (showing structure), it does not explicitly state that it is non-destructive, safe to call, or what the performance implications are. This is adequate but lacks explicit safety cues.
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, tightly worded sentence with no waste. It immediately conveys the tool's purpose without extraneous details, making it easy for an agent to scan and understand.
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 lack of an output schema, the description does not specify the format or depth of the returned structure (e.g., constraints, nullability, default values). It mentions 'columns, types, indexes' which is sufficient for basic use, but could be more comprehensive for a tool that inspects table metadata.
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, so the schema already documents all three parameters. The description adds no additional meaning about parameters (e.g., default values, valid formats). The baseline score of 3 is appropriate as the description does not compensate for any schema 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 'Show table structure: columns, types, indexes' clearly states the tool's purpose with a specific verb ('Show') and resource ('table structure'). It distinguishes itself from sibling tools like 'list_tables' (which returns names only) and 'explain_query' (which explains query plans), making the function 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 no guidance on when to use this tool versus alternatives. It does not mention that it is suitable for inspecting a table before querying, nor does it exclude cases where more detailed schema documentation is needed. Without such context, an AI agent might misuse or overlook it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run EXPLAIN on a SELECT query and provide analysis
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SELECT statement to analyze | |
| profile | No | Profile name (defaults to current profile) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the tool runs EXPLAIN (implying read-only) but does not mention permission requirements, side effects, or output format. The brief description leaves significant 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 a single, concise sentence. It is not verbose, but it omits useful details that could be included without significant length.
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 absence of an output schema, the description should explain what the tool returns (e.g., query plan, analysis text). It fails to do so, leaving the agent with incomplete understanding of the tool's output.
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 documents both parameters. The description adds no additional semantic value beyond what the schema provides, matching the baseline.
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 runs EXPLAIN on a SELECT query, which is distinct from sibling tools like 'query' that execute queries. However, the phrase 'provide analysis' is somewhat vague.
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 (e.g., 'query' for actual results, 'analyze_relations' for schema analysis). The description lacks explicit context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Markdown documentation for database tables
| Name | Required | Description | Default |
|---|---|---|---|
| tables | No | Specific table names. Omit for all tables. | |
| profile | No | Profile name (defaults to current profile) | |
| database | No | Database name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states the action without disclosing side effects (e.g., file output, permissions needed, or data mutation). Minimal information.
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 fluff, directly conveys purpose. Could include more detail without becoming verbose.
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?
With 3 optional parameters, no output schema, and many sibling tools, the description is inadequate. It does not explain output format, prerequisites, or how documentation is generated.
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 descriptions for all three parameters (tables, profile, database). The description adds no extra 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?
Clearly states the verb 'generate' and the resource 'Markdown documentation for database tables'. Distinguishes from siblings like describe_table or list_tables by specifying a documentation generation action.
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., describe_table for details, query for data). Lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accessible databases
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Profile name (defaults to current profile) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description simply restates the function without disclosing behavioral traits such as whether the operation is read-only, what 'accessible' means, or any authentication/rate limits.
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 front-loaded sentence with no wasted words. Every part 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?
Given the simplicity (no output schema, no annotations), the description is too minimal. It does not explain what 'accessible' entails, whether pagination exists, or what the return format looks like. For a listing tool, more context 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?
Schema description coverage is 100% for the single optional parameter 'profile'. The description adds no additional meaning beyond the schema's description, so 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 'List all accessible databases' uses a specific verb ('List') and resource ('databases'), clearly distinguishing from sibling tools like list_tables and query. No ambiguity.
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 vs alternatives. Usage is implied from the name and siblings, but no when-not or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available database profiles (passwords hidden)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'passwords hidden' which implies security but does not explicitly state it is read-only or non-destructive. Adequate for a simple list operation but could be more explicit.
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, front-loaded sentence with no extraneous 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?
For a zero-parameter, no-output-schema tool, the description is mostly complete. However, it does not describe the return format (e.g., list of profile names or objects). Minor 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?
No parameters exist, so the description does not need to add parameter details. Baseline 4 applies as the schema coverage is 100%.
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 specific verb 'List' and resource 'database profiles', clearly distinguishing itself from siblings like 'use_profile' and 'current_profile'. The parenthetical 'passwords hidden' adds a clarifying detail.
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 like 'list_databases' or when not to use it. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tables in a database with row counts
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Profile name (defaults to current profile) | |
| database | No | Database name (defaults to profile database) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing behavioral traits like permissions, performance implications, or output format. Minimal disclosure for a database operation.
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, front-loaded with core action, no extraneous information. Highly concise and efficient.
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 and no annotations; description lacks details on output format, default behavior when no parameters are provided, and whether it requires a selected database. Incomplete for practical 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?
Schema coverage is 100%, so the schema already describes parameters. Description adds no additional meaning beyond what's in the schema, meeting baseline expectations.
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 verb 'List', the resource 'tables in a database', and adds specificity with 'with row counts', distinguishing it from sibling tools like 'list_databases' and 'describe_table'.
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 such as 'list_databases' or 'table_stats'. Missing context for usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SQL query (SELECT, SHOW, etc. In readonly mode, only reads are allowed)
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL statement to execute | |
| maxRows | No | Override global MAX_ROWS for this query | |
| profile | No | Profile name to use for this query (defaults to current profile) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions readonly mode but does not explain whether the tool is always read-only or if there are mutability contexts. Missing details on authentication, rate limits, 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?
The description is very short (one sentence), making it concise. However, it omits important details like return format or behavior, so conciseness comes at the cost of completeness.
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 SQL execution tool and the absence of an output schema or annotations, the description is insufficient. It lacks details about error handling, return values, and constraints like maxRows 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%, meaning each parameter has a description in the schema. The description adds only generic context ('Execute SQL query'), which is already implied by the tool name and 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 the tool executes SQL queries, specifically SELECT and SHOW, which distinguishes it from sibling tools like list_databases and describe_table. However, it does not explicitly rule out other SQL types like INSERT or UPDATE, leaving ambiguity.
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?
There is no guidance on when to use this tool over alternatives. The mention of readonly mode is vague and does not clarify prerequisites or scenarios. Sibling tools like explain_query and list_databases offer simpler alternatives, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show table statistics: row counts, data/index sizes, update time
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Specific table name. Omit for all tables. | |
| profile | No | Profile name (defaults to current profile) | |
| database | No | Database name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only, any potential performance impact, required permissions, or return format. The description only states what statistics are shown.
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 front-loaded with the tool's purpose. Every word is meaningful with no redundant or ambiguous phrasing.
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 3 optional parameters, no output schema, and no annotations, the description is insufficient. It does not explain behavior when no table is specified, how to interpret return values, or any constraints like database/profile filtering.
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 descriptions for each of the 3 parameters, so baseline is 3. The tool description adds context about the output (row counts, sizes, time) but does not enhance understanding of parameters beyond what the schema already 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 uses a specific verb 'Show' and clearly identifies the resource as 'table statistics', listing concrete metrics like row counts, data/index sizes, and update time. This clearly distinguishes it from sibling tools such as list_tables or describe_table.
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 lacks any guidance on when to use this tool versus alternatives, no mention of prerequisites, exclusions, or context. It simply states what the tool does without providing decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch the current database profile (validates connectivity before switching)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Profile name to switch to (must exist in profiles.yml) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that connectivity is validated before switching, but lacks details on side effects (e.g., impact on existing connections, behavior on validation failure). The disclosure is present but minimal.
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 sentence of 9 words, highly efficient with no wasted words. It front-loads the core action ('Switch the current database profile') and adds a key behavioral note in parentheses.
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 tool with one parameter and no output schema, the description covers the essential purpose and a notable behavioral trait (validation). It could mention error handling or return value, but current info is sufficient for basic use. Slightly below max due to omitted details.
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% (the one parameter 'name' has a clear description). The tool description does not add extra meaning to the parameter beyond the schema; it only repeats the validation behavior. 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 tool's action: 'Switch the current database profile' with a specific resource (profile) and a distinguishing behavior (validates connectivity). This differentiates it from siblings like 'current_profile' (show current) and 'list_profiles' (list available).
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 you need to switch profiles and validate connectivity) but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternatives are mentioned.
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.
v1.2.0analyze_relationscurrent_profiledescribe_tableexplain_querygenerate_schema_doclist_databaseslist_profileslist_tablesquerytable_statsuse_profileScored across 11 tools
Every tool has a clearly distinct purpose: profile management, querying, schema exploration, documentation generation, relationship analysis, and statistics. No two tools overlap in functionality.
Tool names follow a consistent verb_noun (or adjective_noun) pattern using snake_case, with minor exceptions like 'query' that are still intuitive and predictable.
With 11 tools, the set is well-scoped for MySQL database operations, covering profile management, querying, schema exploration, and analysis without being excessive or insufficient.
The tool surface is comprehensive for database introspection and analysis: profile switching, querying, listing databases/tables, describing schemas, explaining queries, generating documentation, analyzing relations, and table stats. No obvious gaps for the intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
