en es ja ko zh

SingleStore MCP Server

Name: SingleStore MCP Server
Author: madhukarkumar

by madhukarkumar

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

シングルストア MCP サーバー

鍛冶屋のバッジ

SingleStoreデータベースと連携するためのモデルコンテキストプロトコル（MCP）サーバー。このサーバーは、テーブルのクエリ、スキーマの記述、ERダイアグラムの生成のためのツールを提供します。

特徴

データベース内のすべてのテーブルを一覧表示する
カスタムSQLクエリを実行する
スキーマやサンプルデータを含む詳細なテーブル情報を取得します
データベーススキーマの Mermaid ER 図を生成する
自動 CA バンドル取得による SSL サポート
適切なエラー処理とTypeScriptの型安全性

Related MCP server: SingleStore MCP Server

前提条件

Node.js 16以上
npmまたはyarn
SingleStoreデータベースへのアクセス
SingleStore CA バンドル (ポータルから自動的に取得)

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の SingleStore MCP Server を自動的にインストールするには:

npx -y @smithery/cli install @madhukarkumar/singlestore-mcp-server --client claude

リポジトリをクローンします。

git clone <repository-url>
cd mcp-server-singlestore

依存関係をインストールします:

npm install

サーバーを構築します。

npm run build

環境変数

必要な環境変数

サーバーは、データベース接続に次の環境変数を必要とします。

SINGLESTORE_HOST=your-host.singlestore.com
SINGLESTORE_PORT=3306
SINGLESTORE_USER=your-username
SINGLESTORE_PASSWORD=your-password
SINGLESTORE_DATABASE=your-database

これらの環境変数はすべて、サーバーがSingleStoreデータベースへの接続を確立するために必要です。接続には、SingleStoreポータルから自動的に取得されるSingleStore CAバンドルを使用したSSLが使用されます。

オプションの環境変数

SSE (Server-Sent Events) プロトコルのサポート:

SSE_ENABLED=true       # Enable the SSE HTTP server (default: false if not set)
SSE_PORT=3333          # HTTP port for the SSE server (default: 3333 if not set)

環境変数の設定

シェルの場合: サーバーを実行する前にターミナルで変数を設定します。

export SINGLESTORE_HOST=your-host.singlestore.com
export SINGLESTORE_PORT=3306
export SINGLESTORE_USER=your-username
export SINGLESTORE_PASSWORD=your-password
export SINGLESTORE_DATABASE=your-database

クライアント構成ファイル: 以下の統合セクションに示すように、MCP クライアント構成ファイルに変数を追加します。

使用法

プロトコルサポート

このサーバーは、クライアント統合用の 2 つのプロトコルをサポートしています。

MCP プロトコル: Claude Desktop、Windsurf、および Cursor で使用される、stdio 通信を使用する標準モデルコンテキストプロトコル。
SSE プロトコル: リアルタイムのデータストリーミングを必要とする Web ベースのクライアントおよびアプリケーション用の、HTTP 経由のサーバー送信イベント。

どちらのプロトコルも同じツールと機能を公開しているため、ユースケースに最適な統合方法を選択できます。

利用可能なツール

リストテーブル
- データベース内のすべてのテーブルを一覧表示します
- パラメータ不要 GXP8
クエリテーブル
- カスタムSQLクエリを実行する
- パラメータ:
  - クエリ: SQLクエリ文字列 GXP9
テーブルの説明
- テーブルに関する詳細情報を取得します
- パラメータ:
  - テーブル: テーブル名 GXP10
図を生成する
- データベーススキーマのMermaid ER図を生成します
- パラメータ不要 GXP11
実行読み取りクエリ
- データベースに対して読み取り専用（SELECT）クエリを実行します。
- パラメータ:
  - クエリ: GXP12を実行するためのSQL SELECTクエリ
テーブル作成
- 指定された列と制約を持つデータベースに新しいテーブルを作成します
- パラメータ:
  - table_name: 作成するテーブルの名前
  - columns: 列定義の配列
  - table_options: オプションのテーブル構成 GXP13
合成データを生成する
- 合成データを生成し、既存のテーブルに挿入する
- パラメータ:
  - テーブル: データを挿入するテーブルの名前
  - count: 生成する行数（デフォルト: 100）
  - column_generators: 特定の列用のカスタムジェネレーター
  - バッチサイズ: 各バッチに挿入する行数（デフォルト: 1000）GXP14
