PostgreSQL, MySQL, Firestore를 포함한 다양한 유형의 데이터베이스를 탐색하고 관리하기 위한 강력한 모델 컨텍스트 프로토콜(MCP) 도구입니다.
다중 데이터베이스 지원
포스트그레스큐엘
MySQL
파이어스토어
데이터베이스 작업
데이터베이스에 연결
테이블 목록
트리거 보기
목록 함수
SQL 쿼리 실행(PostgreSQL 및 MySQL)
테이블 스키마 내보내기
테이블 데이터 내보내기
Related MCP server: Database MCP Server
커서에 도구를 추가하기 전에 프로젝트를 빌드해야 합니다.
저장소를 복제합니다
종속성 설치:
지엑스피1
프로젝트를 빌드하세요:
npm run build커서에 도구를 추가하려면:
커서 설정 열기
"모델 컨텍스트 프로토콜(MCP)" 섹션으로 이동합니다.
"새 도구 추가"를 클릭하세요
다음 세부 정보를 입력하세요.
{
"name": "database-explorer",
"command": "node /path/to/project/dist/index.js",
"description": "Database Explorer MCP Tool"
}참고: /path/to/project 프로젝트 디렉토리의 실제 경로로 바꾸세요.
설정을 저장하세요
커서 재시작
도구 사용:
설정 후 다음 명령 중 하나를 사용하여 데이터베이스에 연결할 수 있습니다.
PostgreSQL의 경우: 연결 세부 정보와 함께 !pg 사용하세요.
MySQL의 경우: 연결 세부 정보와 함께 !mysql 사용하세요.
Firestore의 경우: 연결 세부 정보와 함께 !firestore 사용하세요.
연결되면 다양한 데이터베이스 작업을 사용할 수 있습니다.
!tables 사용하여 모든 테이블을 나열합니다.
트리거를 보려면 !triggers 사용하세요.
!functions 를 나열합니다
!query 사용하여 SQL 쿼리를 실행합니다.
!export-db 사용하여 테이블 스키마를 내보냅니다.
!export-data 사용하여 테이블 데이터를 내보냅니다.
자세한 사용 예는 아래의 명령 섹션을 참조하세요.
!pg - PostgreSQL 데이터베이스에 연결
{
"connection": {
"host": "hostname",
"port": 5432,
"database": "dbname",
"user": "username",
"password": "password"
}
}!mysql - MySQL 데이터베이스에 연결
{
"connection": {
"host": "hostname",
"port": 3306,
"database": "dbname",
"user": "username",
"password": "password"
}
}!firestore - Firestore 데이터베이스에 연결
{
"connection": {
"projectId": "your-project-id",
"keyFilename": "path/to/keyfile.json"
}
}!tables - 연결된 데이터베이스의 모든 테이블을 나열합니다.
!triggers - 연결된 데이터베이스의 모든 트리거를 나열합니다.
!functions - 연결된 데이터베이스의 모든 함수를 나열합니다.
!query - SQL 쿼리 실행(PostgreSQL 및 MySQL만 해당)
{
"query": "SELECT * FROM table_name"
}!export-db - 테이블 스키마 내보내기
{
"table": "table_name"
}!export-data - 테이블 데이터를 INSERT 문으로 내보내기
{
"table": "table_name"
}노드.js
필요한 데이터베이스 드라이버:
PostgreSQL용 pg
MySQL용 mysql2
Firestore의 경우 @google-cloud/firestore
필요한 데이터베이스 자격 증명이 있는지 확인하세요
적절한 연결 명령을 사용하여 데이터베이스에 연결하세요.
사용 가능한 명령을 사용하여 데이터베이스를 탐색하고 관리하세요.
이 도구에는 다음에 대한 포괄적인 오류 처리 기능이 포함되어 있습니다.
연결 실패
쿼리 실행 오류
스키마 및 데이터 내보내기 문제
잘못된 데이터베이스 작업
Firestore 지원은 NoSQL 특성으로 인해 기본 작업에만 제한됩니다.
SQL 작업은 PostgreSQL 및 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.