Which integrations are available for this server?

Provides secure, read-only access to MySQL databases, enabling query execution, schema exploration, query plan explanation, and data sampling.

How do I use mysql-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mysql-mcp show me the tables in the inventory database" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mysql-mcp

by qxduddes

Overview Schema Related Servers Score Discussions

Python

Hybrid

mysql-mcp

Secure, read-only MySQL access for AI agents. A Model Context Protocol (MCP) server that lets Claude, Cursor, and other MCP clients explore and query MySQL/MariaDB databases — with no ability to write, no way to retarget the connection, and no credentials in the model context.

Python (FastMCP) port of @nilsir/mcp-server-mysql, restricted to the read-only tool surface and hardened against the risks of connecting an LLM to a live database.

Value proposition

Enterprise data lives in MySQL/MariaDB (application databases, analytics replicas, Amazon RDS/Aurora). mysql-mcp exposes that data to AI agents and analysts for reading only through a zero-trust-oriented interface:

Read-only by construction — there are no write/DDL tools. The query tool accepts only SELECT/SHOW/DESCRIBE/EXPLAIN and additionally blocks file-I/O and stall primitives (INTO OUTFILE, SLEEP, GET_LOCK, BENCHMARK, LOAD_FILE).
Credentials never enter the model context — connection details come only from the server's environment; no tool accepts a host, user, or password.
Fail-closed HTTP — the network transport refuses to start without a bearer token.
Bounded — per-query time limits, a result-row cap, connect timeouts, and single-statement enforcement.
Auditable — one structured JSON log record per tool call (never SQL text, values, or credentials).

The read-only scope and these controls answer the audit that drove this port; see SECURITY.md and docs/security/governance.md.

Related MCP server: mysql-readonly-mcp

Capabilities (9 read-only tools)

Tool	Purpose
`query`	Run one `SELECT`/`SHOW`/`DESCRIBE`/`EXPLAIN` statement (with `%s` bind params)
`explain_query`	Return the execution plan of a `SELECT` (traditional or JSON)
`list_databases`	List databases
`list_tables`	List tables in a database
`describe_table`	Column structure of a table
`inspect_schema`	All tables + columns + indexes of a database at once
`find_tables`	Find tables by table/column name substring
`sample_rows`	Small row sample from a table (max 50)
`health_check`	Connection health + server status

Full request/response schemas and error codes: docs/interface/primitives.md.

Note: this server exposes MCP Tools only. It does not expose MCP Resources or Prompts (see the roadmap notes in docs/interface/primitives.md).

Agent Integration Quickstart

First create a least-privilege MySQL account (do not use root):

CREATE USER 'mcp_ro'@'%' IDENTIFIED BY '<strong-secret>';
GRANT SELECT, SHOW VIEW ON app_db.* TO 'mcp_ro'@'%';

Then wire up your client. Ready-to-copy files live in examples/.

Claude Desktop (stdio, run straight from git via `uvx`)

Requires uv (brew install uv). No clone, no virtualenv — uvx fetches, builds, caches, and runs the mysql-mcp console script. Edit Settings → Developer → Edit Config:

{
  "mcpServers": {
    "mysql": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/<org>/mcp-mysql-server@<tag>",
        "mysql-mcp"
      ],
      "env": {
        "MYSQL_HOST": "your-db-host",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "mcp_ro",
        "MYSQL_PASSWORD": "<strong-secret>",
        "MYSQL_DATABASE": "app_db",
        "MYSQL_SSL": "true"
      }
    }
  }
}

Pin @<tag> (e.g. @v0.1.0) — never track a mutable branch. Running unpinned code straight from git is a supply-chain risk.

Cursor (stdio)

Add to ~/.cursor/mcp.json (or the project .cursor/mcp.json):

