Which integrations are available for this server?

Provides tools to explore MariaDB database schemas, including tables, columns, foreign keys, indexes, and relationships, supporting MariaDB 10.2+. Provides tools to explore MySQL database schemas, including tables, columns, foreign keys, indexes, and relationships, via MCP.

How do I use mcp-server-mysql-schema?

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., "@mcp-server-mysql-schema show columns of users table in myapp" 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.

mcp-server-mysql-schema

by rendi-febrian

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

mcp-server-mysql-schema

npm License Node GitHub stars

MySQL Schema MCP Server — explore tables, columns, foreign keys, indexes, and relationships through the Model Context Protocol. Works with opencode, Claude Desktop, Cursor, and any MCP-compatible AI client.

No more writing SHOW TABLES and DESCRIBE manually. Ask your AI assistant "what tables are in this database?", "show me the foreign keys of the orders table", or "find all columns named 'status'" — and get structured JSON responses.

Quick Start

# Install
npx mcp-server-mysql-schema

# Or clone
git clone git@github.com:rendi-febrian/mcp-server-mysql-schema.git
cd mcp-server-mysql-schema
npm install && npm run build

opencode Configuration

{
  "mcp": {
    "mysql-schema": {
      "type": "local",
      "command": ["node", "/path/to/mcp-server-mysql-schema/dist/index.js"],
      "environment": {
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "root",
        "MYSQL_PASS": "your-password"
      },
      "enabled": true
    }
  }
}

Claude Desktop / Cursor / Other MCP Clients

{
  "mcpServers": {
    "mysql-schema": {
      "command": "node",
      "args": ["/path/to/mcp-server-mysql-schema/dist/index.js"],
      "env": {
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "root",
        "MYSQL_PASS": "your-password"
      }
    }
  }
}

Related MCP server: easy-mysql-mcp

Features

Tools

Tool	Description	Example
`schema_databases`	List all non-system databases with charset	`schema_databases()`
`schema_tables`	All tables — engine, row count, auto-increment, comments	`schema_tables(database: "myapp")`
`schema_views`	All views in a database	`schema_views(database: "myapp")`
`schema_table_detail`	Columns: type, nullable, default, key, extra, comment	`schema_table_detail(database: "myapp", table: "users")`
`schema_foreign_keys`	FK relationships — all DB, per-table, incoming/outgoing	`schema_foreign_keys(database: "myapp", table: "orders")`
`schema_indexes`	Indexes: name, columns, seq, unique, type, comment	`schema_indexes(database: "myapp", table: "users")`
`schema_relationships`	Full PK/FK map across all tables	`schema_relationships(database: "myapp")`
`schema_search`	Search table and column names by keyword	`schema_search(database: "myapp", keyword: "user")`

Resources

URI	Content
`schema://{db}/tables`	All tables in the database
`schema://{db}/relationships`	Full relationship map
`schema://{db}/{table}/columns`	Column details
`schema://{db}/{table}/indexes`	Index details
`schema://{db}/{table}/foreign-keys`	Foreign key details

Security

100% read-only. Every query targets information_schema only. No SELECT on user tables. No INSERT, UPDATE, DELETE, or DDL. The server cannot modify any data.

Why Not Just Use MySQL MCP?

	MySQL MCP	Schema MCP (this)
Purpose	Run arbitrary SQL	Introspect database structure
Query target	Any table / any query	`information_schema` only
Write access	Optional (configurable)	Never
Structured tools	Single `mysql_query` tool	8 focused tools
Resources	Table-level	Table + FK + relationship maps
Best for	Data CRUD, ad-hoc queries	Schema discovery, ERD, migrations

Requirements

Node.js >= 18
MySQL 5.7+ or MariaDB 10.2+
MySQL user with SELECT on information_schema (default)

Environment Variables

Variable	Required	Default	Description
`MYSQL_HOST`	No	`127.0.0.1`	MySQL host
`MYSQL_PORT`	No	`3306`	MySQL port
`MYSQL_USER`	No	`root`	MySQL user
`MYSQL_PASS`	No	`""`	MySQL password
`MYSQL_DEFAULT_DB`	No	—	Default database for resource URIs

