Which integrations are available for this server?

Provides tools to interact with MySQL databases, including listing databases and tables, describing table schemas, and executing read-only SQL queries (with optional write support when configured).

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 list tables in mydb" 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 walternascimentobarroso

Overview Schema Related Servers Score Discussions

Python

Remote

MySQL MCP (FastMCP)

Python MCP server built with FastMCP to connect to MySQL. It exposes tools to list databases and tables, describe tables, and execute SQL queries (read-only by default).

Requirements

Python 3.10+
MySQL reachable (host, username, password)

Related MCP server: @cano721/mysql-mcp-server

Installation

Requires uv. In the project directory:

cd /Users/macbook/projets/MCP/mysql
uv sync

This creates the virtual environment (.venv) and installs dependencies. No pip step is required.

To validate locally:

uv run env PYTHONPATH=src python -m mysql_mcp

Configuration

How the server reads credentials

The server uses environment variables with prefix MYSQL_. The resolution happens in two layers:

First: values provided to the process via env in Cursor mcp.json (or via shell/CI).
Second (fallback): values from the project .env file, but only for fields that are not defined in the environment.

This means that if you configure MYSQL_USER and MYSQL_PASSWORD in mcp.json, the project .env file will not override those values.

Environment variables (or .env file):

Variable	Required	Description	Default
`MYSQL_USER`	Yes	MySQL username	-
`MYSQL_PASSWORD`	Yes	Password	-
`MYSQL_HOST`	No	Host	127.0.0.1
`MYSQL_PORT`	No	Port	3306
`MYSQL_DATABASE`	No	Default database	-
`MYSQL_POOL_SIZE`	No	Connection pool size	5
`MYSQL_ALLOW_WRITE`	No	Allow INSERT/UPDATE/DELETE	false
`MYSQL_SSL_ENABLED`	No	Enable TLS/SSL for MySQL connection	false
`MYSQL_SSL_VERIFY_CERT`	No	Validate server certificate chain	true
`MYSQL_SSL_CA`	No	Path to CA bundle (recommended in prod)	-
`MYSQL_SSL_CERT`	No	Client certificate path (for mTLS)	-
`MYSQL_SSL_KEY`	No	Client private key path (for mTLS)	-

Security details

By default, the server only accepts read-only queries (for example: SELECT, SHOW, DESCRIBE). When MYSQL_ALLOW_WRITE=true, it also accepts INSERT, UPDATE, DELETE, and REPLACE.

Additional rules:

UPDATE and DELETE require an explicit WHERE clause (otherwise the query is rejected).

.env file (optional)

If you want, create /Users/macbook/projets/MCP/mysql/.env using the same format as the variables above. You can use /.env.example in this repository as a reference.

Minimum example (read-only):

MYSQL_USER=user
MYSQL_PASSWORD=password
MYSQL_DATABASE=database
MYSQL_ALLOW_WRITE=false

Production note (require_secure_transport=ON)

If your MySQL server enforces secure transport (--require_secure_transport=ON), you must enable TLS:

MYSQL_SSL_ENABLED=true
MYSQL_SSL_VERIFY_CERT=true
MYSQL_SSL_CA=/absolute/path/to/ca.pem

If you do not have a CA certificate available yet, you can still use TLS encryption without certificate validation:

MYSQL_SSL_ENABLED=true
MYSQL_SSL_VERIFY_CERT=false

This is useful as a temporary fallback, but it is less secure (susceptible to man-in-the-middle attacks). Prefer MYSQL_SSL_VERIFY_CERT=true with a valid CA bundle in production.

If your database requires mTLS, also set:

MYSQL_SSL_CERT=/absolute/path/to/client-cert.pem
MYSQL_SSL_KEY=/absolute/path/to/client-key.pem

Cursor note (mcp.json)

If you are using Cursor, the most common setup is to configure MYSQL_* directly in the env of the mysql server block inside /Users/macbook/.cursor/mcp.json (as shown in the Cursor example below). This avoids relying on the local .env file for credentials.

Running the server

STDIO (e.g. Claude Desktop, Cursor):

/usr/bin/env PYTHONPATH=/Users/macbook/projets/MCP/mysql/src /Users/macbook/projets/MCP/mysql/.venv/bin/python -m mysql_mcp