{
  "mcpServers": {
    "mysql": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/<org>/mcp-mysql-server@<tag>", "mysql-mcp"],
      "env": {
        "MYSQL_HOST": "your-db-host",
        "MYSQL_USER": "mcp_ro",
        "MYSQL_PASSWORD": "<strong-secret>",
        "MYSQL_DATABASE": "app_db",
        "MYSQL_SSL": "true"
      }
    }
  }
}

Enterprise AI gateway (Streamable HTTP + bearer token)

For a shared, centrally-hosted deployment, run the server in HTTP mode (see docs/setup.md) and point your gateway at it. Credentials for one or more databases are configured server-side via DB_PROFILES; clients select a profile per call with db_id and authenticate with a bearer token:

{
  "mcpServers": {
    "mysql": {
      "type": "http",
      "url": "https://mysql-mcp.internal.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MYSQL_MCP_TOKEN}"
      }
    }
  }
}

Authorization note: the bearer token is a single shared secret; any holder can reach every configured DB_PROFILES profile. Per-client / per-profile authorization is not yet implemented — see docs/security/governance.md (SEC-003).

Documentation

Area	Document
Deployment & onboarding	docs/setup.md
MCP contract (tools, schemas, errors)	docs/interface/primitives.md
Transports (stdio vs HTTP)	docs/interface/transport.md
Enterprise governance (authn/authz, privacy, audit)	docs/security/governance.md
Security policy & reporting	SECURITY.md
Contributing & tool-testing standards	CONTRIBUTING.md
Change history	CHANGELOG.md
Working with the codebase (for AI coding agents)	CLAUDE.md

Requirements

Python ≥ 3.12
MySQL 5.7+/8.x or MariaDB 10.1+ to connect to
Docker (optional, for the HTTP container)
uv (optional, for uvx git-based launch)

License & status

Version 0.1.0. See CHANGELOG.md. [TODO: Insert Organization license and support statement].

Available Tools

9 tools

describe_tableDescribe tableA

Read-only

Get the column structure of a table (DESCRIBE output).

Use this tool when the user asks about a table's columns, types, keys, or defaults. Returns JSON: {table, database, columns: [{Field, Type, Null, Key, Default, Extra}]}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: a header card with the table name and a columns table card (name, type, nullable, key, default).

Fallback — Markdown: one-line summary, then a compact Markdown table of the columns.

Formatting rules (both modes): never paste raw JSON unless explicitly asked; highlight primary keys in the summary.

ParametersJSON Schema

