Skip to main content
Glama
Himanshu-Agg12

mcp-mysql-lens

by Himanshu-Agg12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

MCP MySQL Lens

A Model Context Protocol (MCP) server that enables Claude Desktop to interact with MySQL databases directly. This server allows Claude to query, analyze, and manage your MySQL databases through natural language.

Features

  • 🔍 Query Execution: Run SQL queries directly from Claude Desktop

  • 📊 Schema Inspection: Explore database structure, tables, and relationships

  • 🔄 Data Analysis: Analyze and visualize data patterns

  • 🛡️ Safe Operations: Built-in safeguards for database operations

  • 🚀 Easy Setup: Simple configuration with environment variables

Related MCP server: mysql-mcp

Prerequisites

  • Claude Desktop installed

  • Node.js (v16 or higher)

  • MySQL Server (v5.7 or higher)

  • install npm

  • Valid MySQL credentials with appropriate permissions

NPM Link

Visit npm package mcp-mysql-lens

Installation

1. Install the MCP Server

npm install -g mcp-mysql-lens

2. Configure Claude Desktop

Add this configuration to your Claude Desktop config file:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": [
        "mcp-mysql-lens"
      ],
      "env": {
        "MYSQL_HOST": "<YOUR_MYSQL_HOST>",
        "MYSQL_PORT": "<YOUR_MYSQL_PORT>",
        "MYSQL_USER": "<YOUR_MYSQL_USERNAME>",
        "MYSQL_PASSWORD": "<YOUR_MYSQL_PASSWORD>",
        "MYSQL_DATABASE": "<YOUR_MYSQL_DEFAULT_DB>"
      }
    }
  }
}

Configuration File Location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

3. Restart Claude Desktop

After saving the configuration, restart Claude Desktop for the changes to take effect.

Configuration Parameters

Parameter

Description

Default

Required

MYSQL_HOST

MySQL server hostname

-

Yes

MYSQL_PORT

MySQL server port

3306

Yes

MYSQL_USER

Database username

-

Yes

MYSQL_PASSWORD

Database password

-

Yes

MYSQL_DATABASE

Default database to connect to

-

Yes

Usage Examples

Once configured, you can interact with your MySQL database through Claude Desktop:

Query Data

"Show me all users from the users table"
"What are the top 10 products by sales?"
"Find all orders from the last 30 days"

Analyze Schema

"What tables are in my database?"
"Describe the structure of the customers table"
"Show me the relationships between tables"

Data Analysis

"Calculate the average order value by month"
"Find duplicate records in the products table"
"Show me user registration trends"

Security Best Practices

⚠️ Important Security Considerations:

  1. Use Read-Only Credentials: Create a dedicated MySQL user with read-only permissions for data analysis tasks

  2. Never Commit Credentials: Don't commit the claude_desktop_config.json file with actual credentials to version control

  3. Use Environment Variables: For production environments, consider using environment variable substitution

  4. Limit Database Access: Only grant access to specific databases that Claude needs to work with

  5. Use Strong Passwords: Ensure your MySQL password is strong and unique

  6. Enable SSL/TLS: For remote connections, always use SSL/TLS encryption

  7. Regular Auditing: Monitor database access logs regularly

Troubleshooting

Connection Issues

Problem: "Cannot connect to MySQL server"

  • Verify MySQL server is running: systemctl status mysql (Linux) or check Services (Windows)

  • Check host and port are correct

  • Ensure firewall allows connections on MySQL port (default 3306)

  • Verify credentials are correct

Problem: "Access denied for user"

  • Confirm username and password are correct

  • Check user has appropriate permissions: SHOW GRANTS FOR 'your_user'@'localhost';

  • Verify user can connect from the specified host

Configuration Issues

Problem: Claude Desktop doesn't show the MySQL server

  • Ensure the config file is in the correct location

  • Check JSON syntax is valid (use a JSON validator)

  • Restart Claude Desktop after making changes

  • Check Claude Desktop logs for errors

Performance Issues

Problem: Queries are slow

  • Add appropriate indexes to frequently queried columns

  • Optimize complex queries

  • Consider increasing MySQL connection timeout

  • Check database server resources (CPU, memory)

Limitations

  • Query Timeout: Long-running queries may timeout (default: 30 seconds)

  • Result Size: Large result sets may be truncated

  • Write Operations: Currently not supported

  • Concurrent Connections: Limited by MySQL server's max_connections setting

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

  1. Fork the repository

  2. Create your feature branch (git checkout -b feature/AmazingFeature)

  3. Commit your changes (git commit -m 'Add some AmazingFeature')

  4. Push to the branch (git push origin feature/AmazingFeature)

  5. Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

Available Tools

4 tools
describe_tableB

Show the schema for a specific table

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional, uses default if not specified)
tableYesTable name

TDQS

B3.4/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 full burden. It only states 'show the schema' without disclosing behavioral traits like read-only nature, required permissions, idempotency, or error handling. This is insufficient for a tool with zero annotation coverage.

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

Conciseness4/5

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