最適化SQL
- PROFILE を使用して SQL クエリを分析し、最適化の推奨事項を提供します
- パラメータ:
  - クエリ: GXP15 を分析および最適化するための SQL クエリ
- 応答には次のものが含まれます。
  - 元のクエリ
  - パフォーマンスプロファイルの概要 (合計実行時間、コンパイル時間、実行時間)
  - 検出されたボトルネックのリスト
  - 影響レベル（高/中/低）による最適化の推奨事項
  - インデックス、結合、メモリ使用量、その他の最適化に関する提案

スタンドアロン実行

サーバーを構築します。

npm run build

MCP プロトコルのみでサーバーを実行します。

node build/index.js

MCP プロトコルと SSE プロトコルの両方を使用してサーバーを実行します。

SSE_ENABLED=true SSE_PORT=3333 node build/index.js

SSEプロトコルの使用

SSE が有効になっている場合、サーバーは次の HTTP エンドポイントを公開します。

ルートエンドポイント
```
GET /
```
サーバー情報と利用可能なエンドポイントを返します。
健康チェック
```
GET /health
```
サーバーのステータス情報を返します。
SSE接続
```
GET /sse
```
リアルタイム更新のために Server-Sent Events 接続を確立します。
リストツール
```
GET /tools
```
MCP list_tools機能と同じように、使用可能なすべてのツールのリストを返します。
MCP Inspector との互換性のために POST リクエストもサポートします。
```
POST /tools
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "request-id",
  "method": "mcp.list_tools",
  "params": {}
}
```

通話ツール

POST /call-tool
Content-Type: application/json

{
  "name": "tool_name",
  "arguments": {
    "param1": "value1",
    "param2": "value2"
  },
  "client_id": "optional_sse_client_id_for_streaming_response"
}

指定された引数を使用してツールを実行します。

client_idが指定されている場合、応答はその SSE クライアントにストリーミングされます。
client_idを省略すると、応答は HTTP 応答で直接返されます。

MCP Inspector との互換性のために標準の MCP 形式もサポートしています。

POST /call-tool
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "request-id",
  "method": "mcp.call_tool",
  "params": {
    "name": "tool_name",
    "arguments": {
      "param1": "value1",
      "param2": "value2"
    },
    "_meta": {
      "client_id": "optional_sse_client_id_for_streaming_response"
    }
  }
}

SSEイベントの種類

SSE 接続を使用する場合、サーバーは次のイベントタイプを送信します。

メッセージ(名前のないイベント): SSE 接続が正常に確立されたときに送信されます。
open : 追加の接続確立イベント。
メッセージ: ツールの開始、結果、エラーイベントを含むすべての MCP プロトコルメッセージに使用されます。

すべてのイベントは、MCPプロトコルで使用されるJSON-RPC 2.0形式に準拠しています。システムは、MCPインスペクタおよびほとんどのSSEクライアントライブラリとの互換性を確保するために、標準のmessageイベントタイプを使用しています。

JavaScriptクライアントの例

// Connect to SSE endpoint
const eventSource = new EventSource('http://localhost:3333/sse');
let clientId = null;

// Handle connection establishment via unnamed event
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.type === 'connection_established') {
    clientId = data.clientId;
    console.log(`Connected with client ID: ${clientId}`);
  }
};

// Handle open event
eventSource.addEventListener('open', (event) => {
  console.log('SSE connection opened via open event');
});

// Handle all MCP messages
eventSource.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
  
  if (data.jsonrpc === '2.0') {
    if (data.result) {
      console.log('Tool result:', data.result);
    } else if (data.error) {
      console.error('Tool error:', data.error);
    } else if (data.method === 'mcp.call_tool.update') {
      console.log('Tool update:', data.params);
    }
  }
});

// Call a tool with streaming response (custom format)
async function callTool(name, args) {
  const response = await fetch('http://localhost:3333/call-tool', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      name: name,
      arguments: args,
      client_id: clientId
    })
  });
  return response.json();
}

// Call a tool with streaming response (MCP format)
async function callToolMcp(name, args) {
  const response = await fetch('http://localhost:3333/call-tool', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 'request-' + Date.now(),
      method: 'mcp.call_tool',
      params: {
        name: name,
        arguments: args,
        _meta: {
          client_id: clientId
        }
      }
    })
  });
  return response.json();
}