Architecture

src/
├── index.ts              # MCP server entry point (raw Server)
├── db.ts                 # MySQL connection pool
├── schema.ts             # information_schema queries
├── tools/
│   ├── tables.ts         # schema_databases, schema_tables, schema_views
│   ├── detail.ts         # schema_table_detail
│   ├── foreignKeys.ts    # schema_foreign_keys
│   ├── indexes.ts        # schema_indexes
│   ├── relationships.ts  # schema_relationships
│   └── search.ts         # schema_search
└── resources/
    └── index.ts          # schema:// URIs

No ORM, no migrations, no configuration files — just raw information_schema queries over mysql2.

Contributing

See CONTRIBUTING.md.

License

MIT

Available Tools

8 tools

schema_databasesA

List all non-system MySQL databases with charset and collation

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description bears full responsibility. It discloses that the tool lists databases with charset and collation, but does not mention features like read-only nature, response size, permissions, or error conditions. Adequate for a simple listing but lacks depth.

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

Conciseness5/5

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

The description is a single, clear sentence with no unnecessary words. It is front-loaded with the core action and resource, immediately conveying the tool's purpose.

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?

Despite lacking an output schema, the description covers the key return attributes (charset and collation). For a straightforward listing tool with zero parameters, this is sufficient context for an agent to understand what information will be retrieved.

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

Parameters4/5

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

The input schema has no parameters, so schema coverage is trivially 100%. The description adds meaning by specifying exactly what the tool outputs (charset and collation), which the empty schema cannot convey.

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

Purpose5/5

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

The description uses specific verb 'list' and resource 'databases', scoped to 'non-system MySQL' and specifies included attributes 'charset and collation'. It clearly distinguishes from siblings like schema_tables and schema_views which operate on different objects.

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

Usage Guidelines3/5

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

The description implies use for obtaining database-level metadata, but it does not explicitly state when to use this tool versus alternatives like schema_tables for tables or schema_views for views. No exclusion criteria or when-not-to-use guidance is provided.

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

schema_foreign_keysB

List foreign key relationships for a database or specific table (incoming + outgoing)

ParametersJSON Schema

Name	Required	Description
`table`	No	Optional: filter by table name
`database`	Yes	Database name
`direction`	No	When table is set: 'all' (default), 'incoming', or 'outgoing'

TDQS

B3.4/5.0

Behavior2/5

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

Annotations are absent, so the description must fully disclose behavior. It only mentions 'incoming + outgoing' directionality, but lacks details on whether this is a read-only operation, required permissions, rate limits, or any side effects. The tool is likely read-only, but that's not stated.

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

Conciseness5/5

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

The description is a single 12-word sentence that is front-loaded with the verb and resource, making it instantly understandable. There is no redundant information.

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?

With no output schema and no annotations, the description should provide more context, such as the return format, pagination behavior, or the effect of omitting the 'table' parameter. Currently, it lacks completeness for a tool with three parameters and no structured output description.

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% (all 3 parameters documented in the schema). The description adds 'incoming + outgoing', which echoes the enum values of the 'direction' parameter, but does not provide additional meaning or usage context 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 uses a specific verb ('List') and resource ('foreign key relationships') and clarifies scope ('database or specific table') and directionality ('incoming + outgoing'), clearly distinguishing it from siblings like schema_tables or schema_relationships.

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?

No explicit when-to-use or when-not-to-use guidance is provided, but the purpose implies its use for exploring foreign key constraints. The sibling tools list suggests alternative schema introspection tools, but no direct comparison is made.

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

schema_indexesA

List all indexes for a table with columns, uniqueness, and type

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table name
`database`	Yes	Database name

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description fully carries the burden. It accurately describes the output (columns, uniqueness, type) for a read operation. However, it does not mention any error cases or performance considerations, which would improve 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 concise sentence that immediately communicates the tool's purpose. There is no redundancy or unnecessary elaboration.

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

