Skip to main content
Glama

MCP Server Local WP

šŸŽÆ What if your AI assistant could actually SEE your WordPress database?

A Model Context Protocol (MCP) server that gives AI assistants like Claude and Cursor direct, read-only access to your Local by Flywheel WordPress database. No more guessing table structures. No more writing SQL queries blind. Your AI can now understand your actual data.

šŸ¤” What's an MCP Server?

Think of MCP (Model Context Protocol) as a secure bridge between AI assistants and your development tools. Instead of copying and pasting database schemas or query results, MCP servers let AI assistants directly interact with your tools while you maintain complete control.

Without MCP: "Hey AI, I think there's a table called wp_something with a column that might be named user_meta... can you write a query?"
With MCP: "Hey AI, check what's in my database and write the exact query I need."

Related MCP server: Database Query MCP Server

šŸ’” The WordPress Developer's Dilemma

Picture this: You're debugging a LearnDash integration issue. Quiz results aren't syncing properly. You fire up Cursor to help diagnose the problem, but without database access, even the most advanced AI is just making educated guesses about your table structures.

The Real-World Impact

Here's an actual support ticket we were working on. The task was simple: fetch quiz activity data from LearnDash tables.

āŒ Before MCP Server (AI Flying Blind):

Very Good Plugins  Cursor+Diagnose LearnDash quiz field syncing issue — wp-fusion (Workspace)  2025-09-09 at 12 34 38

The AI tried its best, suggesting this query:

$quiz_activities = $wpdb->get_results( 
  $wpdb->prepare( 
    'SELECT post_id, activity_meta FROM ' . esc_sql( LDLMS_DB::get_table_name( 'user_activity' ) ) . ' 
     WHERE user_id=%d AND activity_type=%s AND activity_status=1 AND activity_completed IS NOT NULL',
    $user_id, 
    'quiz' 
  ), 
  ARRAY_A 
);

Problem? The activity_meta column doesn't exist! LearnDash stores metadata in a completely separate table with a different structure. Without database access, the AI made reasonable but incorrect assumptions. You'd spend the next 20 minutes manually correcting table names, discovering relationships, and rewriting the query.

āœ… After MCP Server (AI With X-Ray Vision):

Very Good Plugins  Cursor+Diagnose LearnDash quiz field syncing issue — wp-fusion (Workspace)  2025-09-09 at 12 54 07

With database access, the AI immediately saw the actual table structure and wrote:

$quiz_activities = $wpdb->get_results(
  $wpdb->prepare(
    'SELECT ua.post_id, ua.activity_id, uam.activity_meta_key, uam.activity_meta_value 
     FROM ' . esc_sql( LDLMS_DB::get_table_name( 'user_activity' ) ) . ' ua
     LEFT JOIN ' . esc_sql( LDLMS_DB::get_table_name( 'user_activity_meta' ) ) . ' uam 
     ON ua.activity_id = uam.activity_id 
     WHERE ua.user_id=%d AND ua.activity_type=%s AND ua.activity_completed IS NOT NULL
     AND uam.activity_meta_key IN (%s, %s, %s)',
    $user_id,
    'quiz',
    'percentage',
    'points',
    'total_points'
  ),
  ARRAY_A
);

The difference? The AI could see that metadata lives in a separate user_activity_meta table, understood the relationship through activity_id, and knew exactly which meta keys were available. First try. Zero guesswork. Problem solved.

šŸš€ Why This Changes Everything

When your AI assistant can read your database:

  • No more schema guessing - It sees your actual tables and columns

  • Accurate JOIN operations - It understands table relationships

  • Real data validation - It can verify that data exists before suggesting queries

  • Plugin-aware development - It adapts to any plugin's custom tables (WooCommerce, LearnDash, etc.)

  • Instant debugging - "Show me all users who haven't completed quiz ID 42" becomes a 5-second task

šŸ”§ The Local by Flywheel Challenge We Solved

When using the original mcp-server-mysql with Local by Flywheel, developers face several challenges:

  1. Dynamic Paths: Local by Flywheel generates unique identifiers for each site (like lx97vbzE7) that change when sites are restarted

  2. Socket vs Port Confusion: Local uses both Unix sockets and TCP ports, but the configuration can be tricky

  3. Hardcoded Configurations: Most setups require manual path updates every time Local restarts

Our Solution