// Example usage
callTool('list_tables', {})
  .then(response => console.log('Request accepted:', response));

MCP Inspectorと併用

MCP Inspectorは、MCPサーバーのテストとデバッグのためのブラウザベースのツールです。このサーバーで使用するには、以下の手順に従ってください。

1 つのコマンドでサーバーと MCP インスペクターの両方を起動します。
```
npm run inspector
```
または、次のコマンドでサーバーのみを起動します。
```
npm run start:inspector
```
MCP Inspector を個別にインストールして実行するには:
```
npx @modelcontextprotocol/inspector
```
インスペクターはデフォルトのブラウザで開きます。
MCP インスペクターが開いたら:
a. 接続フィールドにURLを入力します。
```
http://localhost:8081
```
注: 実際のポートは設定によって異なる場合があります。実際に使用されているポートについては、サーバーの起動ログを確認してください。サーバーは次のように出力します。
```
MCP SingleStore SSE server listening on port XXXX
```
b. トランスポートタイプとして「SSE」が選択されていることを確認します。
c. 「接続」をクリックする
接続の問題が発生した場合は、次の代替案を試してください。
a. 特定のエンドポイントに接続してみます。
```
http://localhost:8081/stream
```
b. マシンの実際の IP アドレスを使用してみます。
```
http://192.168.1.x:8081
```
c. Dockerで実行している場合:
```
http://host.docker.internal:8081
```
接続の問題のデバッグ:
a. ブラウザでhttp://localhost:8081にアクセスして、サーバーが動作していることを確認します。
b. サーバーログで接続試行を確認する
c. サーバーとインスペクターの両方を再起動してみてください
d. 他のサービスがポート8081を使用していないことを確認する
e. 提供されたスクリプトを使用して SSE 接続をテストします。
```
npm run test:sse
```
または、curl を使用して手動で実行します。
```
curl -N http://localhost:8081/sse
```
f. ファイアウォールの設定でポート8081への接続が許可されていることを確認します。
接続すると、インスペクターに利用可能なすべてのツールが表示され、インタラクティブにテストできるようになります。

⚠️注意: MCP インスペクターを使用する場合は、 http://プレフィックスを含む完全な URL を使用する必要があります。

MCPクライアント統合

Claude Desktopへのインストール

次の場所にある Claude Desktop 構成ファイルにサーバー構成を追加します。
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "singlestore": {
      "command": "node",
      "args": ["path/to/mcp-server-singlestore/build/index.js"],
      "env": {
        "SINGLESTORE_HOST": "your-host.singlestore.com",
        "SINGLESTORE_PORT": "3306",
        "SINGLESTORE_USER": "your-username",
        "SINGLESTORE_PASSWORD": "your-password",
        "SINGLESTORE_DATABASE": "your-database",
        "SSE_ENABLED": "true",
        "SSE_PORT": "3333"
      }
    }
  }
}

SSE_ENABLED および SSE_PORT 変数はオプションです。標準の MCP プロトコルに加えて、SSE サポート付きの HTTP サーバーを有効にする場合は、これらの変数を含めてください。

Claudeデスクトップアプリを再起動します
Claude との会話では、SingleStore MCP サーバーを次のように使用できるようになりました。

use_mcp_tool({
  server_name: "singlestore",
  tool_name: "list_tables",
  arguments: {}
})

Windsurfへのインストール

次の場所にある Windsurf 構成ファイルにサーバー構成を追加します。
- macOS: ~/Library/Application Support/Windsurf/config.json
- Windows: %APPDATA%\Windsurf\config.json

{
  "mcpServers": {
    "singlestore": {
      "command": "node",
      "args": ["path/to/mcp-server-singlestore/build/index.js"],
      "env": {
        "SINGLESTORE_HOST": "your-host.singlestore.com",
        "SINGLESTORE_PORT": "3306",
        "SINGLESTORE_USER": "your-username",
        "SINGLESTORE_PASSWORD": "your-password",
        "SINGLESTORE_DATABASE": "your-database",
        "SSE_ENABLED": "true",
        "SSE_PORT": "3333"
      }
    }
  }
}