Alternative:

uv run env PYTHONPATH=src python -m mysql_mcp

HTTP (port 8000):

/Users/macbook/projets/MCP/mysql/.venv/bin/python -c "from mysql_mcp.server import run; run(transport='http', port=8000)"

Or with the FastMCP CLI:

uv run fastmcp run mysql_mcp.server:mcp --transport http --port 8000

MCP Tools

list_databases - Lists all databases.
list_tables - Lists tables in a database (optional database parameter).
describe_table - Returns column information (name, type, null, key, default, extra) for a table.
execute_query - Executes a validated SQL query (following the security rules).

Cursor configuration example

In Cursor Settings > MCP, add a server that will be started via stdio.

Important: for stdio, do not set transport=http and do not provide port. The server uses stdio by default.

Example (JSON in `~/.cursor/mcp.json`)

If you use Cursor global configuration, edit /Users/macbook/.cursor/mcp.json (or create a .cursor/mcp.json inside this project directory) and add a mcpServers entry like this:

{
  "mcpServers": {
    "mysql": {
      "command": "/usr/bin/env",
      "args": [
        "PYTHONPATH=/Users/macbook/projets/MCP/mysql/src",
        "/Users/macbook/projets/MCP/mysql/.venv/bin/python",
        "-m",
        "mysql_mcp"
      ],
      "cwd": "/Users/macbook/projets/MCP/mysql",
      "env": {
        "MYSQL_USER": "user",
        "MYSQL_PASSWORD": "password",
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_DATABASE": "database",
        "MYSQL_ALLOW_WRITE": "false"
      }
    }
  }
}

Per-project (recommended) - 3 environments

You can configure multiple MySQL targets per workspace by creating/updating:

/Users/macbook/projets/MCP/mysql/.cursor/mcp.json

Example (3 server blocks, read-only by default):

{
  "mcpServers": {
    "mysql_local": {
      "command": "/usr/bin/env",
      "args": [
        "PYTHONPATH=/Users/macbook/projets/MCP/mysql/src",
        "/Users/macbook/projets/MCP/mysql/.venv/bin/python",
        "-m",
        "mysql_mcp"
      ],
      "cwd": "/Users/macbook/projets/MCP/mysql",
      "env": {
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_HOST": "127.0.0.1",
        "MYSQL_PORT": "3306",
        "MYSQL_DATABASE": "database",
        "MYSQL_ALLOW_WRITE": "false"
      }
    },
    "mysql_staging": {
      "command": "/usr/bin/env",
      "args": [
        "PYTHONPATH=/Users/macbook/projets/MCP/mysql/src",
        "/Users/macbook/projets/MCP/mysql/.venv/bin/python",
        "-m",
        "mysql_mcp"
      ],
      "cwd": "/Users/macbook/projets/MCP/mysql",
      "env": {
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_HOST": "staging-db.example.com",
        "MYSQL_PORT": "3306",
        "MYSQL_DATABASE": "database",
        "MYSQL_ALLOW_WRITE": "false"
      }
    },
    "mysql_prod": {
      "command": "/usr/bin/env",
      "args": [
        "PYTHONPATH=/Users/macbook/projets/MCP/mysql/src",
        "/Users/macbook/projets/MCP/mysql/.venv/bin/python",
        "-m",
        "mysql_mcp"
      ],
      "cwd": "/Users/macbook/projets/MCP/mysql",
      "env": {
        "MYSQL_USER": "your_user",
        "MYSQL_PASSWORD": "your_password",
        "MYSQL_HOST": "prod-db.example.com",
        "MYSQL_PORT": "3306",
        "MYSQL_DATABASE": "database",
        "MYSQL_ALLOW_WRITE": "false",
        "MYSQL_SSL_ENABLED": "true",
        "MYSQL_SSL_VERIFY_CERT": "true",
        "MYSQL_SSL_CA": "/absolute/path/to/ca.pem"
      }
    }
  }
}

Notes:

For stdio, do not set transport=http and do not provide port.
If you removed the project .env, it is still fine: MYSQL_* must be provided via env in mcp.json (as shown above).
Recommended startup in MCP clients is setting PYTHONPATH directly in command/args (via /usr/bin/env), because some clients do not consistently apply env.PYTHONPATH.