Name	Required	Description
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`table`	Yes	Table name.
`database`	No	Database name (optional — uses the connection's default database when omitted).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses the return format (JSON structure), presentation rules (never mention tool name, card-based layout, not pasting raw JSON), and behavior (highlighting primary keys). This adds substantial behavioral context not available from annotations alone.

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 relatively long but well-structured with sections for purpose, usage, return format, and presentation. Every sentence serves a purpose, though it could be tightened without losing essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple describe tool, the description covers purpose, usage, output format, and presentation rules. The presence of an output schema further reduces the need to explain return values. It is complete for the tool's 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?

Schema coverage is 100% for all parameters. The description does not add extra parameter-level detail beyond what the schema already 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 clearly states the tool's purpose with a specific verb and resource: 'Get the column structure of a table (DESCRIBE output).' It distinguishes from siblings by focusing on column metadata (types, keys, defaults) rather than querying or listing tables.

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 provides explicit usage context: 'Use this tool when the user asks about a table's columns, types, keys, or defaults.' It does not explicitly mention alternatives or exclusions, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_queryExplain query planA

Read-only

Run EXPLAIN on a SELECT query and return the execution plan.

Use this tool when the user asks why a query is slow, whether an index is used, or how MySQL will execute a SELECT. Only SELECT statements are accepted (not SHOW/DESCRIBE/EXPLAIN).

Returns JSON: {format, originalSql, explainSql, rowCount, rows} where rows contain the plan.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the analysis.

Preferred rendering — card-based layout: when the client supports rich widgets or HTML artifacts, render a header card with the query, a plan table card (access type, key, rows examined), and a highlights card calling out full scans or missing indexes.

Fallback — Markdown: one-line verdict first (e.g. "uses index X"), then a compact Markdown table of the plan rows.

Formatting rules (both modes): explain the plan in plain language; never paste raw JSON unless explicitly asked.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	A single SELECT statement to analyze. Use %s placeholders for bind values passed via params_json.
`db_id`	No	Optional named database profile configured on the server.
`format`	No	EXPLAIN output format: 'traditional' (default) or 'json'.	traditional
`params_json`	No	Optional JSON array of scalar bind values for %s placeholders.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses accepted input types, output JSON structure, and presentation constraints such as 'never mention this tool's name' and 'never paste raw JSON unless explicitly asked.' This adds substantial behavioral context beyond annotations.

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 well-structured: front-loaded purpose, then usage guidance, output structure, and presentation rules. Every section earns its place, and there is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers tool behavior: what it accepts, what it returns, how to present results, and formatting rules. With the readOnlyHint annotation and output schema present, this is complete for a read-only analysis tool.

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?

Schema covers all 4 parameters with descriptions (100% coverage), so baseline is 3. However, the description adds the critical constraint that sql must be a SELECT statement and not SHOW/DESCRIBE/EXPLAIN, which is not present in the schema. This adds meaningful parameter semantics.

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 'Run EXPLAIN on a SELECT query and return the execution plan.' This is a specific verb+resource statement that distinguishes the tool from siblings (query, describe_table) by focusing on execution plans and explicitly restricting to SELECT statements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this tool when the user asks why a query is slow, whether an index is used, or how MySQL will execute a SELECT.' Also provides exclusions: 'Only SELECT statements are accepted (not SHOW/DESCRIBE/EXPLAIN).' This is clear guidance with context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_tablesFind tablesA

Read-only

Find tables by matching table or column names.

Use this tool when the user knows roughly what they're looking for ("something with customer emails") but not the exact table. Returns JSON: {database, term, matchCount, matches: [{tableName, tableType, engine, matchedTableName, matchedColumns}]}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: a header card with the search term and one row per match showing why it matched (name vs columns).

Fallback — Markdown: one-line summary (match count), then a compact Markdown table of matches.

Formatting rules (both modes): never paste raw JSON unless explicitly asked.

ParametersJSON Schema

Name	Required	Description
`term`	Yes	Search term matched against table and column names.
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`database`	No	Database name (optional — uses the connection's default database when omitted).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses the return JSON structure, matching behavior on both table and column names, and critical presentation instructions (never mentioning the tool name, rendering modes). This is substantial behavioral context that helps the agent act correctly.

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 well-structured with front-loaded purpose, followed by usage, return format, and presentation rules. It is longer than typical but every section serves a distinct purpose, and the presentation rules are essential for correct agent behavior. Slightly verbose but not wasteful.

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?

Given the tool's moderate complexity, the rich schema (100% coverage), and the presence of an output schema, the description is complete: it covers search behavior, usage, output structure, and presentation. It does not need to explain return values (output schema exists). Minor gaps like case sensitivity or matching semantics are not critical for basic invocation.

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 has 100% coverage with descriptions for all three parameters. The description adds minimal extra meaning beyond the schema—it mainly clarifies that 'term' matches names, which is already in the schema. Baseline 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 opens with a specific verb and resource: 'Find tables by matching table or column names.' This clearly distinguishes the tool from siblings like list_tables (which lists all tables) and describe_table (which describes a specific table). The purpose is 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?

The description states when to use the tool: 'Use this tool when the user knows roughly what they're looking for... but not the exact table.' This is clear usage guidance. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

health_checkCheck database healthA

Read-only

Check MySQL connection health and basic server status.

Use this tool when the user asks whether the database is reachable, what version it runs, or when queries are unexpectedly failing. Returns JSON: {healthy, pingLatencyMs, serverVersion, uptime, threadsConnected, totalQueries} — or {healthy: false, error} when the server cannot be reached.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the status.

Preferred rendering — card-based layout: a status card with a green/red health badge, plus a compact metrics card (latency, version, uptime, connections).

Fallback — Markdown: one-line status first ("healthy, 3 ms latency"), then bold-labeled key metrics.

Formatting rules (both modes): render uptime in human units (days/ hours); never paste raw JSON unless explicitly asked.

ParametersJSON Schema

Name	Required	Description	Default
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnlyHint annotation by detailing the exact JSON response shape for both success and failure scenarios, and by specifying precise presentation rules (card layout, Markdown fallback, never mention tool name, format uptime in human units). This equips the agent to handle the tool's output correctly and addresses all behavioral nuances.

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 well-structured and front-loaded with the purpose and usage, followed by return format and formatting rules. It is somewhat lengthy but every sentence contributes necessary information, especially the output and presentation details. It could be tightened, but the organization is logical and not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description is comprehensive: it covers purpose, usage triggers, output schema (via example JSON), error handling, and rendering instructions. The presence of an output schema further reduces the need to explain return values. Nothing essential is missing for an agent to use this tool effectively.

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, db_id, is fully described in the input schema with clear semantics ('Optional named database profile configured on the server'). The tool description adds no additional meaning, but with 100% schema description coverage, the baseline of 3 is justified.

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: 'Check MySQL connection health and basic server status.' It uses a specific verb and resource, and the distinction from sibling tools (query, list_tables, etc.) is obvious. This is a focused health check tool with no ambiguity.

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 provides explicit when-to-use guidance: 'when the user asks whether the database is reachable, what version it runs, or when queries are unexpectedly failing.' It does not name alternatives or mention when not to use it, but the context is clear enough that no exclusions are needed. Since no alternative is explicitly provided, a 4 is appropriate rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_schemaInspect schemaA

Read-only

Inspect all tables, columns, and indexes of a database at once.

Use this tool when the user wants an overview of a whole schema — e.g. to understand an unfamiliar database or plan queries. Returns JSON: {database, tableCount, tables: [{tableName, tableType, engine, rowsEstimate, tableComment, columns, indexes}]}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: a header card for the database (table count), then one card per table with its columns and indexes as compact tables.

Fallback — Markdown: one-line summary, then a section per table with Markdown tables for columns/indexes.

Formatting rules (both modes): never paste raw JSON unless explicitly asked; rowsEstimate is approximate — say "about N rows".

ParametersJSON Schema

Name	Required	Description
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`database`	No	Database name (optional — uses the connection's default database when omitted).
`include_columns`	No	Include per-table column details (default true).
`include_indexes`	No	Include per-table index details (default true).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite annotations already declaring readOnlyHint=true, the description adds substantial behavioral context: the exact return JSON structure, presentation rules ('never mention this tool's name...'), fallback formats, and the caveat that rowsEstimate is approximate. This goes well beyond the annotation and helps the agent set correct expectations.

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 longer than average but well-organized: purpose, usage, return format, presentation, and formatting rules each have their own sentence group. It front-loads the core purpose and every sentence adds practical guidance, though a couple of formatting details could be tightened without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with nested outputs, the description is remarkably complete. It explains the return structure, the rendering modes (card vs Markdown), forbidden actions (raw JSON), and approximation caveats. Even with an output schema present, the description adds enough contextual detail to fully prepare the agent for invocation and response formatting.

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 all four parameters (db_id, database, include_columns, include_indexes) are already documented in the input schema. The description adds no additional parameter semantics, which is acceptable given full schema coverage. 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 opens with a specific verb+resource+scope: 'Inspect all tables, columns, and indexes of a database at once.' This clearly differentiates from sibling tools like list_tables or describe_table by emphasizing the whole-schema scope. The purpose is unambiguous and concrete.

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?

Explicitly states when to use: 'Use this tool when the user wants an overview of a whole schema — e.g. to understand an unfamiliar database or plan queries.' Provides clear context and example scenarios, but does not name alternative tools or state when not to use it, so it misses the full 'alternatives' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_databasesList databasesA

Read-only

List all databases visible to the configured MySQL account.

Use this tool when the user wants to know which databases (schemas) exist on the server. Returns JSON: {databases: [...]}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: when the client supports rich widgets, render a single card with the database names as a clean list or chips.

Fallback — Markdown: one-line summary (count), then a bulleted list.

Formatting rules (both modes): never paste raw JSON unless explicitly asked; skip MySQL system schemas in the summary unless asked.

ParametersJSON Schema

Name	Required	Description	Default
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral detail beyond the readOnlyHint annotation: it discloses the exact JSON return format, instructs the agent to never mention the tool's name, defines card vs. Markdown rendering rules, and specifies skipping system schemas unless asked. These are concrete behaviors that aid invocation and response formatting, going well beyond the annotation.

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 well-structured and front-loaded with purpose, then usage, then return format, and finally presentation/formatting. Every sentence contributes essential information for the agent to act correctly, including rendering details that would otherwise be missing. Nothing is redundant or verbose relative to the tool's needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no required parameters) and the existence of an output schema (as indicated in context signals), the description is complete: it explains the purpose, when to use, the return shape, how to present results, and formatting exceptions. There are no gaps that would prevent an agent from using the tool effectively.

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 contains a complete description of the single optional parameter `db_id`, achieving 100% schema coverage. The tool description does not add further parameter-level context; it only implicitly references the default connection when omitting the parameter. Per the rubric, a 3 is the baseline when schema covers all parameters, and no extra semantics are provided.

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 opens with a specific verb-resource statement: 'List all databases visible to the configured MySQL account.' This clearly distinguishes the tool from siblings like list_tables or describe_table, which target tables or schemas. It also uses the synonym 'schemas' to remove ambiguity, making the purpose absolutely clear.

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 second sentence explicitly states when to use: 'Use this tool when the user wants to know which databases (schemas) exist on the server.' It gives clear context, though it does not name exclusionary conditions or direct users to alternative sibling tools for other intents. That keeps it a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesList tablesA

Read-only

List tables in a database.

Use this tool when the user wants to see what tables exist. Returns JSON: {tables: [...], database}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: a header card naming the database and a table-list card.

Fallback — Markdown: one-line summary (database + count), then a bulleted list of tables.

Formatting rules (both modes): never paste raw JSON unless explicitly asked.

ParametersJSON Schema

Name	Required	Description	Default
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`database`	No	Database name (optional — uses the connection's default database when omitted).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint: true, so the bar for additional disclosure is lower. The description adds significant behavioral context: it specifies the return format (JSON object with tables and database), and details on presentation (never mention tool name, card vs. Markdown layout, formatting rules). This goes well beyond the annotation.

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 well-organized with clear sections (purpose, usage, return format, presentation). It is more verbose than strictly necessary, but every section contributes useful guidance. The first sentence immediately conveys the core action, and the structured formatting rules are justified for consistent agent output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool, the description covers all essential aspects: what it does, when to use it, what it returns, and how to format the answer. The presence of an output schema and annotations covers remaining structural details, making the description comprehensive.

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 both parameters (db_id and database) well-documented in the schema itself. The description does not add parameter-specific details, but the schema already explains optionality and defaults, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List tables in a database' with a specific verb and resource. It further clarifies the purpose ('when the user wants to see what tables exist') and distinguishes from sibling tools like list_databases and describe_table by focusing on the list of tables.

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 explicitly says 'Use this tool when the user wants to see what tables exist,' providing a clear use case. However, it does not mention alternatives or when not to use it, so it stops short of full comparative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

queryRun read-only SQL queryA

Read-only

Execute a read-only SQL query and return rows as JSON.

Use this tool when the user wants to read data with SQL: filtering, joining, aggregating, or ad-hoc questions the schema tools cannot answer. Only SELECT / SHOW / DESCRIBE / EXPLAIN statements are accepted; INSERT/UPDATE/DELETE/DDL are refused — this server is strictly read-only. File-writing and lock functions (INTO OUTFILE, SLEEP, GET_LOCK, BENCHMARK, LOAD_FILE) are also refused.

Placeholders: use %s (PyMySQL style), not ?, and pass the values as a JSON array in params_json.

Returns JSON: {rows, rowCount, truncated, maxRows}. When truncated is true, the result was capped at maxRows rows.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the retrieved data.

Preferred rendering — card-based layout: when the client supports rich widgets or HTML artifacts, render a header card (query intent), a results table card, and a footer card with row count and a truncation notice if applicable.

Fallback — Markdown: one-line summary first, then a compact Markdown table of the rows.

Formatting rules (both modes): human-readable dates and numbers; never paste raw JSON unless explicitly asked; mention truncation when truncated is true; omit internal fields the user did not ask about.

ParametersJSON Schema

Name	Required	Description
`sql`	Yes	One read-only SQL statement (SELECT, SHOW, DESCRIBE, or EXPLAIN). Multi-statement input is rejected. Use %s placeholders for bind values passed via params_json.
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`params_json`	No	Optional JSON array of scalar bind values for %s placeholders, e.g. '["ACME", 10]'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses the exact allowed statements (SELECT/SHOW/DESCRIBE/EXPLAIN), explicitly refuses writes and dangerous functions (INTO OUTFILE, SLEEP, GET_LOCK, BENCHMARK, LOAD_FILE), explains placeholder syntax, and specifies the return JSON shape including truncation behavior. It even details presentation rules and warns against mentioning the tool name, all of which are valuable behavioral insights not captured by annotations.

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 long but exceptionally well-structured: it opens with a crisp purpose, then systematically covers usage context, safety restrictions, placeholder syntax, return format, and presentation rules. Every sentence earns its place given the tool's complexity and the number of constraints an agent must understand to invoke it correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This description is fully complete for a tool of this complexity with an output schema. It covers accepted and refused operations, placeholder conventions, result truncation, and even output formatting for both rich and Markdown contexts. No ambiguity remains about how to select, invoke, or interpret the result of this 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the placeholder style ('use %s, not ?') and the params_json format, but these are already stated in the input schema. It adds no substantially new parameter-level semantics beyond what the schema already provides.

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 opens with a specific verb+resource ('Execute a read-only SQL query and return rows as JSON') and clearly distinguishes itself from siblings by targeting ad-hoc read queries with filtering, joining, aggregating, and questions the schema tools cannot answer. It also explicitly enumerates allowed statement types, leaving no ambiguity about its scope.

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 provides explicit guidance on when to use this tool ('when the user wants to read data with SQL... or ad-hoc questions the schema tools cannot answer') and implicitly excludes write operations by listing refused statements. However, it does not name specific sibling alternatives (e.g., describe_table) as fallbacks, so the guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sample_rowsSample table rowsA

Read-only

Read a small sample of rows from a table (capped at 50).

Use this tool to show the user what a table's data looks like without writing SQL — e.g. right after describe_table. Returns JSON: {database, table, limit, rowCount, rows}.

Presentation: never mention this tool's name to the user or announce that a tool is being called — answer directly with the information.

Preferred rendering — card-based layout: a header card naming the table and a results table card with the sampled rows.

Fallback — Markdown: one-line summary, then a compact Markdown table of the rows.

Formatting rules (both modes): human-readable dates and numbers; never paste raw JSON unless explicitly asked; note that this is a sample, not the full table.

ParametersJSON Schema

Name	Required	Description
`db_id`	No	Optional named database profile configured on the server. Omit to use the server's default connection.
`limit`	No	Number of rows to sample (default 5, max 50).
`table`	Yes	Table name to sample from.
`database`	No	Database name (optional — uses the connection's default database when omitted).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnlyHint=true, but the description adds significant behavioral context: the return JSON structure, the 50-row cap, and detailed presentation instructions (never mention the tool name, card-based layout, formatting rules, note that it's a sample). This goes well beyond the annotation, providing the agent with clear expectations for output and interaction.

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 longer than average due to presentation and formatting rules, but it is front-loaded with the core purpose and well-organized into paragraphs. Every sentence provides value for correct invocation and presentation; only minor trimming could make it even crisper.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, output schema, and readOnly annotation, the description covers purpose, when to use it, return format, presentation, and formatting rules. It is sufficiently complete for an agent to select and invoke the tool correctly, with no notable 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 already covers all parameters with descriptions (coverage 100%). The description does not add extra meaning to the parameters themselves; it only references 'table' and 'limit' in the return structure. Per the baseline rule for high schema coverage, a 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 opens with 'Read a small sample of rows from a table (capped at 50)' — a specific verb, resource, and scope. It clearly distinguishes itself from sibling 'query' by noting 'without writing SQL', and from 'describe_table' by implying it shows data, not schema.

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?

Description explicitly says 'Use this tool to show the user what a table's data looks like without writing SQL' and gives an example ('right after describe_table'). However, it does not explicitly mention when not to use it or name alternative tools, though the 'without writing SQL' caveat implies distinction from 'query'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.0Aug 2, 2026
- First observeddescribe_table
- First observedexplain_query
- First observedfind_tables
- First observedhealth_check
- First observedinspect_schema
- First observedlist_databases
- First observedlist_tables
- First observedquery
- First observedsample_rows

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: listing schemas, running SQL, explaining plans, listing tables, describing columns, inspecting full schemas, searching tables, sampling rows, and checking health. The overlapping table-related tools are clearly differentiated by scope and use case.

Naming Consistency4/5

Most tools follow a verb_noun pattern (list_tables, describe_table, inspect_schema, sample_rows, explain_query). Two exceptions stand out: 'query' is a bare noun and 'health_check' is a noun_noun compound, breaking the otherwise consistent convention.

Tool Count5/5

Nine tools is a well-scoped set for a read-only MySQL server. Every tool covers a distinct need without redundancy or bloat.

Completeness5/5

The set covers the full read-only lifecycle: discovery (list_databases, list_tables), schema inspection (describe_table, inspect_schema, find_tables), data access (query, sample_rows), performance analysis (explain_query), and operational status (health_check). No significant gaps exist for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
Dataassist-IOOAuth
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2

Related MCP Servers

mysql-mcp
Databases Developer Tools
rlembo06
A
license
Not graded
quality
D
maintenance
A lightweight MCP server providing safe, read-only access to MySQL databases. It enables users to query multiple MySQL instances securely while preventing write operations.
Updated 5 months ago (2026-04-13 14:19 UTC)
1,090
MIT
mysql-readonly-mcp
Databases Developer Tools
a1030307996-hash
A
license
Not graded
quality
C
maintenance
Read-only MySQL MCP server for safe schema inspection and SELECT-style queries.
Updated 2 months ago (2026-06-22 06:53 UTC)
33
MIT
mcp-database
Databases Developer Tools
AimanFadillah
A
license
A
quality
C
maintenance
Read-only MySQL/MariaDB MCP server for running SELECT queries safely, with automatic read-only enforcement and query limits.
Updated 3 months ago (2026-06-04 02:38 UTC)
3
14
MIT
MySQL MCP Server
Databases Developer Tools
boyzoid
F
license
Not graded
quality
D
maintenance
Provides read-only access to MySQL databases, enabling schema exploration, table inspection, and safe SELECT query execution via MCP.
Updated 7 months ago (2026-02-16 17:58 UTC)
1
-

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/qxduddes/mcp-server-mysql'

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

mysql-mcp

Value proposition

Capabilities (9 read-only tools)

Agent Integration Quickstart

Claude Desktop (stdio, run straight from git via uvx)

Cursor (stdio)

Enterprise AI gateway (Streamable HTTP + bearer token)

Documentation

Requirements

License & status

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop (stdio, run straight from git via `uvx`)