SSE_ENABLED および SSE_PORT 変数はオプションですが、SSE HTTP サーバーを通じて追加機能を有効にします。

ウィンドサーフィンを再開
Windsurf での Claude との会話では、Claude がデータベース情報にアクセスする必要があるときに、SingleStore MCP ツールが自動的に使用できるようになります。

カーソルへのインストール

カーソル設定にサーバー構成を追加します。
- オープンカーソル
- 設定（歯車アイコン）>拡張機能>Claude AI>MCPサーバーに移動します
- 次の構成で新しい MCP サーバーを追加します。

{
  "singlestore": {
    "command": "node",
    "args": ["path/to/mcp-server-singlestore/build/index.js"],
    "env": {
      "SINGLESTORE_HOST": "your-host.singlestore.com",
      "SINGLESTORE_PORT": "3306",
      "SINGLESTORE_USER": "your-username",
      "SINGLESTORE_PASSWORD": "your-password",
      "SINGLESTORE_DATABASE": "your-database",
      "SSE_ENABLED": "true",
      "SSE_PORT": "3333"
    }
  }
}

SSE_ENABLED および SSE_PORT 変数により、Web アプリケーションは HTTP 経由でサーバーに接続し、Server-Sent Events を通じてリアルタイムの更新を受信できるようになります。

カーソルを再開
Cursor 内で Claude AI を使用する場合、データベース操作に SingleStore MCP ツールが使用できるようになります。

セキュリティに関する考慮事項

バージョン管理に資格情報をコミットしない
環境変数または安全な構成管理を使用する
実稼働環境での接続プーリングメカニズムの使用を検討する
SingleStore で適切なアクセス制御とユーザー権限を実装する
SingleStore CAバンドルを最新の状態に保つ

発達

プロジェクト構造

mcp-server-singlestore/
├── src/
│   └── index.ts      # Main server implementation
├── package.json
├── tsconfig.json
├── README.md
└── CHANGELOG.md

建物

npm run build

テスト

npm test

トラブルシューティング

接続の問題
- 環境変数の資格情報とホスト情報を確認する
- SSL設定を確認する
- ネットワークからデータベースにアクセスできることを確認する
- ファイアウォールの設定を確認し、SingleStore データベースへの送信接続を許可してください。
ビルドの問題
- node_modulesをクリアして依存関係を再インストールする
- TypeScriptの設定を確認する
- Node.js バージョンの互換性を確認します (16 以上である必要があります)
MCP統合の問題
- クライアント構成でサーバーのbuild/index.jsファイルへのパスが正しいことを確認します。
- クライアント構成ですべての環境変数が適切に設定されていることを確認します
- 構成を変更した後、クライアントアプリケーションを再起動します。
- クライアントログでMCPサーバーに関連するエラーメッセージを確認します。
- まずサーバーをスタンドアロンで実行して、クライアントの外で動作するか確認します。

貢献

リポジトリをフォークする
機能ブランチを作成する
変更をコミットする
ブランチにプッシュする
プルリクエストを作成する

ライセンス

MITライセンス - 詳細はLICENSEファイルを参照

Available Tools

8 tools

create_tableC

Create a new table in the database with specified columns and constraints

ParametersJSON Schema

Name	Required	Description
`columns`	Yes	List of columns to create
`table_name`	Yes	Name of the table to create
`table_options`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention important behavioral aspects: whether this requires specific database permissions, if it's a destructive operation that might overwrite existing tables, what happens on success/failure, or any rate limits. The description is minimal and doesn't compensate for the lack of annotations.

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, efficient sentence that front-loads the core purpose ('Create a new table in the database') and adds necessary qualification ('with specified columns and constraints'). Every word serves a purpose with zero waste or redundancy. It's appropriately sized for a creation operation with moderate complexity.

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

Completeness2/5

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