Option A (recommended) - using uv:

Command: uv
Args: run, env, PYTHONPATH=src, python, -m, mysql_mcp
Cwd: project directory (where pyproject.toml lives)
Env: set MYSQL_USER, MYSQL_PASSWORD, and optionally MYSQL_HOST, MYSQL_PORT, MYSQL_DATABASE, MYSQL_ALLOW_WRITE, MYSQL_SSL_*

Option B - using the Makefile shortcut:

Command: make
Args: up
Cwd: project directory
Env: same values as Option A

Alternative - using the venv interpreter directly:

Command: /usr/bin/env
Args: PYTHONPATH=/absolute/path/to/project/src, .venv/bin/python, -m, mysql_mcp

License

MIT.

Available Tools

4 tools

describe_tableA

Return column information (name, type, null, key, default, extra) for a table.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes
`database`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/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 states that the tool 'return[s]' information, implying a read-only operation, but it does not describe edge cases (e.g., nonexistent table), error behavior, or the optional database context. This is adequate for a simple tool 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, front-loaded sentence with no filler. It efficiently communicates the core function and return fields.

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?

The tool is simple, and an output schema exists, so return format is covered. However, the description omits the database parameter and does not differentiate the tool from execute_query for schema exploration. This leaves some context gaps.

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 0%, so the description must explain parameters. It only mentions 'a table' implicitly referring to the table parameter, but does not describe the database parameter at all, nor does it clarify whether the table name is per database or fully qualified. This is a notable gap.

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

Purpose5/5

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

The description clearly states the tool's function: 'Return column information (name, type, null, key, default, extra) for a table.' This is a specific verb+resource combination that distinguishes it from siblings like list_databases and list_tables, which operate at a different level.

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 usage is implied by the description: you would use this tool when you need column metadata for a table. However, there is no explicit guidance on when to use it instead of alternatives like execute_query, nor any mention of the optional database parameter or prerequisites.

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

execute_queryA

Execute a read-only SQL query (SELECT, SHOW, DESCRIBE, etc.). Write operations require MYSQL_ALLOW_WRITE=true and must include a proper WHERE clause for UPDATE/DELETE.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`database`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the read-only default and the required MYSQL_ALLOW_WRITE=true and WHERE clause for write operations, which is valuable context beyond the schema. However, it does not mention pagination, limits, or error behavior.

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 two sentences, front-loaded with the primary purpose and followed by an important caveat. No wasted words; every sentence delivers actionable information.

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?

The tool has an output schema, so return values are likely covered, but the description omits the database parameter's purpose and does not reference sibling alternatives. The read-only and write-restriction details are helpful, but the missing param semantics leave a notable gap.

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 0%, so the description must compensate. It indirectly explains the query parameter as a SQL query but does not describe the database parameter at all. The description adds minimal meaning beyond the schema's bare property definitions.

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 executes SQL queries, specifically read-only ones like SELECT, SHOW, and DESCRIBE. This distinguishes it from sibling tools that handle specific tasks like listing databases or tables.

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 arbitrary read-only SQL queries and mentions write operations under specific conditions, but it does not explicitly compare with sibling tools or state when to prefer this tool over list_databases, list_tables, or describe_table. Context is present, but exclusions are not.

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 databases on the MySQL server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. The verb 'List' implies a read-only operation, but the description does not explicitly mention safety, side effects, or whether system databases are included. It adds minimal behavioral context beyond the tool's name.

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 ('List all databases on the MySQL server.') that is front-loaded with the action and resource, containing no wasted words.

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

Completeness5/5

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

Given the tool's low complexity (0 parameters), an output schema (so return values need not be described), and clear scope, the description is fully adequate. It is complete for its intended purpose without needing extra detail.

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?

There are 0 parameters, and the schema coverage is 100% (empty schema). The baseline for 0 parameters is 4, and the description has no additional parameter semantics to explain.

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' with a clear resource 'all databases on the MySQL server'. This clearly distinguishes it from sibling tools like list_tables (which lists tables) and describe_table (which describes a table).

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 retrieving an overview of all databases but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are mentioned, so the guidance is only implicit from the tool name and description.

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

