Which integrations are available for this server?

Provides access to a MySQL database, allowing agents to execute SQL queries for reading data, creating tables, inserting, updating, and deleting records, with results returned in JSON format. Uses Node.js as the runtime environment for the MCP server, requiring v14 or higher for server operation.

How do I use MySQL MCP Server?

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 Server show me all users from the test_users table" 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 Server

by alittleyellowkevin

Overview Schema Related Servers Score Discussions

JavaScript

MySQL MCP Server

This is a Model Context Protocol (MCP) server that provides access to a MySQL database. It allows agent to execute SQL queries against a MySQL database.

Features

Execute SQL queries against a MySQL database:
- Read data (SELECT statements)
- Create tables (CREATE TABLE statements)
- Insert data (INSERT INTO statements)
- Update data (UPDATE statements)
- Delete data (DELETE FROM statements)
Returns query results in JSON format
Configurable database connection settings
Transaction logging with unique IDs

Related MCP server: MCP MySQL Server

Prerequisites

Node.js (v14 or higher)
MySQL server
MCP SDK

Installation

Clone or download this repository
Install dependencies:

cd mysql-mcp-server
npm install

Build the server:

npm run build

Configuration

The MySQL MCP server uses the following environment variables for configuration:

MYSQL_HOST: MySQL server hostname (default: 'localhost')
MYSQL_PORT: MySQL server port (default: 3306)
MYSQL_USER: MySQL username (default: 'mcp101')
MYSQL_PASSWORD: MySQL password (default: '123qwe')
MYSQL_DATABASE: MySQL database name (default: 'mcpdb')

Database Setup

Create a MySQL database:

CREATE DATABASE mcpdb;

Create a MySQL user with access to the database:

CREATE USER 'mcp101'@'localhost' IDENTIFIED BY '123qwe';
GRANT ALL PRIVILEGES ON mcpdb.* TO 'mcp101'@'localhost';
FLUSH PRIVILEGES;

Create a test table with sample data:

USE mcpdb;
CREATE TABLE test_users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO test_users (name, email) VALUES
  ('John Doe', 'john@example.com'),
  ('Jane Smith', 'jane@example.com'),
  ('Bob Johnson', 'bob@example.com');

MCP Configuration

Add the MySQL MCP server to your MCP settings file:

VSCode (Claude Extension)

File: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

Change the args according your MySQL configuruation

{
  "mcpServers": {
    "mysql-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "timeout": 60,
      "command": "node",
      "args": [
        "/path/to/mysql-mcp-server/build/index.js"
      ],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "mcp101",
        "MYSQL_PASSWORD": "123qwe",
        "MYSQL_DATABASE": "mcpdb"
      },
      "transportType": "stdio"
    }
  }
}

Claude Desktop App

File: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mysql-mcp-server": {
      "autoApprove": [],
      "disabled": false,
      "timeout": 60,
      "command": "node",
      "args": [
        "/path/to/mysql-mcp-server/build/index.js"
      ],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "mcp101",
        "MYSQL_PASSWORD": "123qwe",
        "MYSQL_DATABASE": "mcpdb"
      },
      "transportType": "stdio"
    }
  }
}

Usage

Once configured, you can use the MySQL MCP server in your conversations with Claude. For example:

"Can you show me all the users in the test_users table?"

Claude will use the run_sql_query tool to execute:

SELECT * FROM test_users

Available Tools

run_sql_query

Executes a read-only SQL query (SELECT statements only) against the MySQL database.

Parameters:

query: The SQL SELECT query to execute.

Example:

{
  "query": "SELECT * FROM test_users"
}

create_table

Creates a new table in the MySQL database.

Parameters:

query: The SQL CREATE TABLE query to execute.

Example:

{
  "query": "CREATE TABLE products (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), price DECIMAL(10,2))"
}

insert_data

Inserts data into a table in the MySQL database.

Parameters:

query: The SQL INSERT INTO query to execute.

Example:

{
  "query": "INSERT INTO products (name, price) VALUES ('Laptop', 999.99), ('Smartphone', 499.99)"
}

update_data

Updates data in a table in the MySQL database.

Parameters:

query: The SQL UPDATE query to execute.

Example:

{
  "query": "UPDATE products SET price = 899.99 WHERE name = 'Laptop'"
}

delete_data

Deletes data from a table in the MySQL database.

Parameters:

query: The SQL DELETE FROM query to execute.

Example:

{
  "query": "DELETE FROM products WHERE name = 'Smartphone'"
}

Security Considerations

Use a dedicated MySQL user with appropriate privileges for the MCP server
Consider using read-only privileges if you only need to query data
Store sensitive information like database credentials securely
All operations are logged with unique transaction IDs for auditing

Available Tools

6 tools

create_tableC

在 MySQL 数据库中创建新表

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL CREATE TABLE 语句

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While '创建新表' (create new table) implies a write/mutation operation, the description doesn't disclose permissions needed, whether the operation is reversible, potential side effects, error conditions, or what happens on success/failure. For a database mutation tool with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single sentence in Chinese that directly states the tool's purpose. There's zero waste or unnecessary elaboration. It's appropriately sized for a simple tool with one parameter.

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