For a database mutation tool with no annotations, no output schema, and moderate parameter complexity (3 parameters including nested objects), the description is insufficient. It doesn't address critical context: what permissions are needed, whether the operation is idempotent, what happens if a table already exists, what the return value looks like, or error conditions. The agent lacks necessary operational context for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'columns and constraints' which aligns with the 'columns' and 'table_options' parameters in the schema, providing some semantic context beyond the schema's technical descriptions. However, with 67% schema description coverage (2 of 3 parameters have descriptions), the description doesn't fully compensate for the coverage gap - it doesn't explain what 'table_options' encompasses or provide examples of constraint types. The baseline is appropriate given partial schema coverage.

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 action ('Create a new table') and the resource ('in the database'), with additional context about what gets created ('with specified columns and constraints'). It distinguishes from siblings like 'list_tables' or 'describe_table' by being a creation operation rather than querying existing tables. However, it doesn't explicitly differentiate from other potential table-related operations that might exist in other contexts.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., database permissions, existing schema), when not to use it (e.g., for temporary tables vs permanent), or refer to sibling tools like 'generate_er_diagram' for design planning or 'optimize_sql' for performance considerations. The agent must infer usage from the tool name alone.

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

describe_tableC

Get detailed information about a table

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes	Name of the table to describe

TDQS

C2.9/5.0

Behavior2/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 of behavioral disclosure. It states the action ('Get detailed information') but doesn't describe what 'detailed information' includes (e.g., schema, columns, constraints), whether it requires specific permissions, or how errors are handled. For a tool with no annotations, this leaves significant gaps in understanding its 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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose ('Get detailed information about a table'), making it easy to parse quickly. Every word earns its place, and there's no unnecessary elaboration.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex metadata. It doesn't explain what 'detailed information' entails (e.g., column types, indexes), leaving the agent uncertain about the return value. For a tool with such contextual gaps, more detail is needed to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'table' parameter clearly documented as 'Name of the table to describe'. The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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 verb ('Get') and resource ('detailed information about a table'), making the purpose immediately understandable. It distinguishes from siblings like 'list_tables' (which lists tables) and 'query_table' (which queries data), though it doesn't explicitly differentiate them. The description is specific but lacks explicit sibling differentiation for a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'describe_table' instead of 'list_tables' (for metadata vs. listing) or 'query_table' (for data vs. structure), nor does it specify prerequisites like needing an existing table. Usage is implied from the name but not explicitly stated.

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

generate_er_diagramB

Generate a Mermaid ER diagram of the database schema

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/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 the action but does not reveal any behavioral traits such as whether it requires database permissions, if it's read-only or mutative, potential rate limits, or what the output format entails beyond 'Mermaid ER diagram'. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.

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, efficient sentence that directly states the tool's function with zero waste. It is front-loaded and appropriately sized for a tool with no parameters, making it easy for an agent to parse and understand quickly.

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?

Given the tool has no parameters, no annotations, and no output schema, the description is minimally adequate by stating what it does. However, it lacks details on output format (e.g., Mermaid syntax specifics), behavioral context, or usage compared to siblings, which are important for a tool that generates diagrams. This makes it complete enough for basic understanding but with clear gaps in practical guidance.

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 tool has 0 parameters, and the schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for such cases is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information, though it could slightly improve by noting the lack of parameters explicitly.

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 verb 'Generate' and the resource 'Mermaid ER diagram of the database schema', making the purpose specific and actionable. However, it does not explicitly differentiate from sibling tools like 'describe_table' or 'list_tables', which might also provide schema information, so it falls short of a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives such as 'describe_table' for detailed table info or 'list_tables' for a simple overview. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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

generate_synthetic_dataC

Generate and insert synthetic data into an existing table

ParametersJSON Schema

Name	Required	Description
`batch_size`	No	Number of rows to insert in each batch
`column_generators`	No	Custom generators for specific columns (optional)
`count`	No	Number of rows to generate and insert
`table`	Yes	Name of the table to insert data into

TDQS

C2.9/5.0

Behavior2/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 mentions 'insert' implying a write operation, but lacks details on permissions needed, whether data overwrites existing rows, transaction behavior, or error handling. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it could be slightly more informative given the tool's complexity.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after insertion (e.g., success confirmation, row count returned), error conditions, or dependencies on existing table structure, leaving significant gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying data generation and insertion, which is already clear from the tool name. Baseline 3 is appropriate when the schema does all the work.

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 action ('Generate and insert synthetic data') and the target resource ('into an existing table'), which distinguishes it from siblings like create_table or query_table. However, it doesn't explicitly differentiate from all siblings (e.g., run_read_query might also involve data manipulation).

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., table must exist), when not to use it (e.g., for production data), or refer to sibling tools like create_table for table creation first.

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