Completeness4/5

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

For a simple list tool with no output schema, the description adequately explains what the output contains (columns, uniqueness, type). It is complete enough for an agent to understand the tool's functionality, though specifying the output format would add clarity.

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 parameter descriptions for 'table' and 'database'. The tool description does not add any new semantic information beyond what is already in the schema, 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 it lists all indexes for a table, specifying what details are included (columns, uniqueness, type). This clearly distinguishes it from sibling tools like schema_tables or schema_foreign_keys.

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 the tool should be used when index information is needed, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., schema_table_detail for broader table info). No exclusion criteria or prerequisites are mentioned.

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

schema_relationshipsB

Full relationship map across all tables in a database: primary keys, foreign keys, and references

ParametersJSON Schema

Name	Required	Description	Default
`database`	Yes	Database 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 must disclose behavior. It only states what information is returned but omits details about output format, performance, authentication, or side effects. This is a significant gap for a tool with no output schema.

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, clear sentence with no unnecessary words. The phrase 'Full relationship map' immediately conveys the core purpose.

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?

The description is too sparse for a tool lacking an output schema and annotations. An agent needs to know what the relationship map looks like (list, graph, etc.), how to parse it, and any limitations. This is incomplete.

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?

With 100% schema coverage and one parameter clearly described as 'Database name', the description adds no additional semantics beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool returns a full relationship map across all tables, covering primary keys, foreign keys, and references. It distinctly separates from sibling tools like schema_foreign_keys, which likely returns individual FK details.

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 when to use (to get a full relationship map), but does not explicitly contrast with sibling tools like schema_foreign_keys or schema_tables. No usage restrictions or alternatives are mentioned.

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

schema_searchB

Search across table and column names in a database

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes	Search keyword
`database`	Yes	Database name

TDQS

B3.4/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 implies a read-only search operation, which is appropriate, but it does not disclose any details about the output format, pagination, rate limits, or authentication requirements. The description is minimal but not misleading.

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 of 8 words, extremely concise. It front-loads the action ('Search') and immediately specifies the scope. There is no wasted words or irrelevant information.

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

Completeness2/5

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

Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It fails to describe what the tool returns (e.g., list of matching table/column names, any additional metadata) and does not cover edge cases like no results or search syntax.

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% coverage with descriptions for both parameters (keyword and database). The tool description does not add any additional meaning beyond what the schema already provides. The baseline score of 3 is appropriate since the schema itself is sufficient.

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

Purpose5/5

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

The description clearly states the tool's action (search) and the specific resource scope (across table and column names in a database). This is a specific verb and resource, and it distinguishes the tool from siblings like schema_tables (which lists tables) or schema_views (which lists views) by indicating it searches both.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer it over sibling tools like schema_tables or schema_views, nor does it specify any prerequisites or exclusions.

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

schema_table_detailB

Show columns, types, defaults, nullable, keys, and comments for a table

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Table name
`database`	Yes	Database name

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose any behavioral traits beyond the obvious read operation. No mention of permissions, side effects, or other 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?

Single sentence, front-loaded with key information. Efficient but could be slightly more structured.

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 simplicity (2 parameters, no output schema), the description adequately explains what the tool returns. However, it could be more comprehensive without being verbose.

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 baseline is 3. The description does not add extra meaning to parameters 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 clearly states the tool shows columns, types, defaults, nullable, keys, and comments for a table, which is specific and distinguishes from siblings focusing on databases, foreign keys, indexes, etc.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives or when not to use it. The description is purely functional without context.

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

schema_tablesA

List all tables in a database with engine, row count, size estimates, and comments

ParametersJSON Schema

Name	Required	Description	Default
`database`	Yes	Database name

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided. The description only states what is returned, not behavioral traits such as read-only nature, performance implications, or lack of side effects. For a listing tool, these are expected but undocumented.

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

Conciseness5/5

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

The description is a single, clear sentence that immediately states the tool's purpose and the information provided, with no extraneous words.

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

Completeness4/5

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

