DB Gateway MCP Server

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation4/5
Most tools target distinct MySQL operations (e.g., show_tables vs. list_databases vs. get_schema). A few pairs like execute_query/execute_batch and describe_table/get_schema overlap in purpose, but descriptions clarify the differences.
Naming Consistency5/5
All tools follow a consistent 'mysql_<verb>_<noun>' pattern (e.g., mysql_show_tables, mysql_execute_query, mysql_kill_process). This makes the set predictable and easy to navigate.
Tool Count4/5
At 17 tools, the server is slightly larger than the ideal 3-15 range but remains well-scoped for a MySQL gateway. Each tool addresses a specific operational need without redundancy.
Completeness4/5
The set covers core database operations: schema inspection, query execution, process management, and table relationships. While explicit CRUD or transaction tools are absent, mysql_execute_query and mysql_execute_batch provide a flexible escape hatch for any SQL operation.
Average 3.4/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 full responsibility for behavioral disclosure. It states that it executes SQL but does not disclose potential side effects (e.g., data modification, DDL execution), required permissions, or transaction behavior. This is a significant gap for a tool that can run arbitrary SQL.
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 a single sentence with no redundant wording. It is appropriately short for the tool's apparent simplicity, though it lacks substance that could be added without being wordy.
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 executes arbitrary SQL, it has high complexity and potential risk. The description provides no information about return format, how the limit parameter affects results, or connection alias behavior beyond the schema. The combination of no annotations and a minimal description makes it incomplete for an agent to invoke safely.
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 each parameter (query, alias, limit) having a clear description. The tool description itself adds no additional meaning, but since the schema already documents the parameters, 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 'Execute SQL query on MySQL database' clearly specifies the action (execute) and resource (SQL query on MySQL). It is distinct from sibling tools like mysql_show_tables or mysql_describe_table, though it does not explicitly differentiate from mysql_execute_batch beyond the name.
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 does not mention that read-only operations could be done with dedicated tools like mysql_show_tables, nor does it suggest when to use mysql_execute_batch instead.
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 only states what the tool does (shows running queries/connections) without mentioning safety implications, required privileges, performance effects, or the shape of the returned data. It does not contradict any annotations, but it provides minimal insight into potential side effects or limitations.
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, front-loaded sentence that directly states the tool's purpose and includes the relevant MySQL command in parentheses for clarity. There is no extraneous information or redundancy, making it highly concise and well-structured.
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?
Despite being a simple tool with one optional parameter and no output schema, the description lacks contextual completeness. It does not explain what the returned data looks like, how it differs from similar tools like mysql_list_connections, or any behavioral caveats. This leaves the agent without sufficient context to confidently select and invoke the tool in more nuanced scenarios.
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 includes one optional parameter 'alias' with a description ('MySQL connection alias (optional, uses default if omitted)'), giving 100% schema description coverage. The tool description itself adds no additional meaning about the parameter, so it relies on the schema, which is sufficient. Baseline 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 shows all running queries and connections with a specific verb ('Show') and resource ('all running queries and connections in MySQL'), and references the underlying SHOW FULL PROCESSLIST command. It is specific enough to understand the tool's function, though it does not explicitly distinguish it from siblings like mysql_list_connections, which could overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mysql_list_connections or mysql_show_status. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer appropriate usage solely from the tool name and brief description.
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 present, so the description carries full burden. It only states 'Show MySQL server status variables', implying a read operation but without disclosing any behavioral details such as whether it returns session/global variables, performance implications, or required privileges. This is a minimal statement with no added behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states purpose, no redundant words. However, it is under-specified given the tool's bare context, so it earns a 4 rather than 5.
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?
Tool has low complexity (2 optional params, no output schema), so this is a minimum viable description. It mentions the subject matter but does not specify return format or any usage caveats, which are needed since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond the schema; the 'connections, queries' examples hint at possible pattern values but don't clarify parameter semantics further.
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 uses a specific verb ('Show') and resource ('MySQL server status variables') with examples ('connections, queries'), clearly distinguishing it from sibling tools like mysql_show_tables (tables) and mysql_show_variables (configuration variables). However, it does not explicitly name alternatives, so it falls short of a 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?
No guidance is provided on when to use this tool versus siblings like mysql_show_variables or mysql_show_processlist. The description only states what it does; usage context must be inferred from the tool name.
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, the description carries the full burden of behavioral disclosure. It simply says 'switch' without indicating whether this changes a session/connection state, whether it persists across calls, whether it validates the database name, or what happens if the switch fails. No side effects or safety information is disclosed.
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 a single, concise sentence that gets to the point. It is not verbose or redundant. However, it may be overly terse, lacking any contextual details that could fit without losing conciseness. Still, it earns a 4 for efficient structure.
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 that this is a state-changing tool (switching database) with no output schema and sparse annotations, the description is incomplete. It fails to explain the effect on subsequent operations, the role of the alias parameter, or error handling. In the context of sibling tools like mysql_execute_query, this tool's behavior is crucial to understand, but the description does not provide that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters (alias and database_name) have descriptions in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, so it neither helps nor hurts. Baseline 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 action: switching to a different MySQL database. It identifies the resource (MySQL database) and the specific verb 'switch'. However, it lacks additional scope detail (e.g., what 'different' means, whether it sets the default for subsequent operations), and it doesn't explicitly distinguish itself from sibling tools like mysql_list_databases or mysql_get_all_schemas, though the action is distinct enough.
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 usage guidance is provided. The description does not explain when to use this tool relative to siblings (e.g., before executing queries) or any prerequisites or exclusions. The context is implied by the tool name but not articulated.
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 must disclose behavioral traits, but it only states a generic outcome. It does not clarify what 'structure' includes (e.g., columns, types, indexes, constraints), whether it uses SHOW CREATE TABLE or DESCRIBE, or any side effects. The tool appears to be read-only, but this is not explicitly stated.
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, front-loaded sentence with no redundant words. It is appropriately sized for a simple tool and immediately conveys the core 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?
The tool is simple, and the schema fully documents its parameters. However, there is no output schema, and the description does not explain what structure information is returned (e.g., column names, data types, keys). For an agent selecting this tool, knowing the return format would be valuable, so completeness is moderate.
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 covers both parameters (alias and table_name) with descriptions, so baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides. It does not explain the relationship between alias and table_name or provide examples.
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 'Describe the structure of a MySQL table' uses a specific verb ('Describe') and resource ('MySQL table'), clearly stating the tool's purpose. It is not a tautology and is concise, though it does not explicitly differentiate itself from sibling tools like mysql_get_schema, which may also describe table structures.
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 does not mention when to prefer mysql_describe_table over mysql_get_schema, mysql_show_tables, or mysql_list_indexes. There are no 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It does not disclose that this is a read-only operation, potential permission requirements, or behavior when no tables exist. It only states the basic action, which is insufficient for full transparency.
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 one concise sentence that directly states the tool's function. It is well-structured and front-loaded, though it could include more context without becoming verbose.
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?
The tool is simple with one optional parameter and no output schema. The description explains the core functionality but does not specify the return format, error handling, or behavior when no tables exist. Given low complexity, this is acceptable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'alias' is fully documented in the input schema. The description does not add additional meaning beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (Get) and resource (CREATE TABLE statements for all tables in the current database). It distinguishes from sibling tools like mysql_show_tables (which lists table names) and mysql_describe_table (single table). However, the tool name 'all_schemas' vs 'all tables' creates minor ambiguity, so not a 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 use when you need DDL for all tables, but does not explicitly state when this tool is preferred over alternatives like mysql_show_tables or mysql_describe_table. It lacks exclusionary guidance.
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, the description carries the burden of disclosing behavioral traits. It does not mention read-only status, required privileges, or potential errors, and only states the basic get operation. The name suggests a read-only action but this is not explicitly disclosed.
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, clear sentence that immediately states the action and target. It is concise with no filler or redundant information, making it easy for an agent to parse.
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?
The description is minimal but adequate for a simple two-parameter tool with full schema coverage. However, it does not explain return format, connection handling, or how it differs from mysql_describe_table, leaving some gaps for an agent navigating sibling tools.
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 already provides descriptions for both parameters (alias and table_name) with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the CREATE TABLE statement for a specific MySQL table' clearly states the action (get), the resource (schema of a table), and the specific output (CREATE TABLE statement). This distinguishes it from sibling tools like mysql_describe_table or mysql_show_tables.
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 such as mysql_describe_table or mysql_show_tables. The description only states what it does, leaving the agent to infer usage context.
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 full responsibility for disclosing behavioral traits. It states the action is to kill a connection/query, which implies destructiveness, but does not disclose severity, irreversibility, permission requirements, or whether it terminates the entire connection or just the query. This ambiguity is significant for a potentially disruptive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core action and target. It contains no filler or redundant wording, making it easy to parse quickly.
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 simplicity (2 params, no output schema), the description is minimally viable. However, it lacks important contextual information for a destructive operation: no safety warning, no mention of obtaining the process ID via a sibling tool, and no clarification on the scope (connection vs. query). This leaves gaps for an agent unfamiliar with MySQL process management.
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 schema already describing process_id as 'Process ID to kill (from SHOW PROCESSLIST)' and alias as optional. The description adds no additional parameter meaning beyond what the schema provides, meeting the baseline for good schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Kill') and clearly identifies the resource ('MySQL connection/query by process ID'). It distinguishes itself from sibling tools like mysql_show_processlist and mysql_list_connections by communicating the destructive action.
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites like calling mysql_show_processlist to obtain the process ID, nor does it warn against killing critical processes. Usage context is only implied by the tool's purpose.
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 present, so the description must disclose behavior. It does not state that the operation is read-only, whether it requires permissions, or how it behaves with no pattern (e.g., returns all variables). The description only restates the obvious 'show' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no wasted text or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with two optional parameters and no output schema. However, it omits any mention of return format, default behavior (e.g., showing all variables without a pattern), or connection alias semantics, which could leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description itself adds no parameter details, but the schema's parameter descriptions are sufficient.
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 shows MySQL server configuration variables, using a specific verb ('Show') and resource ('configuration variables'). This distinguishes it from sibling tools like mysql_show_status, which deals with status variables.
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?
There is no guidance on when to use this tool versus alternatives such as mysql_show_status or mysql_show_processlist. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 adds a meaningful behavioral nuance by stating 'current user can see', indicating permission-based filtering and implying a read-only operation. However, it does not explicitly confirm safety, side effects, or output format, leaving some gaps for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action and scope. Every word contributes to meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers the core purpose and the user-visibility constraint. It does not detail the output structure, but the phrase 'list databases' naturally implies a list of names. A small gap is the lack of distinction from overlapping siblings, but overall the description is complete for its simplicity.
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 a clear explanation of the optional 'alias' parameter. The tool description itself adds no parameter detail, but since the schema fully documents the one parameter, the baseline 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 states a specific action ('List') with a clear resource ('databases') and a scope qualifier ('the current user can see'), which unambiguously identifies the tool's function. However, it does not differentiate from the closely named sibling 'mysql_get_all_schemas', which likely serves a similar purpose, so it falls short of a 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 offers no guidance on when to use this tool versus alternatives, such as 'mysql_get_all_schemas' or 'mysql_show_tables'. There is no mention of prerequisites, use cases, or situations where another tool would be preferred, leaving the agent to infer context from the name alone.
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 transparency burden. It only states the basic action ('Show all tables') without disclosing any behavioral details such as whether it requires an active connection, if it queries information_schema, or potential error conditions (e.g., no database selected). It does not even explicitly state that it is read-only, though 'show' implies so. This is minimal beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's action without any unnecessary words or repetition. It is appropriately front-loaded and easy to parse.
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?
The tool is simple (one optional param, no output schema), and the description covers the core function. However, it does not explicitly describe the return value (e.g., whether it returns a list of table names, any additional metadata) or mention any prerequisites beyond the current database context. Given the lack of an output schema, the description could be more explicit about the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'alias' is fully described in the schema ('optional, uses default if omitted'). The tool description adds no extra parameter context beyond referencing the 'current MySQL database', which aligns with the alias/default connection but does not enhance understanding of the parameter itself. Thus the baseline of 3 applies.
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 'Show all tables in the current MySQL database' uses a specific verb ('Show') and resource ('all tables'), clearly distinguishing it from siblings like mysql_describe_table (describes a specific table) and mysql_list_databases (lists databases). It explicitly mentions the scope 'current MySQL database', which aligns with the tool's name and function.
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 its use (when you want to list tables in the current database) but provides no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. No alternative tools are mentioned.
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?
There are no annotations, so the description must disclose behavioral traits. It only says 'Get the execution plan' and doesn't state that the query is not actually executed, that the operation is read-only, or what kind of output to expect. This leaves important behavior unspecified.
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, front-loaded sentence that captures the essence without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description gives the core idea of returning an execution plan. However, since there is no output schema, the description doesn't specify the exact return format, but the standard EXPLAIN behavior is widely known. It is sufficient for a simple tool.
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?
Both parameters (alias and query) are fully documented in the schema with 100% coverage, so the baseline is 3. The description adds no additional semantic information about the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get the execution plan for a SQL query (EXPLAIN)' which clearly identifies the tool's function with a specific verb and resource. It distinguishes itself from siblings like mysql_execute_query (which actually runs the query) and mysql_describe_table (which describes table structure).
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 this tool is for query performance analysis via EXPLAIN, but it doesn't explicitly state when to use it over alternatives or provide exclusions. For instance, it doesn't note that it won't execute the query, which would be helpful in choosing between this and mysql_execute_query.
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, the description carries the full burden of behavioral disclosure. It only states the basic action (list) and result (status), but does not explicitly state that the operation is read-only, requires no credentials, or has any side effects. The verb 'List' implies non-destructive, but the description adds no further 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, concise sentence that directly states the purpose. It contains no filler and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description adequately tells the agent what to expect: a list of connections with connected/disconnected status. It could potentially mention the format or additional fields, but for this simplicity level it is sufficiently complete.
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, so the baseline is 4. The description correctly implies that no inputs are needed, and there are no schema descriptions to supplement.
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 function: 'List all configured MySQL connections with their status (connected/disconnected)'. It uses a specific verb ('List') and resource ('MySQL connections'), and the status detail distinguishes it from sibling tools like mysql_list_databases or mysql_show_tables.
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. For example, it does not mention that this is for inspecting connection configurations rather than database content, nor does it reference any sibling tools for comparison.
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, the description must disclose behavioral traits, but it only states the core operation. It does not mention that this is a read-only action, what information is returned, whether it uses the default connection, or any error conditions. The description adds no behavioral context beyond the one-line summary.
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, front-loaded sentence that conveys the entire purpose with no filler or redundant information. It is optimally concise.
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?
The tool is simple with two parameters and no output schema, but the description does not explain the return format or connection behavior. Since there is no output schema, some return-value information would be helpful. The description is adequate but leaves the agent guessing about the result structure.
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 fully describes both parameters (alias and table_name) with 100% coverage. The description merely restates 'specific MySQL table', which maps to table_name, adding no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a specific resource 'indexes on a specific MySQL table', clearly distinguishing it from siblings like mysql_show_tables or mysql_describe_table. It is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear context: use this tool when you need indexes for a particular table. However, it does not explicitly mention when not to use it or name alternatives such as mysql_describe_table for column details, so it falls short of full guideline coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not state side effects, return format, or potential limitations. It adds minimal context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate but could be more complete by specifying the return format or the structure of the relationships returned. It is still sufficient for the tool's low complexity.
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% for the single optional 'alias' parameter. The description does not add any parameter-related meaning, but the schema already fully documents it, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all foreign key relationships between tables in the current database. This is a specific verb+resource+scope, and it distinguishes itself from sibling tools like mysql_list_indexes and mysql_describe_table.
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 for retrieving foreign key relationships but provides no explicit when-to-use or alternative guidance. It gives context ('in the current database') but no exclusions or comparisons with related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. 'Get' implies a read-only operation, and the description lists what will be returned. However, it does not disclose any potential side effects, permission requirements, or edge cases (e.g., behavior when no table is specified). It adds useful return-value context but lacks deeper operational transparency.
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, focused sentence that is front-loaded with the action and resource. Every word contributes meaning, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description sufficiently covers the return values (row count, data size, index size). The parameter behavior is fully documented in the schema. It is slightly thin on edge cases, but for the tool's simplicity, it is complete enough.
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 for both parameters (alias and table_name), so the schema already explains their meaning and optionality. The description adds no additional parameter-level context, keeping the score at the baseline for high schema coverage.
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 a specific verb ('Get') and resource ('table statistics') and details the exact statistics included ('row count, data size, and index size'). This distinguishes it from siblings like mysql_show_tables (list tables) and mysql_describe_table (structure).
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 usage is implied: use when you need table statistics like row count, data size, or index size. However, there is no explicit mention of when not to use it or which alternative tools to prefer (e.g., mysql_describe_table for structure), so it relies on the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: sequential execution, shared connection, and persistence of SET variables/temporary tables. However, it omits crucial error-handling behavior (e.g., whether a failing query interrupts the batch, rolls back, or continues) and does not mention transactionality, which is important for a multi-query execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and immediately states the core behavior, return format, and key connection semantics. Every sentence adds value; there is no filler.
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?
The description explains the return format and connection behavior, but for a batch execution tool, failure semantics are essential context. Without mentioning error handling, an AI agent may not correctly anticipate the tool's behavior when a query fails. This leaves a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both alias and queries, covering the baseline. The description adds meaningful context about how the queries interact (shared connection) and the return format ({query,result} pairs), enriching the semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Execute multiple SQL queries sequentially on a single connection,' clearly identifying the tool's function and distinguishing it from the singular mysql_execute_query sibling. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Useful for running several queries at once,' providing clear context for when to choose this tool. It does not explicitly name alternatives or exclusions, but implies that this is for multi-query scenarios. The shared-connection persistence is a practical usage consideration.
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:

[![db-gateway MCP server](https://glama.ai/mcp/servers/sijunkim/db-gateway/badges/card.svg)](https://glama.ai/mcp/servers/sijunkim/db-gateway)

Score Badge

Copy to your README.md:

[![db-gateway MCP server](https://glama.ai/mcp/servers/sijunkim/db-gateway/badges/score.svg)](https://glama.ai/mcp/servers/sijunkim/db-gateway)

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/sijunkim/db-gateway'

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