The description is a single sentence with no waste. However, it could include a brief note on sibling differentiation or usage context, but overall it is appropriately concise.

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

Completeness3/5

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

For a simple introspection tool with two parameters and no output schema, the description is adequate but lacks details on return format, error cases, or prerequisites (e.g., table must exist). It does not reference siblings, leaving the agent to infer 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%, so the baseline is 3. The description adds no additional meaning beyond the schema (e.g., clarifying what 'table' or 'database' refer to). It does not enhance 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?

"Show the schema for a specific table" uses a specific verb and resource, and clearly distinguishes from siblings like list_tables and execute_query.

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

Usage Guidelines3/5

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

The description implies usage for schema retrieval, but provides no explicit guidance on when to use this tool vs alternatives like list_tables (which only lists names) or execute_query (for custom queries). No when-not-to-use or alternative mentions.

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

execute_queryB

Execute a read-only SQL query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query (only SELECT, SHOW, DESCRIBE, and EXPLAIN statements are allowed)
databaseNoDatabase name (optional, uses default if not specified)

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries burden. It declares read-only, which is a key behavioral trait, but does not disclose result format, performance, or error handling. The parameter schema already specifies allowed statements, so description adds little beyond that.

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?

Single sentence of 5 words with no redundancy. Front-loaded and efficient.

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 no output schema, the description does not explain the return format of the executed query. It also omits potential side effects (though read-only) and error scenarios. For a query tool, this is somewhat acceptable but could be more complete.

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

Parameters3/5

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

Schema coverage is 100%, with clear descriptions for both parameters. The tool description adds no additional parameter information beyond what the schema provides. Baseline 3.

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 verb 'Execute' and the resource 'read-only SQL query', distinguishing it from sibling tools like describe_table which describe schema. The title is null but description suffices.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool over alternatives. It does not mention that for table metadata users should use describe_table or list_tables. The description is standalone without context.

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

list_databasesA

List all accessible databases on the MySQL server

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

The description indicates it returns 'all accessible databases', which is a basic behavioral trait. No annotations are provided, so the disclosure is minimal but adequate for a simple read operation. It does not mention permissions, system databases, or performance implications.

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

Conciseness5/5

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

A single sentence of 9 words front-loaded with the core purpose. No extraneous information, every word earns its place.

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

Completeness4/5

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

Given no parameters, no output schema, and no annotations, the description covers the essential purpose. It could be enhanced by clarifying 'accessible' (user privileges) or whether system databases are included, but it is sufficient for a basic list operation.

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

Parameters4/5

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

The tool has zero parameters, so the description need not add parameter details beyond what the schema provides. Per guidelines, baseline is 4 for 0 parameters.

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

Purpose5/5

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

The description clearly states the verb 'List' and resource 'databases', specifying scope 'all accessible' and context 'MySQL server'. It effectively differentiates from sibling tools like list_tables and describe_table.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. No mention of prerequisites, when-not, or references to sibling tools.

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

list_tablesC

List all tables in a specified database

ParametersJSON Schema
NameRequiredDescriptionDefault
databaseNoDatabase name (optional, uses default if not specified)

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 disclosing behavior. It only states the basic function but does not elaborate on side effects, read-only nature, error handling (e.g., what if the database doesn't exist), or the meaning of 'default' database. This lack of detail limits transparency.

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

Conciseness5/5

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

The description is a single sentence with no redundant information. It is concise and to the point, using no filler words.

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

Completeness3/5

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

Given the tool's simplicity (one optional parameter, no output schema), the description is minimally adequate. However, it misses details like what 'default' database refers to or whether the tool requires any privileges. It does not fully prepare the agent for all usage scenarios.

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

Parameters2/5

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

Schema description coverage is 100% for the single parameter 'database', which already explains its optionality and default behavior. The description adds no additional semantic value beyond restating 'in a specified database', which is already implicit from the schema.

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 'List all tables in a specified database' clearly identifies the action (list) and resource (tables), distinguishing it from sibling tools like list_databases (lists databases) and describe_table (describes a single table). However, the word 'specified' implies the database parameter is required, while the schema marks it as optional, causing minor ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as describe_table or execute_query. There is no mention of prerequisites, limitations, or explicit when-to-use/when-not-to-use instructions, leaving the agent to infer appropriate usage.

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.

  1. 4 tool updates
    • First observeddescribe_table
    • First observedexecute_query
    • First observedlist_databases
    • First observedlist_tables
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: describe_table shows schema, execute_query runs SQL queries, list_databases lists databases, and list_tables lists tables. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (describe_table, execute_query, list_databases, list_tables) with clear, descriptive verbs and nouns that match their functions.

Tool Count4/5

With 4 tools, the count is reasonable for a MySQL server interface, though it feels slightly thin as it lacks write operations (e.g., insert, update, delete) which are common in database contexts. However, the tools cover essential read and metadata functions well.

Completeness3/5

The tool surface covers read operations and metadata well (list databases/tables, describe schema, execute queries), but there are notable gaps: no write operations (insert, update, delete), no transaction management, and no user or permission management tools, which limits full database lifecycle coverage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers