Powerdrill ユーザー ID とプロジェクト API キーで認証され、Powerdrill データセットと対話するためのツールを提供するモデル コンテキスト プロトコル (MCP) サーバー。
AI データ分析を個別に行う場合、またはチームで使用する場合は、 https://powerdrill.ai/にアクセスしてください。
チームの Powerdrill ユーザー ID とプロジェクト API キーをお持ちの場合は、Powerdrill オープンソース Web クライアントを介してデータを操作できます。
Node.js エディション: https://flow.powerdrill.ai/ 、またはオープン ソース Web クライアントhttps://github.com/powerdrillai/powerdrill-flowを試してみてください。
Python エディション: https://powerdrill-flow.streamlit.app/ 、またはオープン ソース Web クライアントhttps://github.com/powerdrillai/powerdrill-flow-streamlitを試してみてください。
ユーザーIDとプロジェクトAPIキーを使用してPowerdrillで認証する
Powerdrillアカウントで利用可能なデータセットを一覧表示する
特定のデータセットに関する詳細情報を取得する
自然言語の質問を含むデータセットでジョブを作成して実行する
Claude Desktop およびその他の MCP 互換クライアントとの統合
Related MCP server: HF Dataset MCP
Smithery経由で Claude Desktop 用の powerdrill-mcp を自動的にインストールするには:
npx -y @smithery/cli install @powerdrillai/powerdrill-mcp --client claude# Install globally
npm install -g @powerdrillai/powerdrill-mcp
# Or run directly with npx
npx @powerdrillai/powerdrill-mcpこのリポジトリをクローンし、依存関係をインストールします。
git clone https://github.com/yourusername/powerdrill-mcp.git
cd powerdrill-mcp
npm installグローバルにインストールされている場合:
# Start the MCP server
powerdrill-mcpnpx を使用する場合:
# Run the latest version
npx -y @powerdrillai/powerdrill-mcp@latest実行する前に、Powerdrill の資格情報を使用して環境変数を設定する必要があります。
# Set environment variables
export POWERDRILL_USER_ID="your_user_id"
export POWERDRILL_PROJECT_API_KEY="your_project_api_key"または、これらの値を含む.envファイルを作成します。
このMCPサーバーを使用するには、有効なAPI認証情報（ユーザーIDとAPIキー）を持つPowerdrillアカウントが必要です。取得方法は以下の通りです。
まだお持ちでない場合は、Powerdrill Teamアカウントに登録してください。
アカウント設定に移動します
次の項目が記載されている API セクションを探します。
ユーザーID: アカウントの一意の識別子
APIキー: APIアクセス用の認証トークン
まず、Powerdrill チームの作成方法に関する次のビデオ チュートリアルをご覧ください。
次に、次のビデオ チュートリアルに従って API 資格情報を設定します。
サーバーをセットアップする最も簡単な方法は、提供されているセットアップ スクリプトを使用することです。
# Make the script executable
chmod +x setup.sh
# Run the setup script
./setup.shこれにより、次のようになります。
依存関係をインストールする
TypeScriptコードをビルドする
.envファイルが存在しない場合は作成します
Claude Desktop と Cursor の設定ファイルを npx ベースの設定で生成します (推奨)
次に、実際の資格情報を使用して.envファイルを編集します。
POWERDRILL_USER_ID=your_actual_user_id
POWERDRILL_PROJECT_API_KEY=your_actual_project_api_keyまた、生成された構成ファイル内の資格情報も使用前に更新してください。
手動で設定する場合:
# Install dependencies
npm install
# Build the TypeScript code
npm run build
# Copy the environment example file
cp .env.example .env
# Edit the .env file with your credentialsnpm startクロードデスクトップを開く
「設定」>「サーバー設定」へ移動
次のいずれかの構成で新しいサーバーを追加します。
{
"powerdrill": {
"command": "npx",
"args": [
"-y",
"@powerdrillai/powerdrill-mcp@latest"
],
"env": {
"POWERDRILL_USER_ID": "your_actual_user_id",
"POWERDRILL_PROJECT_API_KEY": "your_actual_project_api_key"
}
}
}{
"powerdrill": {
"command": "node",
"args": ["/path/to/powerdrill-mcp/dist/index.js"],
"env": {
"POWERDRILL_USER_ID": "your_actual_user_id",
"POWERDRILL_PROJECT_API_KEY": "your_actual_project_api_key"
}
}
}設定を保存する
Claudeデスクトップを再起動します
オープンカーソル
設定 > MCPツールに移動します
次のいずれかの構成で新しい MCP ツールを追加します。
{
"powerdrill": {
"command": "npx",
"args": [
"-y",
"@powerdrillai/powerdrill-mcp@latest"
],
"env": {
"POWERDRILL_USER_ID": "your_actual_user_id",
"POWERDRILL_PROJECT_API_KEY": "your_actual_project_api_key"
}
}
}{
"powerdrill": {
"command": "node",
"args": ["/path/to/powerdrill-mcp/dist/index.js"],
"env": {
"POWERDRILL_USER_ID": "your_actual_user_id",
"POWERDRILL_PROJECT_API_KEY": "your_actual_project_api_key"
}
}
}設定を保存する
必要に応じてカーソルを再起動する
接続すると、Claude Desktop、Cursor、Cline、Windsurf などとの会話で Powerdrill ツールを使用できるようになります。
データセットの一覧: What datasets are available in my Powerdrill account?または、 Show me all my datasets
データセットの作成: Create a new dataset called "Sales Analytics"か、 Make a new dataset named "Customer Data" with description "Customer information for 2024 analysis"
ローカル ファイルからデータ ソースを作成します。 Upload the file /Users/your_name/Downloads/sales_data.csv to dataset {dataset_id}か、 Add my local file /path/to/customer_data.xlsx to my {dataset_id} dataset
データセットの概要を取得する: Tell me more about this dataset: {dataset_id}またはDescribe the structure of dataset {dataset_id}
ジョブの作成: Analyze dataset {dataset_id} with this question: "How has the trend changed over time?"または、 Run a query on {dataset_id} asking "What are the top 10 customers by revenue?"
セッションの作成: Create a new session named "Sales Analysis 2024" for my data analysisか、 Start a session called "Customer Segmentation" for analyzing market data
データ ソースの一覧表示: What data sources are available in dataset {dataset_id}?またはShow me all files in the {dataset_id} dataset
セッションの一覧表示: Show me all my current analysis sessionsか、 List my recent data analysis sessions
Powerdrill アカウントから利用可能なデータセットを一覧表示します。
パラメータ:
limit (オプション): 返されるデータセットの最大数
応答例:
{
"datasets": [
{
"id": "dataset-dasfadsgadsgas",
"name": "mydata",
"description": "my dataset"
}
]
}特定のデータセットに関する詳細な概要情報を取得します。
パラメータ:
datasetId （必須）: 概要情報を取得するデータセットのID
応答例:
{
"id": "dset-cm5axptyyxxx298",
"name": "sales_indicators_2024",
"description": "A dataset comprising 373 travel bookings with 15 attributes...",
"summary": "This dataset contains 373 travel bookings with 15 attributes...",
"exploration_questions": [
"How does the booking price trend over time based on the BookingTimestamp?",
"How does the average booking price change with respect to the TravelDate?"
],
"keywords": [
"Travel Bookings",
"Booking Trends",
"Travel Agencies"
]
}自然言語の質問でデータを分析するジョブを作成します。
パラメータ:
question （必須）: データを分析するための自然言語の質問またはプロンプト
dataset_id (必須): 分析するデータセットのID
datasource_ids (オプション): 分析するデータセット内の特定のデータソースIDの配列
session_id (オプション): 関連するジョブをグループ化するためのセッションID
stream （オプション、デフォルト：false）：結果をストリーミングするかどうか
output_language （オプション、デフォルト："AUTO"）: 出力の言語
job_mode (オプション、デフォルト: "AUTO"): ジョブモード
応答例:
{
"job_id": "job-cm3ikdeuj02zk01l1yeuirt77",
"blocks": [
{
"type": "CODE",
"content": "```python\nimport pandas as pd\n\ndef invoke(input_0: pd.DataFrame) -> pd.DataFrame:\n...",
"stage": "Analyze"
},
{
"type": "TABLE",
"url": "https://static.powerdrill.ai/tmp_datasource_cache/code_result/...",
"name": "trend_data.csv",
"expires_at": "2024-11-21T09:56:34.290544Z"
},
{
"type": "IMAGE",
"url": "https://static.powerdrill.ai/tmp_datasource_cache/code_result/...",
"name": "Trend of Deaths from Natural Disasters Over the Century",
"expires_at": "2024-11-21T09:56:34.290544Z"
},
{
"type": "MESSAGE",
"content": "Analysis of Trends in the Number of Deaths from Natural Disasters...",
"stage": "Respond"
}
]
}関連するジョブをグループ化するための新しいセッションを作成します。
パラメータ:
name （必須）: セッション名。最大128文字まで使用できます。
output_language （オプション、デフォルト："AUTO"）: 出力を生成する言語。オプション："AUTO"、"EN"、"ES"、"AR"、"PT"、"ID"、"JA"、"RU"、"HI"、"FR"、"DE"、"VI"、"TR"、"PL"、"IT"、"KO"、"ZH-CN"、"ZH-TW"
job_mode （オプション、デフォルト：「AUTO」）: セッションのジョブモード。オプションには「AUTO」、「DATA_ANALYTICS」が含まれます。
max_contextual_job_history (オプション、デフォルト: 10): 次のジョブのコンテキストとして保持される最近のジョブの最大数 (0-10)
agent_id （オプション、デフォルト: "DATA_ANALYSIS_AGENT"): エージェントのID
応答例:
{
"session_id": "session-abcdefghijklmnopqrstuvwxyz"
}特定のデータセット内のデータ ソースを一覧表示します。
パラメータ:
datasetId （必須）: データソースを一覧表示するデータセットのID
pageNumber （オプション、デフォルト：1）：リストを開始するページ番号
pageSize （オプション、デフォルト：10）：1ページあたりのアイテム数
status （オプション）：データソースをステータス（同期中、無効、同期済み（複数の場合はカンマ区切り）でフィルタリングします。
応答例:
{
"count": 3,
"total": 5,
"page": 1,
"page_size": 10,
"data_sources": [
{
"id": "dsource-a1b2c3d4e5f6g7h8i9j0",
"name": "sales_data.csv",
"type": "CSV",
"status": "synched",
"size": 1048576,
"dataset_id": "dset-cm5axptyyxxx298"
},
{
"id": "dsource-b2c3d4e5f6g7h8i9j0k1",
"name": "customer_info.xlsx",
"type": "EXCEL",
"status": "synched",
"size": 2097152,
"dataset_id": "dset-cm5axptyyxxx298"
},
{
"id": "dsource-c3d4e5f6g7h8i9j0k1l2",
"name": "market_research.pdf",
"type": "PDF",
"status": "synched",
"size": 3145728,
"dataset_id": "dset-cm5axptyyxxx298"
}
]
}Powerdrill アカウントのセッションを一覧表示します。
パラメータ:
pageNumber （オプション）：リストを開始するページ番号（デフォルト：1）
pageSize （オプション）: 1ページあたりのアイテム数（デフォルト: 10）
search （オプション）：名前でセッションを検索
応答例:
{
"count": 2,
"total": 2,
"sessions": [
{
"id": "session-123abc",
"name": "Product Analysis",
"job_count": 3,
"created_at": "2024-03-15T10:30:00Z",
"updated_at": "2024-03-15T11:45:00Z"
},
{
"id": "session-456def",
"name": "Financial Forecasting",
"job_count": 5,
"created_at": "2024-03-10T14:20:00Z",
"updated_at": "2024-03-12T09:15:00Z"
}
]
}Powerdrill アカウントに新しいデータセットを作成します。
パラメータ:
name (必須): データセット名。最大128文字まで使用できます。
description （オプション）：データセットの説明。最大128文字まで使用できます。
応答例:
{
"id": "dataset-adsdfasafdsfasdgasd",
"message": "Dataset created successfully"
}指定されたデータセットにローカル ファイルをアップロードして、新しいデータ ソースを作成します。
パラメータ:
dataset_id (必須): データソースを作成するデータセットのID
file_path (必須): アップロードするファイルへのローカルパス
file_name (オプション): ファイルのカスタム名。デフォルトは元のファイル名
chunk_size (オプション、デフォルト: 5MB): マルチパートアップロードの各チャンクのサイズ(バイト単位)
応答例:
{
"dataset_id": "dset-cm5axptyyxxx298",
"data_source": {
"id": "dsource-a1b2c3d4e5f6g7h8i9j0",
"name": "sales_data_2024.csv",
"type": "FILE",
"status": "synched",
"size": 2097152
},
"file": {
"name": "sales_data_2024.csv",
"size": 2097152,
"object_key": "uploads/user_123/sales_data_2024.csv"
}
}問題が発生した場合:
.envで環境変数が正しく設定されていることを確認してください。
npm startでサーバーが正常に起動することを確認します。
Claude Desktop の設定が正しいファイルパスを指していることを確認します
コンソール出力にエラーメッセージがないか確認します
マサチューセッツ工科大学
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The dataset name, which can be up to 128 characters in length | |
| description | No | The dataset description, which can be up to 128 characters in length |
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 |
|---|---|---|---|
| dataset_id | Yes | The ID of the dataset to create the data source in | |
| file_path | Yes | The local path to the file to upload | |
| file_name | No | Optional custom name for the file, defaults to the original filename | |
| chunk_size | No | Size of each chunk in bytes, default is 5MB |
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 |
|---|---|---|---|
| question | Yes | The natural language question or prompt to analyze the data | |
| dataset_id | Yes | The ID of the dataset to analyze | |
| datasource_ids | No | Optional array of specific data source IDs within the dataset to analyze | |
| session_id | Yes | Session ID to group related jobs | |
| stream | No | Whether to stream the results (default: false) | |
| output_language | No | The language for the output (default: AUTO) | AUTO |
| job_mode | No | The job mode (default: AUTO) | AUTO |
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 |
|---|---|---|---|
| name | Yes | The session name, which can be up to 128 characters in length | |
| output_language | No | The language in which the output is generated | AUTO |
| job_mode | No | Job mode for the session | AUTO |
| max_contextual_job_history | No | The maximum number of recent jobs retained as context for the next job | |
| agent_id | No | The ID of the agent | DATA_ANALYSIS_AGENT |
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 |
|---|---|---|---|
| datasetId | Yes | The ID of the dataset to delete |
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 |
|---|---|---|---|
| datasetId | Yes | The ID of the dataset to get overview information for |
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 |
|---|---|---|---|
| limit | No | Maximum number of datasets to return | |
| pageNumber | No | The page number to start listing (default: 1) | |
| pageSize | No | The number of items on a single page (default: 10) | |
| search | No | Search for datasets by name |
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 |
|---|---|---|---|
| datasetId | Yes | The ID of the dataset to list data sources from | |
| pageNumber | No | The page number to start listing (default: 1) | |
| pageSize | No | The number of items on a single page (default: 10) | |
| status | No | Filter data sources by status: synching, invalid, synched (comma-separated for multiple) |
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 |
|---|---|---|---|
| pageNumber | No | The page number to start listing (default: 1) | |
| pageSize | No | The number of items on a single page (default: 10) | |
| search | No | Search for sessions by name |
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.0mcp_powerdrill_create_data_source_from_local_filemcp_powerdrill_create_datasetmcp_powerdrill_delete_datasetmcp_powerdrill_list_datasets3 fields changedInput schema / properties / pageNumberAdded value: +{
+ "description": "The page number to start listing (default: 1)",
+ "type": "number"
+}Input schema / properties / pageSizeAdded value: +{
+ "description": "The number of items on a single page (default: 10)",
+ "type": "number"
+}Input schema / properties / searchAdded value: +{
+ "description": "Search for datasets by name",
+ "type": "string"
+}mcp_powerdrill_create_jobmcp_powerdrill_create_sessionmcp_powerdrill_get_dataset_overviewmcp_powerdrill_list_data_sourcesmcp_powerdrill_list_datasetsmcp_powerdrill_list_sessionsScored across 9 tools
Each tool has a clearly distinct purpose with no overlap: create/delete/list operations target specific resources (datasets, data sources, jobs, sessions) and get_dataset_overview provides unique insight. The resource-action combinations are unambiguous, making tool selection straightforward for an agent.
All tools follow a perfect verb_noun pattern with consistent snake_case: mcp_powerdrill_<verb>_<noun> or mcp_powerdrill_<verb>_<noun>_<modifier>. The naming is highly predictable, using verbs like create, delete, get, list consistently across resources.
With 9 tools, the count is well-scoped for a data processing server. It covers core operations for datasets, data sources, jobs, and sessions without being overwhelming. Each tool appears to earn its place in managing these resources.
The toolset provides strong CRUD coverage for datasets (create, delete, list, get overview) and listing for data sources and sessions, with create operations for jobs and sessions. Minor gaps include no update operations for datasets or data sources, and no delete/get for jobs or sessions, but agents can likely work around these for basic workflows.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Hosted MCP server for live public-data APIs and Skills for AI agents.