This MCP server automatically detects your active Local by Flywheel MySQL instance by:

  1. Process Detection: Scans running processes to find active mysqld instances

  2. Config Parsing: Extracts MySQL configuration from the active Local site

  3. Dynamic Connection: Connects using the correct socket path or port automatically

  4. Fallback Support: Falls back to environment variables for non-Local setups

Multi-Site Support

When you have multiple Local sites, the server uses priority-based site selection to ensure you're always connected to the right database:

Selection Priority

  1. SITE_ID env var - Direct site ID (highest priority)

  2. SITE_NAME env var - Human-readable site name lookup

  3. Working directory detection - If your cwd is within a Local site path, that site is used

  4. Process detection - First running Local mysqld found

  5. Filesystem fallback - Most recently modified socket

Explicit Site Selection

Specify which site to connect to in your MCP config:

{
  "mcpServers": {
    "wordpress-dev": {
      "command": "npx",
      "args": ["-y", "@verygoodplugins/mcp-local-wp@latest"],
      "env": {
        "SITE_NAME": "dev"
      }
    }
  }
}

Or use the site ID directly:

{
  "env": {
    "SITE_ID": "lx97vbzE7"
  }
}

Working Directory Detection

When using Claude Code or Cursor, the server automatically detects which site you're working in based on your current directory. If you're editing files in /Users/.../Local Sites/dev/app/public/wp-content/plugins/my-plugin/, the server connects to the "dev" site's database automatically.

Verifying Your Connection

Use the mysql_current_site tool to see which site you're connected to:

{
  "siteName": "dev",
  "siteId": "lx97vbzE7",
  "sitePath": "/Users/.../Local Sites/dev",
  "domain": "dev.local",
  "selectionMethod": "cwd_detection"
}

Use mysql_list_sites to see all available sites and their status.

Tools Available

mysql_query

Execute read-only SQL against your Local WordPress database.

Input fields:

  • sql (string): Single read-only statement (SELECT/SHOW/DESCRIBE/EXPLAIN)

  • params (string[]): Optional parameter values for ? placeholders

Example Usage:

-- With parameters
SELECT * FROM wp_posts WHERE post_status = ? ORDER BY post_date DESC LIMIT ?;
-- params: ["publish", "5"]

-- Direct queries
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%theme%';
SHOW TABLES;
DESCRIBE wp_users;

mysql_schema

Inspect database schema using INFORMATION_SCHEMA.

  • No args: lists tables with basic stats

  • With table: returns columns and indexes for that table

Examples:

// List all tables
{
  "tool": "mysql_schema",
  "args": {}
}

// Inspect a specific table
{
  "tool": "mysql_schema",
  "args": { "table": "wp_posts" }
}

mysql_current_site

Get information about the currently connected Local WordPress site.

Returns the site name, ID, path, domain, socket path, and how the site was selected (env var, cwd detection, or auto-detection).

{
  "tool": "mysql_current_site",
  "args": {}
}
// Returns:
// {
//   "siteName": "dev",
//   "siteId": "lx97vbzE7",
//   "sitePath": "/Users/.../Local Sites/dev",
//   "domain": "dev.local",
//   "selectionMethod": "cwd_detection",
//   "socketPath": "/Users/.../Local/run/lx97vbzE7/mysql/mysqld.sock"
// }

mysql_list_sites

List all available Local WordPress sites and their running status.

{
  "tool": "mysql_list_sites",
  "args": {}
}
// Returns:
// {
//   "sites": [
//     { "id": "lx97vbzE7", "name": "dev", "domain": "dev.local", "running": true },
//     { "id": "WP7lolWDi", "name": "staging", "domain": "staging.local", "running": false }
//   ],
//   "currentSiteId": "lx97vbzE7"
// }

Installation

Prerequisites

  • Local by Flywheel installed and running

  • An active Local site running

  • Node.js 18+ (for local development only)

The easiest way to get started - no installation required:

Cursor IDE Configuration

Add this to your Cursor MCP configuration file (.cursor/mcp.json):

{
  "mcpServers": {
    "mcp-local-wp": {
      "command": "npx",
      "args": [
        "-y",
        "@verygoodplugins/mcp-local-wp@latest"
      ]
    }
  }
}

Claude Desktop Configuration

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\\Claude\\claude_desktop_config.json

{
  "mcpServers": {
    "mcp-local-wp": {
      "command": "npx",
      "args": [
        "-y",
        "@verygoodplugins/mcp-local-wp@latest"
      ]
    }
  }
}

Advanced Setup (Local Development)

