Powerdrill 사용자 ID와 프로젝트 API 키로 인증된 Powerdrill 데이터 세트와 상호 작용할 수 있는 도구를 제공하는 MCP(Model Context Protocol) 서버입니다.
개별적으로 또는 팀과 함께 AI 데이터 분석을 사용하려면 https://powerdrill.ai/ 로 이동하세요.
팀의 Powerdrill 사용자 ID와 프로젝트 API 키가 있으면 Powerdrill 오픈 소스 웹 클라이언트를 통해 데이터를 조작할 수 있습니다.
Node.js 버전 : https://flow.powerdrill.ai/ 또는 오픈 소스 웹 클라이언트 https://github.com/powerdrillai/powerdrill-flow 를 사용해 보세요.
Python 버전 : https://powerdrill-flow.streamlit.app/ 또는 오픈 소스 웹 클라이언트 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를 자동으로 설치하려면:
지엑스피1
# 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 파일이 없으면 생성하세요.
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클로드 데스크톱 열기
설정 > 서버 설정으로 이동하세요
다음 구성 중 하나를 사용하여 새 서버를 추가합니다.
{
"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을 다시 시작하세요
커서 열기
설정 > 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): 단일 페이지의 항목 수
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 구성이 올바른 파일 경로를 가리키는지 확인하세요.
오류 메시지가 있는지 콘솔 출력을 확인하세요.
MIT
| 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.