Una poderosa herramienta de Protocolo de Contexto de Modelo (MCP) para explorar y administrar diferentes tipos de bases de datos, incluidos PostgreSQL, MySQL y Firestore.
Compatibilidad con múltiples bases de datos
PostgreSQL
MySQL
Firestore
Operaciones de base de datos
Conectarse a bases de datos
Tablas de listas
Ver activadores
Funciones de lista
Ejecutar consultas SQL (PostgreSQL y MySQL)
Exportar esquemas de tablas
Exportar datos de la tabla
Related MCP server: Database MCP Server
Antes de agregar la herramienta a Cursor, debe compilar el proyecto:
Clonar el repositorio
Instalar dependencias:
npm installConstruir el proyecto:
npm run buildPara agregar la herramienta al Cursor:
Abrir la configuración del cursor
Vaya a la sección "Protocolo de Contexto de Modelo (MCP)".
Haga clic en "Agregar nueva herramienta"
Complete los siguientes datos:
{
"name": "database-explorer",
"command": "node /path/to/project/dist/index.js",
"description": "Database Explorer MCP Tool"
}Nota: Reemplace /path/to/project con la ruta real al directorio de su proyecto.
Guardar la configuración
Reiniciar cursor
Usando la herramienta:
Después de la configuración, puede conectarse a su base de datos utilizando uno de estos comandos:
Para PostgreSQL: utilice !pg con detalles de conexión
Para MySQL: utilice !mysql con detalles de conexión
Para Firestore: use !firestore con detalles de conexión
Una vez conectado, podrá utilizar varias operaciones de base de datos:
!tables para listar todas las tablas
!triggers para ver los activadores
!functions para enumerar funciones
!query para ejecutar consultas SQL
!export-db para exportar esquemas de tablas
!export-data para exportar datos de la tabla
Consulte la sección Comandos a continuación para ver ejemplos de uso detallados.
!pg - Conectarse a la base de datos PostgreSQL
{
"connection": {
"host": "hostname",
"port": 5432,
"database": "dbname",
"user": "username",
"password": "password"
}
}!mysql - Conectarse a la base de datos MySQL
{
"connection": {
"host": "hostname",
"port": 3306,
"database": "dbname",
"user": "username",
"password": "password"
}
}!firestore - Conectarse a la base de datos de Firestore
{
"connection": {
"projectId": "your-project-id",
"keyFilename": "path/to/keyfile.json"
}
}!tables - Lista todas las tablas en la base de datos conectada
!triggers - Lista todos los activadores en la base de datos conectada
!functions - Lista todas las funciones en la base de datos conectada
!query - Ejecutar consulta SQL (solo PostgreSQL y MySQL)
{
"query": "SELECT * FROM table_name"
}!export-db - Exportar esquema de tabla
{
"table": "table_name"
}!export-data - Exportar datos de la tabla como instrucciones INSERT
{
"table": "table_name"
}Node.js
Controladores de base de datos necesarios:
pg para PostgreSQL
mysql2 para MySQL
@google-cloud/firestore para Firestore
Asegúrese de tener las credenciales de base de datos necesarias
Conéctese a su base de datos utilizando el comando de conexión apropiado
Utilice los comandos disponibles para explorar y administrar su base de datos
La herramienta incluye un manejo integral de errores para:
Fallos de conexión
Errores de ejecución de consultas
Problemas de esquema y exportación de datos
Operaciones de base de datos no válidas
El soporte de Firestore está limitado a operaciones básicas debido a su naturaleza NoSQL
Las operaciones SQL solo están disponibles para PostgreSQL y MySQL
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| connection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| connection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| connection | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0!export-data!export-db!firestore!functions!mysql!pg!query!tables!triggersScored across 9 tools
The tools are completely indistinguishable due to the lack of descriptions and ambiguous naming. For example, '!export-data' and '!export-db' likely overlap significantly, while '!mysql' and '!pg' might both handle database operations without clear differentiation. Without descriptions, an agent cannot determine the purpose or boundaries of any tool.
The naming is inconsistent with a mix of conventions: some tools use hyphens (e.g., '!export-data'), others are single words (e.g., '!mysql'), and some are abbreviations (e.g., '!pg'). While all start with '!', there is no predictable verb_noun pattern or consistent style, making it hard to infer relationships.
With 9 tools, the count is reasonable for a database-related server, but the lack of descriptions makes it impossible to assess if this number is well-scoped. It could be appropriate if each tool covers a distinct aspect, but currently, it feels borderline due to the ambiguity.
The server appears to target database operations, but without descriptions, it is impossible to assess coverage. Tools like '!query' and '!tables' suggest basic operations, but there are likely significant gaps (e.g., no clear create, update, or delete tools) and no way to determine if the surface supports a complete workflow.
PostgreSQL, MySQL, and SQL Server in one session. 26 read-only MCP tools for AI agents.
Managed Postgres MCP: projects, SQL, docs search, and storage buckets via OAuth.
The AI that understands raw data: Schema over your tables and databases, as MCP tools.