For customization or local development:

Install from Source

git clone https://github.com/verygoodplugins/mcp-local-wp.git
cd mcp-local-wp
npm install
npm run build

Local Configuration

{
  "mcpServers": {
    "mcp-local-wp": {
      "command": "node",
      "args": [
        "/full/path/to/mcp-local-wp/dist/index.js"
      ]
    }
  }
}

Custom Environment Variables

For non-Local setups or custom configurations:

{
  "mcpServers": {
    "mcp-local-wp": {
      "command": "npx",
      "args": [
        "-y",
        "@verygoodplugins/mcp-local-wp@latest"
      ],
      "env": {
        "MYSQL_DB": "local",
        "MYSQL_HOST": "localhost",
        "MYSQL_PORT": "3306",
        "MYSQL_USER": "root",
        "MYSQL_PASS": "root"
      }
    }
  }
}

Site Selection Variables

Variable

Description

Example

SITE_ID

Explicit site ID (highest priority)

lx97vbzE7

SITE_NAME

Site name for lookup

dev

LOCAL_SITES_JSON

Override path to Local's sites.json

/custom/path/sites.json

LOCAL_RUN_DIR

Override Local's run directory

/custom/run/path

How It Works with Local by Flywheel

This MCP server was created because connecting to Local by Flywheel MySQL was "kind of difficult to get working" with existing MCP servers. Here's the story of what we solved:

The Original Problem

When we first tried to use mcp-server-mysql with Local by Flywheel, we encountered several issues:

  1. Dynamic Socket Paths: Local generates paths like /Users/.../Local/run/lx97vbzE7/mysql/mysqld.sock where lx97vbzE7 changes each time you restart Local

  2. Configuration Complexity: The original server required hardcoded paths that would break every time Local restarted

  3. Host/Port Confusion: Local's MySQL configuration can be tricky with both socket and TCP connections available

Our Solution Process

We solved this step by step:

1. Process-Based Detection

Instead of guessing paths, we scan for the actual running MySQL process:

ps aux | grep mysqld | grep -v grep

This finds the active MySQL instance and extracts its configuration file path.

2. Dynamic Path Resolution

// From the process args: --defaults-file=/Users/.../Local/run/lx97vbzE7/conf/mysql/my.cnf
// We extract the site directory and build the socket path
const configPath = extractFromProcess();
const siteDir = path.dirname(path.dirname(path.dirname(configPath)));
const socketPath = path.join(siteDir, 'mysql/mysqld.sock');

3. Automatic Configuration

The server automatically configures itself with:

  • Correct socket path for the active Local site

  • Proper database name (local)

  • Default credentials (root/root)

  • Fallback to environment variables if needed

Why This Approach Works

āœ… Restart Resilient: Works every time you restart Local by Flywheel
āœ… Site Switching: Automatically adapts if you switch between Local sites
āœ… Zero Maintenance: No need to manually update paths ever again
āœ… Error Handling: Provides clear error messages if MySQL isn't running

Local Directory Structure We Handle

~/Library/Application Support/Local/run/
ā”œā”€ā”€ lx97vbzE7/                    # Dynamic site ID (changes on restart)
│   ā”œā”€ā”€ conf/mysql/my.cnf        # We read this for port info
│   └── mysql/mysqld.sock        # We connect via this socket
└── WP7lolWDi/                   # Another site (if multiple running)
    ā”œā”€ā”€ conf/mysql/my.cnf
    └── mysql/mysqld.sock

The server intelligently finds the active site and connects to the right MySQL instance.

Usage Examples

Once connected, you can use the mysql_query tool to execute any SQL query against your Local WordPress database:

Getting Recent Posts

SELECT ID, post_title, post_date, post_status 
FROM wp_posts 
WHERE post_type = 'post' AND post_status = 'publish' 
ORDER BY post_date DESC 
LIMIT 5;

Exploring Database Structure

-- See all tables
SHOW TABLES;

-- Examine a table structure
DESCRIBE wp_posts;

-- Get table info
SHOW TABLE STATUS LIKE 'wp_%';

WordPress-Specific Queries

-- Get site options
SELECT option_name, option_value 
FROM wp_options 
WHERE option_name IN ('blogname', 'blogdescription', 'admin_email');

-- Find active plugins
SELECT option_value 
FROM wp_options 
WHERE option_name = 'active_plugins';

-- Get user information
SELECT user_login, user_email, display_name 
FROM wp_users 
LIMIT 10;

