The DB Gateway MCP Server provides AI agents with direct access to databases across 8 engines (MySQL, PostgreSQL, Redshift, MongoDB, Redis, DynamoDB, Elasticsearch, Kafka) using 145+ tools, while keeping credentials hidden from the agent.
Query Execution: Run arbitrary SQL queries (mysql_execute_query) and batch multiple statements (mysql_execute_batch).
Schema Introspection: List databases/tables, describe structures, retrieve CREATE TABLE statements (single or all), and map foreign key relationships.
Performance Monitoring: Explain query plans, view running processes, inspect server status/variables, and gather table statistics.
Administration: Switch databases, list indexes, kill processes, and manage connections.
Multi-Instance Support: Connect to multiple instances of the same engine using aliases (e.g., dev and prod).
Read-Only Mode: Restrict agents to SELECT-only queries by setting READ_ONLY=true.
Selective Engine Registration: Only tools for specified engines are exposed, keeping the tool list clean.
Credential Safety: Agents reference only an alias; host, port, and password stay in the server configuration.
Provides tools for interacting with Elasticsearch, enabling search, indexing, and data exploration.
Provides tools for interacting with MongoDB, enabling operations on documents and collections, including schema discovery and data retrieval.
Provides tools for interacting with MySQL databases, including schema inspection, relationship discovery, and executing SQL queries.
Provides tools for interacting with PostgreSQL databases, including schema inspection, relationship discovery, and executing SQL queries.
Provides tools for interacting with Redis, enabling operations on data structures, keys, and cache management.
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., "@DB Gateway MCP Server Find users who signed up last month and never placed an order"
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.
English | 한국어
An MCP server that gives AI agents direct access to your databases — 145+ tools across 8 engines.
The point is that the agent reads your schema itself instead of you pasting DDL into a prompt:
You: "Find users who signed up last month and never placed an order"
1. mysql_get_all_schemas → reads every table definition
2. mysql_get_table_relationships → finds the users ↔ orders foreign key
3. mysql_execute_query → runs the LEFT JOINMost database MCP servers cover one engine, or a handful of relational ones. If your stack is MySQL for the app, Redshift for analytics, Redis for cache, and Kafka for events, that means four servers with four different config styles.
This is one server, one config block:
Engines | Tools | |
Relational | MySQL, PostgreSQL, Redshift | 59 |
NoSQL | MongoDB, Redis, DynamoDB | 48 |
Search | Elasticsearch | 19 |
Streaming | Kafka | 19 |
DBS decides which of them are enabled — only those tools get registered, so a MySQL-only setup stays a MySQL-only tool list.
Related MCP server: database-explorer-mcp
Every screenshot below is one real session against a development MySQL database holding 249 rows — unedited output, not mock data. The agent calls a single tool, mysql_execute_query, and never sees a host, port, or password: those stay in the client config, and the agent only ever names the alias.
Point the same server at production with READ_ONLY=true and steps 2 through 4 simply do not exist — the write tools are never registered, so the agent cannot see them to call them.
Requires Node.js 18+. Register it with your MCP client — no install step:
{
"mcpServers": {
"db-gateway": {
"command": "npx",
"args": ["-y", "db-gateway"],
"env": {
"DBS": "mysql,redis",
"MYSQL": "mysql://<user>:<password>@<host>:3306/<database>?alias=dev&default=true",
"REDIS": "redis://:@<host>:6379/0?alias=dev&default=true"
}
}
}
}DBS decides which engines are enabled — only those tools get registered.
One string per engine. Semicolons separate multiple instances.
Variable | Format |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
aliasis required. It is how tools address a specific instance — omit it and that engine fails to connect.
Several instances of the same engine — separate their connection strings with a semicolon. The agent picks one by passing an alias argument to any tool; default=true marks the one used when no alias is given:
MYSQL="mysql://<user>:<password>@<dev-host>:3306/<db>?alias=dev&default=true;mysql://<user>:<password>@<prod-host>:3306/<db>?alias=prod"DynamoDB is the exception — it takes DYNAMODB_REGION, DYNAMODB_ACCESS_KEY_ID, and DYNAMODB_SECRET_ACCESS_KEY instead. See .env.example for every option.
READ_ONLY=true hides write tools from the tool list entirely and restricts *_execute_query to SELECT-style statements.
Register production as a second MCP server with this flag on. The agent then cannot modify production data — the write tools do not exist as far as it can see.
"db-gateway-prod": {
"command": "npx",
"args": ["-y", "db-gateway"],
"env": { "READ_ONLY": "true", "DBS": "mysql", "MYSQL": "..." }
}Tool Reference — all 145+ tools, by engine
Connection Management — pooling, health checks, and why connectionLimit multiplies per session
Deployment — SSE mode, Nginx, PM2, sharing one gateway across a team
MIT
Describe the structure of a MySQL table
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| table_name | Yes | Name of the table to describe |
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.
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.
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.
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.
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.
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.
Execute multiple SQL queries sequentially on a single connection. Useful for running several queries at once. All queries share the same connection, so SET variables and temporary tables persist across queries. Returns an array of { query, result } pairs.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| queries | Yes | Array of SQL queries to execute sequentially |
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.
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.
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.
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.
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.
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.
Execute SQL query on MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| limit | No | Maximum number of rows to return (optional, truncates results if exceeded) | |
| query | Yes | SQL query to execute |
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.
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.
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.
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.
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.
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.
Get the execution plan for a SQL query (EXPLAIN)
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| query | Yes | SQL query to analyze (SELECT, UPDATE, DELETE, etc.) |
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.
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.
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.
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.
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.
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.
Get CREATE TABLE statements for all tables in the current database
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) |
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.
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.
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.
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.
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.
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.
Get the CREATE TABLE statement for a specific MySQL table
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| table_name | Yes | The name of the table to get the schema for |
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.
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.
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.
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.
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.
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.
Get all foreign key relationships between tables in the current database
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) |
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.
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.
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.
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.
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.
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.
Kill a MySQL connection/query by process ID
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| process_id | Yes | Process ID to kill (from SHOW PROCESSLIST) |
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.
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.
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.
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.
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.
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.
List all configured MySQL connections with their status (connected/disconnected)
| 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 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.
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.
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.
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.
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.
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.
List all databases the current user can see in MySQL
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) |
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.
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.
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.
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.
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.
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.
List all indexes on a specific MySQL table
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| table_name | Yes | Name of the table to list indexes for |
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.
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.
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.
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.
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.
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.
Show all running queries and connections in MySQL (SHOW FULL PROCESSLIST)
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) |
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.
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.
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.
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.
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.
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.
Show MySQL server status variables (connections, queries, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| pattern | No | LIKE pattern to filter status variables (e.g., 'Conn%', 'Threads%') |
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.
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.
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.
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.
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.
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.
Show all tables in the current MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) |
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.
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.
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.
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.
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.
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.
Show MySQL server configuration variables
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| pattern | No | LIKE pattern to filter variables (e.g., 'max_%', 'innodb%') |
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.
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.
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.
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.
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.
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.
Get table statistics including row count, data size, and index size
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| table_name | No | Name of a specific table (optional, shows all tables if not provided) |
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.
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.
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.
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.
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.
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.
Switch to a different MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| alias | No | MySQL connection alias (optional, uses default if omitted) | |
| database_name | Yes | Name of the database to switch to |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.2mysql_describe_tablemysql_execute_batchmysql_execute_querymysql_explain_querymysql_get_all_schemasmysql_get_schemamysql_get_table_relationshipsmysql_kill_processmysql_list_connectionsmysql_list_databasesmysql_list_indexesmysql_show_processlistmysql_show_statusmysql_show_tablesmysql_show_variablesmysql_table_statsmysql_use_databaseMost 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Database for your AI agent. Turn its output into data, docs, skills, and apps you can actually use.
Give your AI agents the tools to build, manage, and run automation workflows.
Direct access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
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