list_tablesA

List tables in a database. If database is empty, uses the default configured database.

ParametersJSON Schema

Name	Required	Description	Default
`database`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/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. It discloses the fallback behavior for an empty database parameter, which is useful. However, it does not explicitly state that the operation is read-only or mention any side effects. Since an output schema exists, return format details are likely covered elsewhere, but the description could add more behavioral context.

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 concise, consisting of two sentences that are front-loaded with the main action. Every word contributes to the meaning, with no redundancy or filler.

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 operation with one optional parameter and an existing output schema, the description is nearly complete. It covers the primary purpose and an edge case (empty database). The only gap is the lack of explicit guidance on when to choose this tool over its siblings, but this is minor given the tool's simplicity.

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 provides only a default value for the database parameter without any description. The description clarifies that an empty value triggers the default configured database, adding meaningful semantics beyond the schema. With one parameter and 0% schema description coverage, this compensation is effective, though it could be slightly more explicit about accepting a database name.

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

Purpose5/5

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

The description clearly states the tool's function with a specific verb and resource: 'List tables in a database.' This distinguishes it from sibling tools like list_databases, describe_table, and execute_query by focusing on the enumeration of tables.

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

Usage Guidelines3/5

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

The description provides some usage context by explaining the behavior when the database parameter is empty (defaults to the configured database), but it does not explicitly state when to use this tool versus alternatives such as list_databases or describe_table. The usage is implied by the purpose, but no exclusions 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.

Tool Schema Changelog

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

4 tool updatesv0.1.0Aug 10, 2026
- First observeddescribe_table
- First observedexecute_query
- First observedlist_databases
- First observedlist_tables

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource operation: databases, tables, schema, and custom queries. There is no ambiguity because the specific tools are convenient shortcuts, and execute_query is the catch-all for arbitrary read-only SQL.

Naming Consistency5/5

All tool names follow the verb_noun pattern with lowercase and underscores: list_databases, list_tables, describe_table, execute_query. The convention is consistent and predictable.

Tool Count5/5

Four tools is well-scoped for a read-only MySQL server. Each tool earns its place: listing databases, listing tables, describing schemas, and running custom queries—no superfluous tools.

Completeness4/5

Covers the full read-only workflow: discover databases, list tables, inspect column structure, and execute arbitrary SELECT/SHOW queries. Missing write operations are intentional, but there is no tool for viewing indexes/foreign keys, which is a minor gap.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
SRI — MCP Server Inspector A
biz.sri-test
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Developer Tools
21

Related MCP Servers

MySQL MCP Server
Databases Developer Tools Code Execution
dave-wind
A
license
Not graded
quality
D
maintenance
A server that provides LLMs with read-only access to MySQL databases, allowing them to inspect database schemas and execute read-only queries.
Updated 4 months ago (2026-05-18 14:28 UTC)
145
14
MIT
@cano721/mysql-mcp-server
Databases Developer Tools
cano721
A
license
A
quality
D
maintenance
Enables read-only MySQL database access, allowing listing databases, tables, describing schemas, and executing SELECT/SHOW/DESCRIBE/EXPLAIN queries.
Updated 8 months ago (2026-01-09 08:45 UTC)
7
89
4
MIT
local-mysql
Databases Developer Tools
myexperimenthub
F
license
A
quality
C
maintenance
Provides read-only access to a local MySQL database, enabling SQL queries, database and table listings, and table schema descriptions.
Updated 3 months ago (2026-06-14 18:13 UTC)
4
-
MySQL Ops MCP
Databases Developer Tools
lemonq3q
F
license
Not graded
quality
C
maintenance
A generic MCP server for MySQL operations, enabling listing databases/tables, describing schemas, running read-only SQL, and optionally executing write SQL with logging.
Updated 2 months ago (2026-07-06 00:46 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/walternascimentobarroso/database_mcp'

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

MySQL MCP (FastMCP)

Requirements

Installation

Configuration

Running the server

MCP Tools

Cursor configuration example

Example (JSON in ~/.cursor/mcp.json)

Per-project (recommended) - 3 environments

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Example (JSON in `~/.cursor/mcp.json`)