模型上下文协议 (MCP) 服务器提供与 Powerdrill 数据集交互的工具，并通过 Powerdrill 用户 ID 和项目 API 密钥进行身份验证。
请前往https://powerdrill.ai/进行个人 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-mcp如果使用 npx：
# 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 服务器，您需要一个 Powerdrill 帐户以及有效的 API 凭证（用户 ID和API 密钥）。获取方法如下：
如果您还没有注册 Powerdrill Team 帐户，请先注册
导航至您的帐户设置
查找 API 部分，您将在其中找到：
用户 ID：您帐户的唯一标识符
API 密钥：用于 API 访问的身份验证令牌
首先，观看此视频教程，了解如何创建 Powerdrill 团队：
然后，按照此视频教程设置您的 API 凭据：
设置服务器的最简单方法是使用提供的安装脚本：
# Make the script executable
chmod +x setup.sh
# Run the setup script
./setup.sh这将：
安装依赖项
构建 TypeScript 代码
如果不存在则创建一个.env文件
使用基于 npx 的配置生成 Claude Desktop 和 Cursor 的配置文件（推荐）
然后使用您的实际凭证编辑您的.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打开 Claude 桌面
转至“设置”>“服务器设置”
使用以下配置之一添加新服务器：
{
"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"
}
}
}保存配置
如果需要，重新启动 Cursor
连接后，您可以在与 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）：单页上的项目数
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 （可选）：单页上的项目数（默认值：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.