PostgreSQL、MySQL、Firestore などのさまざまな種類のデータベースを探索および管理するための強力なモデル コンテキスト プロトコル (MCP) ツール。
複数のデータベースのサポート
PostgreSQL
MySQL
ファイアストア
データベース操作
データベースに接続する
テーブルの一覧
トリガーを表示
リスト関数
SQLクエリを実行する（PostgreSQLとMySQL）
テーブルスキーマをエクスポートする
テーブルデータをエクスポートする
Related MCP server: Database MCP Server
ツールをカーソルに追加する前に、プロジェクトをビルドする必要があります。
リポジトリをクローンする
依存関係をインストールします:
npm installプロジェクトをビルドします。
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"
}Node.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.