Completeness2/5

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

For a database mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after table creation, what gets returned, error handling, or behavioral constraints. Given the complexity of database operations and the lack of structured metadata, the description should provide more complete context about the tool's behavior and outcomes.

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 schema already documents the single 'query' parameter as '要执行的 SQL CREATE TABLE 语句' (SQL CREATE TABLE statement to execute). The description doesn't add any additional parameter semantics beyond what's in the schema. With high schema coverage, baseline 3 is appropriate when the description doesn't enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the action ('创建新表' - create new table) and resource ('在 MySQL 数据库中' - in MySQL database), providing specific verb+resource. However, it doesn't distinguish this from sibling tools like 'execute_sql' or 'run_sql_query' which could also potentially create tables, so it doesn't fully differentiate from alternatives.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'execute_sql' or 'run_sql_query'. There's no mention of prerequisites, when-not-to-use scenarios, or explicit alternatives. The agent must infer usage context from the tool name alone.

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

delete_dataC

从 MySQL 数据库表中删除数据

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL DELETE FROM 语句

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While '删除数据' clearly indicates a destructive operation, it doesn't specify permissions required, whether deletions are reversible, transaction behavior, error handling, or what happens on success/failure. For a destructive tool with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient Chinese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.

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

Completeness2/5

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

For a destructive database operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, return values, error conditions, or safety considerations. Given the high-risk nature of data deletion and lack of structured metadata, more contextual information is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single 'query' parameter as a SQL DELETE FROM statement. The description adds no additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the action ('删除数据' - delete data) and target resource ('从 MySQL 数据库表中' - from MySQL database table). It distinguishes from siblings like insert_data and update_data by specifying deletion. However, it doesn't explicitly differentiate from execute_sql or run_sql_query which could also perform deletions.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like execute_sql or run_sql_query. It doesn't mention prerequisites, when-not-to-use scenarios, or compare functionality with sibling tools. The agent must infer usage from the tool name alone.

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

execute_sqlA

执行任意非 SELECT 的 SQL 语句（如 ALTER TABLE、DROP 等）

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL 语句

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this executes SQL statements (implying write/mutation operations), it doesn't disclose important behavioral traits like authentication requirements, transaction handling, error behavior, or whether changes are reversible. For a tool that can execute destructive operations like DROP, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) and front-loaded with all essential information. Every word earns its place by specifying the tool's scope (non-SELECT SQL), providing examples, and distinguishing from alternatives. There's zero waste or redundancy.

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

Completeness2/5

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

For a tool that can execute potentially destructive SQL operations (DROP, ALTER TABLE) with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what permissions are required, whether transactions are supported, what happens on errors, or what the return format looks like. The description does well on purpose and usage but misses important behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with the single 'query' parameter well-documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides ('要执行的 SQL 语句'). The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 specific verbs ('执行任意非 SELECT 的 SQL 语句') and resources (SQL statements like ALTER TABLE, DROP). It explicitly distinguishes from SELECT operations, which helps differentiate from sibling tools like 'run_sql_query' that likely handles SELECT queries.

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?

The description provides explicit usage guidelines by stating '非 SELECT 的 SQL 语句' (non-SELECT SQL statements) and giving examples like ALTER TABLE and DROP. This clearly indicates when to use this tool versus alternatives like 'run_sql_query' (likely for SELECT) and other siblings that handle specific operations (create_table, delete_data, etc.).

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

insert_dataC

向 MySQL 数据库表插入数据

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL INSERT INTO 语句

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an insert operation but reveals nothing about permissions required, whether it's idempotent, what happens on constraint violations, transaction behavior, or what the response contains. For a database mutation tool with zero annotation coverage, this leaves critical behavioral aspects unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential information. Every word earns its place in conveying the tool's function.

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

Completeness2/5

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

For a database mutation tool with no annotations, no output schema, and multiple similar siblings, the description is incomplete. It doesn't address critical context like error handling, return values, transaction boundaries, or differentiation from other SQL tools. The agent lacks sufficient information to use this tool effectively in complex scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with the single parameter 'query' documented as '要执行的 SQL INSERT INTO 语句' (SQL INSERT INTO statement to execute). The description adds no additional parameter context beyond what the schema already provides. With high schema coverage, the baseline score of 3 is appropriate - the description doesn't enhance parameter understanding but doesn't need to compensate for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the action ('插入数据' - insert data) and target resource ('向 MySQL 数据库表' - to MySQL database table), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'update_data' or 'delete_data', but the verb 'insert' provides inherent differentiation. This is better than vague but lacks explicit sibling comparison.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'update_data', 'delete_data', or 'execute_sql'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone, which is insufficient given multiple SQL-related siblings.

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

run_sql_queryA