list_tablesB

List all tables in the database

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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

There are no annotations, so the description must fully disclose behavior. It merely states 'List all tables', which implies a read operation, but omits details on permissions, output format, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no unnecessary words. It is appropriately front-loaded but lacks any structural enhancement like bullet points that could aid readability.

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

Completeness2/5

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

Given no output schema or annotations, the description should explain what 'list' returns (e.g., table names, schemas). Without this, an agent may not know how to use the result. Sibling tools like 'describe_table' suggest additional context might be needed.

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 tool has no parameters, so the description cannot add parameter meaning. Baseline for zero parameters is 4, and the description is sufficient for the parameterless case.

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 tables in the database. While it distinguishes from 'describe_table' by listing instead of describing, it does not explicitly differentiate from potential siblings like 'query' or 'execute'.

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?

The description provides no guidance on when to use this tool versus its siblings (describe_table, execute, query). It is implied that it retrieves table names, but no context on prerequisites or alternatives.

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

optimize_sqlB

Analyze a SQL query using PROFILE and provide optimization recommendations

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query to analyze and optimize

TDQS

B3.3/5.0

Behavior2/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 mentions the tool uses 'PROFILE' (implying a profiling mechanism) and provides recommendations, but doesn't specify whether this is a read-only analysis, if it requires specific permissions, what the output format looks like, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that front-loads the core functionality ('analyze a SQL query') and adds key details ('using PROFILE and provide optimization recommendations') without any wasted words. Every part of the sentence contributes directly to understanding the tool's purpose.

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?

Given the tool's moderate complexity (analysis with optimization recommendations), no annotations, no output schema, and a single well-documented parameter, the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, output format, and usage context relative to siblings, which are needed for a more complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'query' well-documented in the schema ('SQL query to analyze and optimize'). The description adds minimal value beyond this, only reiterating that it analyzes and optimizes the query. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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's purpose with specific verbs ('analyze' and 'provide optimization recommendations') and identifies the resource ('SQL query'). It distinguishes from siblings like 'query_table' or 'run_read_query' by focusing on analysis rather than execution. However, it doesn't explicitly differentiate from all siblings (e.g., 'describe_table' might also analyze queries).

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 context ('analyze a SQL query... and provide optimization recommendations'), suggesting it's for performance tuning rather than data retrieval or schema operations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'run_read_query' for execution or 'describe_table' for schema analysis, and doesn't mention prerequisites or exclusions.

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

query_tableC

Execute a query on a table

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL query to execute

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits such as whether it's read-only or destructive, permission requirements, rate limits, or response format. It lacks critical context for safe and effective use.

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, efficient sentence with zero waste, appropriately sized and front-loaded. It directly states the tool's function without unnecessary elaboration, earning full marks for conciseness.

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

Completeness2/5

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

Given the tool's complexity (executing queries, potentially with side effects), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It fails to provide enough context for the agent to understand risks, results, or proper application.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the 'query' parameter as 'SQL query to execute'. The description adds no additional meaning beyond this, such as query syntax examples or constraints, resulting in a baseline score of 3.

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

Purpose3/5

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

The description 'Execute a query on a table' states a general purpose (verb+resource) but is vague about what type of query (read/write, SQL specifics) and doesn't distinguish from sibling 'run_read_query' or 'optimize_sql'. It minimally meets the requirement but lacks specificity for differentiation.

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 guidance is provided on when to use this tool versus alternatives like 'run_read_query' or 'optimize_sql'. The description implies a general query execution but doesn't specify context, exclusions, or prerequisites, leaving the agent with no usage direction.

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

run_read_queryB

Execute a read-only (SELECT) query on the database

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL SELECT query to execute

TDQS

B3.2/5.0

Behavior2/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 'read-only (SELECT)' which implies non-destructive and safe operations, but fails to address critical aspects like permissions needed, rate limits, error handling, or what the output looks like (e.g., result format, pagination). This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that front-loads key information ('Execute a read-only (SELECT) query'). There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.

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

Completeness2/5

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