-- Post meta data
SELECT p.post_title, pm.meta_key, pm.meta_value
FROM wp_posts p
JOIN wp_postmeta pm ON p.ID = pm.post_id
WHERE p.post_type = 'post' AND pm.meta_key = '_edit_last';

Development Setup

Running from Source

  1. Start a Local site: Make sure you have an active Local by Flywheel site running

  2. Clone and build:

    git clone https://github.com/verygoodplugins/mcp-local-wp.git
    cd mcp-local-wp
    npm install
    npm run build
  3. Test the connection:

    node dist/index.js

Development Mode

npm run dev

This runs the server with TypeScript watching for changes.

Linting & Formatting

  • Lint: npm run lint

  • Fix lint: npm run lint:fix

  • Format: npm run format

  • Check formatting: npm run format:check

Standards are unified across MCP servers via ESLint + Prettier.

Troubleshooting

Common Issues

  1. "No active MySQL process found"

    • Ensure Local by Flywheel is running

    • Make sure at least one site is started in Local

    • Check that the site's database is running

  2. "MySQL socket not found"

    • Verify the Local site is fully started

    • Try stopping and restarting the site in Local

    • Check Local's logs for MySQL startup issues

  3. Connection refused

    • Ensure the Local site's MySQL service is running

    • Check if another process is using the MySQL port

    • Try restarting Local by Flywheel

  4. Permission denied

    • Make sure the MySQL socket file has correct permissions

    • Check if your user has access to Local's directories

Manual Configuration

If auto-detection fails, you can manually configure the connection:

export MYSQL_SOCKET_PATH="/path/to/your/local/site/mysql/mysqld.sock"
export MYSQL_DB="local"
export MYSQL_USER="root"
export MYSQL_PASS="root"

Debugging

Enable debug logging by setting DEBUG:

DEBUG=mcp-local-wp mcp-local-wp

Security

  • Read-only operations: Only SELECT/SHOW/DESCRIBE/EXPLAIN are allowed

  • Single statement: Multiple statements in one call are blocked

  • Local development: Designed for local environments (Local by Flywheel)

  • No external connections: Prioritizes Unix socket connections when available

Contributing

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

Development Guidelines

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature/your-feature-name

  3. Make your changes and add tests

  4. Ensure TypeScript compiles: npm run build

  5. Submit a pull request

License

GPL-3.0-or-later - see the LICENSE file for details. As a WordPress-focused tool, we embrace the copyleft philosophy to ensure this remains free and open for the community.

Support

  • GitHub Issues: Report bugs or request features

  • Documentation: This README and inline code documentation

  • Community: Join the Model Context Protocol community discussions


Built with 🧔 by Jack Arturo at Very Good Plugins · Made with love for the open-source community

Available Tools

4 tools
mysql_current_siteA

Get information about the currently connected Local WordPress site, including how it was selected

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/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 carry behavioral transparency. It does not disclose read-only nature, side effects, or auth requirements beyond basic purpose, leaving gaps for a tool that likely performs a safe query.

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, front-loaded sentence with no extraneous words, effectively conveying the tool's purpose.

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 has no parameters, no output schema, and a simple purpose, the description fully explains what it does and what it returns (information and selection method), making it complete.

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 0 parameters and 100% coverage, so the baseline is 4. The description does not need to add parameter semantics as none exist.

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 retrieves information about the currently connected Local WordPress site, including selection method, which distinguishes it from sibling tools like mysql_list_sites, mysql_query, and mysql_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?

The description implies usage context (when needing current site info) but does not explicitly exclude alternatives or provide when-not scenarios; context is clear enough given sibling differentiation.

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

mysql_list_sitesA

List all available Local WordPress sites and their running status

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior4/5

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

No annotations exist, so description fully carries the burden. It accurately describes a read-only list operation, which is transparent for this simple action. No hidden behaviors or side effects.

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, no wasted words. Efficiently communicates purpose and 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?

Fully describes what the tool returns (list of sites with running status) without needing output schema. Complete for a simple 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?

Input schema has 0 parameters, so baseline is 4. The description does not need to add parameter info, and it doesn't repeat unnecessary details.

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 lists all available Local WordPress sites and their running status. The verb 'List' and the resource are specific, and it implicitly distinguishes from siblings like mysql_current_site (single site) or mysql_query (queries).

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 vs alternatives. The description implies listing all sites, but no when-not or alternative tool mentions.

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

mysql_queryA