执行只读 SQL 查询（仅限 SELECT 语句）

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL SELECT 查询语句

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only and limited to SELECT statements, which is helpful context. However, it lacks details on potential behavioral traits like error handling, result formatting, timeouts, or authentication requirements, leaving gaps for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded with a single sentence in Chinese that directly states the tool's function and limitations. There is no wasted text, and every word earns its place by clarifying the scope (read-only, SELECT-only).

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

Completeness3/5

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

Given the tool's complexity (SQL execution), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and restrictions but misses details like return format, error cases, or performance considerations. For a tool with no structured output documentation, more context would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'query' parameter documented as '要执行的 SQL SELECT 查询语句' (SQL SELECT query statement to execute). The description doesn't add any additional meaning beyond what the schema provides, such as syntax examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the tool's purpose as '执行只读 SQL 查询（仅限 SELECT 语句）', which translates to 'execute read-only SQL queries (only SELECT statements)'. This specifies both the verb ('execute') and resource ('SQL queries') with a clear restriction to SELECT statements. However, it doesn't explicitly differentiate from sibling tools like 'execute_sql', which might handle other SQL operations.

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 clear context for when to use this tool by specifying '只读' (read-only) and '仅限 SELECT 语句' (only SELECT statements). This implicitly guides usage for read operations versus siblings like 'insert_data' or 'update_data' for writes. However, it doesn't explicitly name alternatives or state when not to use it, such as for non-SELECT queries.

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

update_dataC

更新 MySQL 数据库表中的数据

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	要执行的 SQL UPDATE 语句

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates data, implying a mutation operation, but does not disclose critical traits such as whether it requires specific database permissions, if changes are reversible, potential side effects on related data, or error handling. This leaves significant gaps in understanding the tool's behavior beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it easy to understand at a glance while avoiding redundancy or fluff.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It does not explain what the tool returns (e.g., success status, affected rows), error conditions, or behavioral nuances like transaction handling. Given the complexity of database updates and the lack of structured data, more context is needed to ensure safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'query' parameter clearly documented as '要执行的 SQL UPDATE 语句' (the SQL UPDATE statement to execute). The description does not add any meaning beyond what the schema provides, as it only reiterates the general purpose without detailing parameter usage or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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

The description clearly states the action ('更新' meaning 'update') and the target resource ('MySQL 数据库表中的数据' meaning 'data in MySQL database tables'), providing a specific verb+resource combination. However, it does not distinguish this tool from its sibling 'execute_sql' or 'run_sql_query', which could also potentially update data, leaving some ambiguity about its unique role.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'execute_sql' or 'delete_data'. It lacks explicit instructions on prerequisites, such as requiring a valid SQL UPDATE statement, or context for when it is appropriate compared to other data manipulation tools in the sibling list.

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

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a distinct and clear purpose with no overlap: create_table for table creation, delete_data for deletion, execute_sql for non-SQL operations, insert_data for insertion, run_sql_query for read-only queries, and update_data for updates. The separation between execute_sql (non-SELECT) and run_sql_query (SELECT) is particularly well-defined, preventing confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, such as create_table, delete_data, and run_sql_query. This uniformity makes the tool set predictable and easy for an agent to navigate, with no deviations in naming conventions.

Tool Count5/5

With 6 tools, this server is well-scoped for basic MySQL database operations, covering essential CRUD actions and SQL execution. Each tool serves a specific function without redundancy, making the count appropriate for the domain and avoiding both over-saturation and under-coverage.

Completeness4/5

The tool set provides strong coverage for core database operations, including create, read (via run_sql_query), update, and delete, plus general SQL execution. A minor gap exists in lacking tools for table deletion or schema inspection, but agents can work around this using execute_sql for such tasks, keeping the surface largely complete for typical workflows.

Resources

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

Mercado Pago
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
Google Big Query A
com.googleapis.bigquery
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Databases Cloud Platforms Search
63

Related MCP Servers

MySQL-MCP
Databases RAG Systems
zajTools
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables SQL query execution, database management, and business intelligence capabilities through MySQL connections.
Updated 2 years ago (2025-03-03 08:44 UTC)
1,090
MIT
MCP MySQL Server
Databases Developer Tools Code Execution
Atomzzm
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI models to interact with MySQL databases, providing tools for querying, executing statements, listing tables, and describing table structures.
Updated 2 years ago (2025-02-22 00:55 UTC)
5
342
MIT
MCP MySQL Server
Databases Developer Tools
kevinbin
F
license
B
quality
D
maintenance
A Model Context Protocol server that enables AI models to interact with MySQL databases through a standardized interface, providing tools for querying, executing commands, and managing database schemas.
Updated a year ago (2025-03-08 03:37 UTC)
7
MySQL MCP Server
Databases Search
caicongyang
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI models to interact with MySQL databases through natural language, supporting SQL queries, table creation, and schema exploration.
Updated a year ago (2025-06-02 14:57 UTC)
3

Appeared in Searches

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/alittleyellowkevin/Mysql-MCP'

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