Given the simplicity (one parameter, no output schema), the description is adequate. It could mention that an empty database returns an empty list or how results are ordered, but it covers the essential output.

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 the 'database' parameter description in the schema. The description adds no additional meaning beyond the schema, so 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 clearly states the action ('List all tables') and specifies the returned information (engine, row count, size estimates, comments). It distinguishes from siblings like schema_table_detail (single table) and schema_foreign_keys (specific relationships).

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 getting an overview of database tables but does not explicitly state when to use this tool versus alternatives like schema_table_detail for details on a single table or schema_search for searching.

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

schema_viewsB

List all views in a database

ParametersJSON Schema

Name	Required	Description	Default
`database`	Yes	Database name

TDQS

B3.4/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It does not mention whether the operation is read-only, idempotent, or any side effects. Minimal behavioral disclosure.

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, front-loaded sentence that is perfectly concise and contains no extraneous information. Every word adds value.

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

Completeness4/5

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

For a simple listing tool with one parameter and no output schema, the description is mostly adequate. However, it could hint at the result format or that it's read-only.

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 description adds no extra meaning beyond the input schema, which already documents the single parameter ('Database name'). With 100% schema coverage, baseline is 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 action ('List'), the target ('views'), and the scope ('in a database'). It distinguishes from sibling tools like schema_tables (which list tables) and schema_indexes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like schema_tables or schema_search. It simply states the function without context.

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.

8 tool updatesv1.0.0Jul 9, 2026
- First observedschema_databases
- First observedschema_foreign_keys
- First observedschema_indexes
- First observedschema_relationships
- First observedschema_search
- First observedschema_table_detail
- First observedschema_tables
- First observedschema_views

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: databases, foreign keys, indexes, relationships, search, table details, tables, and views. No two tools overlap in function.

Naming Consistency5/5

All tool names follow a consistent 'schema_noun' pattern using snake_case, making it easy to predict what each tool does.

Tool Count5/5

With 8 tools, the server is well-scoped for MySQL schema exploration. Each tool covers a distinct aspect without excessive granularity.

Completeness4/5

The set covers essential schema exploration: databases, tables, columns, indexes, foreign keys, relationships, views, and search. Missing stored procedures or events, but these are not core to schema inspection.

Maintenance

ActivitySlowing

ResponsivenessSyncing

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

QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
wgong-sqlite-mcp-server
ai.smithery
Explore, query, and inspect SQLite databases with ease. List tables, preview results, and view det…
Databases Developer Tools
21
db-planner
io.dbplanner
Read and edit DB Planner database schemas, diagrams and board layouts as an AI agent.
1
AI2SQL
io.ai2sql
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
1

Related MCP Servers

MCP MySQL Server
Databases Developer Tools
Iceeeeec
A
license
Not graded
quality
D
maintenance
Enables AI assistants to safely query MySQL databases with read-only access by default, supporting table listing, structure inspection, and SQL queries with optional write operation control.
Updated 10 months ago (2025-11-06 03:02 UTC)
18
MIT
easy-mysql-mcp
Databases Developer Tools
chenkumi
A
license
A
quality
C
maintenance
Enables AI assistants to inspect and query a MySQL database through safe, structured tools, including schema discovery and read-only queries.
Updated 2 months ago (2026-07-17 06:57 UTC)
9
89
MIT
Simple MCP MySQL Server
Databases Developer Tools
alexcc4
F
license
Not graded
quality
D
maintenance
Enables AI assistants to securely interact with MySQL databases, including listing tables, viewing schemas, and executing read-only SQL queries through natural language.
Updated a year ago (2025-03-09 15:57 UTC)
6
-
MySQL MCP Server
Databases Developer Tools
eltonf
A
license
Not graded
quality
D
maintenance
Enables schema introspection and safe read-only queries on MySQL databases, supporting table/column discovery, relationship exploration, and controlled SELECT queries.
Updated 4 months ago (2026-05-11 20:29 UTC)
25
MIT

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/rendi-febrian/mcp-server-mysql-schema'

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