Execute a read-only SQL query against the Local WordPress database

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesSingle read-only SQL statement (SELECT/SHOW/DESCRIBE/EXPLAIN).
paramsNoOptional parameter values for placeholders (?).

TDQS

A3.9/5.0
Behavior3/5

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

Declares 'read-only', implying non-destructive behavior. Without annotations, description carries full burden; lacks details on error behavior, return format, or connection specifics.

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 front-loads the action and scope, no wasted 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?

Lacks output shape description (since no output schema), missing error behavior details. Adequate for simple query but could be more complete for an agent.

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 coverage is 100% with descriptions. Description adds value by restricting sql to allowed commands (SELECT/SHOW/DESCRIBE/EXPLAIN), going beyond schema's generic 'Single read-only SQL statement'.

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?

Clear action verb 'Execute', specific object 'read-only SQL query', and context 'Local WordPress database'. Distinguishes from siblings which focus on current site, listing sites, and schema.

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?

Explicitly lists allowed SQL commands (SELECT/SHOW/DESCRIBE/EXPLAIN) indicating read-only usage. However, no guidance on when to use this tool versus siblings like mysql_schema for schema exploration.

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

mysql_schemaA

Inspect database schema. Without args: lists tables. With table: shows columns and indexes.

ParametersJSON Schema
NameRequiredDescriptionDefault
tableNoOptional table name to inspect

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description must cover behavior. It describes the two modes but lacks details on side effects, authentication, or output format. For a read-heavy tool, this is adequate but not thorough.

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?

Two tightly written sentences, no superfluous words. Purpose is front-loaded. Ideal conciseness for a simple tool.

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 (1 param, no output schema), the description covers the essential functionality. Minor omission: not specifying output format, but it's not critical for an inspect 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 coverage is 100% for the single parameter. The description adds concrete meaning by explaining the effect of providing the table parameter versus omitting it, going beyond the schema's description.

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?

Clearly states the tool inspects database schema, with specific behavior: without args lists tables, with table shows columns and indexes. This distinguishes it from sibling tools like mysql_query or mysql_list_sites.

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?

Provides clear usage guidance for both modes (with/without args) but does not explicitly mention when not to use or alternatives. The context is clear enough for basic 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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.1.0
    • Addedmysql_current_site
    • Addedmysql_list_sites
  2. 12 tool updatesv1.0.0
    • Addedmysql_query
    • Addedmysql_schema
    • Removedwp_execute_query
    • Removedwp_get_database_info
    • Removedwp_get_options
    • Removedwp_get_plugins
    • Removedwp_get_post
    • Removedwp_get_post_meta
    • Removedwp_get_posts
    • Removedwp_get_theme_info
    • Removedwp_get_user
    • Removedwp_get_users
  3. 10 tool updates
    • First observedwp_execute_query
    • First observedwp_get_database_info
    • First observedwp_get_options
    • First observedwp_get_plugins
    • First observedwp_get_post
    • First observedwp_get_post_meta
    • First observedwp_get_posts
    • First observedwp_get_theme_info
    • First observedwp_get_user
    • First observedwp_get_users

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct operation: listing sites, getting current site info, running queries, and inspecting schema. No overlap in purpose.

Naming Consistency4/5

All tools share a 'mysql_' prefix and are descriptive. However, patterns vary: 'list_sites' is verb_noun, but 'query' and 'schema' are single nouns, and 'current_site' is a noun phrase. Minor inconsistency.

Tool Count5/5

Four tools cover the essential operations for a MySQL interaction server: discovery, current context, querying, and schema inspection. Neither too few nor too many.

Completeness5/5

The tool set provides full coverage for read-only database interaction: listing sites, querying, and schema inspection. Any write operations are intentionally excluded for safety, so no missing functionality.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Provides secure, read-only access to MariaDB/MySQL databases, allowing users to list databases, explore table schemas, and execute SQL queries with built-in security measures.
    4
    72
    4
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables secure read-only querying of multiple database types (MySQL, PostgreSQL, MSSQL, Oracle) through natural language. Automatically reads database configuration from project files and blocks any data modification operations for safety.
    4
    16
    1
    ISC
  • A
    license
    A
    quality
    D
    maintenance
    Enables read-only MySQL database connectivity, allowing execution of SELECT queries, listing tables, and describing table structures via natural language.
    3
    23
    MIT

Latest Blog Posts

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/verygoodplugins/mcp-local-wp'

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