For a database query tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., security, performance), output format, and usage guidelines compared to siblings. While concise, it does not provide enough context for an agent to reliably use the tool without additional assumptions or trial-and-error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'query' parameter clearly documented as 'SQL SELECT query to execute'. The description adds no additional semantic details beyond this, such as syntax examples, supported SQL features, or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.

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 action ('Execute') and resource ('read-only (SELECT) query on the database'), making the purpose immediately understandable. It distinguishes from siblings like 'create_table' or 'optimize_sql' by specifying read-only SELECT operations, though it doesn't explicitly contrast with 'query_table' which might have overlapping functionality.

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 executing SELECT queries, but provides no explicit guidance on when to use this tool versus alternatives like 'query_table' or 'optimize_sql'. It mentions 'read-only' which suggests safety, but lacks details on prerequisites, limitations, or specific scenarios where this tool is preferred.

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.

8 tool updatesv1.0.0Aug 18, 2025
- First observedcreate_table
- First observeddescribe_table
- First observedgenerate_er_diagram
- First observedgenerate_synthetic_data
- First observedlist_tables
- First observedoptimize_sql
- First observedquery_table
- First observedrun_read_query

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored 2026-04-18 11:35 across 8 tools

Disambiguation4/5

Most tools have distinct purposes, but query_table and run_read_query overlap significantly as both execute SELECT queries, which could cause confusion. The other tools target clear, separate operations like table management, schema visualization, and query optimization.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as create_table, list_tables, and optimize_sql. This predictability makes it easy for agents to understand and navigate the tool set without confusion.

Tool Count5/5

With 8 tools, this server is well-scoped for database operations, covering essential tasks like table management, query execution, and schema analysis. Each tool serves a clear purpose, and the count is neither too sparse nor overwhelming for the domain.

Completeness4/5

The tool set provides strong coverage for core database workflows, including CRUD-like operations (create, list, describe, query) and utilities like optimization and data generation. A minor gap is the lack of update or delete operations, which agents might need to work around, but the surface is largely complete for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

AI2SQLOAuth
io.ai2sql
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Databases Developer Tools
1
SaturnSQL
com.saturnsql
Query Postgres, MySQL, SQL Server, Oracle, BigQuery, ClickHouse and Redshift from your AI client.
Databases
81
PlanetScaleOAuth
io.github.planetscale
Connect to PlanetScale databases, branches, schema, query insights, and execute SQL
Databases Cloud Platforms Developer Tools
25
Draxlr AOAuth
com.draxlr.api
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
Data Visualization Databases Search
1

Related MCP Servers

MySQL Server MCP Server
Databases Developer Tools
xianzong85
A
license
Not graded
quality
D
maintenance
A TypeScript-based MCP server that facilitates SQL query execution and MySQL database connectivity using environment variables.
Updated 2 years ago (2025-01-06 02:06 UTC)
47 npm
MIT
SingleStore MCP Server
Databases RAG Systems Developer Tools
singlestore-labs
A
license
A
quality
D
maintenance
An implementation of the Model Context Protocol (MCP) server for SingleStore that enables natural language interaction with SingleStore databases through compatible LLM clients like Claude Desktop and Cursor.
Updated 4 months ago (2026-06-12 11:31 UTC)
21
33
MIT
PostgreSQL MCP Server
cesarvarela
A
license
B
quality
D
maintenance
A TypeScript-based Model Context Protocol server that enables AI assistants to perform secure database operations on PostgreSQL databases through structured tool interfaces.
Updated a year ago (2025-07-14 19:57 UTC)
8
10 npm
MIT
sql-mcp
Databases Developer Tools
NakiriYuuzu
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server for interacting with MSSQL and PostgreSQL databases, offering tools for schema exploration and SQL execution. It features configurable query modes for safety and supports advanced authentication methods like Windows Auth and SSL.
Updated 6 months ago (2026-04-23 00:25 UTC)
9 npm
MIT

シングルストア MCP サーバー

特徴

前提条件

インストール

Smithery経由でインストール

環境変数

必要な環境変数

オプションの環境変数

環境変数の設定

使用法

プロトコルサポート

利用可能なツール

スタンドアロン実行

SSEプロトコルの使用

SSEイベントの種類

JavaScriptクライアントの例

MCP Inspectorと併用

MCPクライアント統合

Claude Desktopへのインストール

Windsurfへのインストール

カーソルへのインストール

セキュリティに関する考慮事項

発達

プロジェクト構造

建物

テスト

トラブルシューティング

貢献

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches