Un servidor de Protocolo de contexto de modelo (MCP) que proporciona herramientas para interactuar con conjuntos de datos de Powerdrill, autenticado con el ID de usuario de Powerdrill y la clave de API del proyecto.
Vaya a https://powerdrill.ai/ para realizar análisis de datos de IA de forma individual o para usarlos con su equipo.
Si tiene el ID de usuario de Powerdrill y la clave API del proyecto de su equipo, puede manipular los datos a través de los clientes web de código abierto de Powerdrill:
Edición Node.js : https://flow.powerdrill.ai/ , o juega con el cliente web de código abierto https://github.com/powerdrillai/powerdrill-flow .
Edición Python : https://powerdrill-flow.streamlit.app/ , o juegue con el cliente web de código abierto https://github.com/powerdrillai/powerdrill-flow-streamlit .
Autenticarse con Powerdrill usando el ID de usuario y la clave API del proyecto
Enumere los conjuntos de datos disponibles en su cuenta de Powerdrill
Obtenga información detallada sobre conjuntos de datos específicos
Crear y ejecutar trabajos en conjuntos de datos con preguntas en lenguaje natural
Integración con Claude Desktop y otros clientes compatibles con MCP
Related MCP server: HF Dataset MCP
Para instalar powerdrill-mcp para Claude Desktop automáticamente a través de Smithery :
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-mcpClonar este repositorio e instalar las dependencias:
git clone https://github.com/yourusername/powerdrill-mcp.git
cd powerdrill-mcp
npm installSi se instala globalmente:
# Start the MCP server
powerdrill-mcpSi usa npx:
# Run the latest version
npx -y @powerdrillai/powerdrill-mcp@latestNecesitará configurar las variables de entorno con sus credenciales de Powerdrill antes de ejecutar:
# Set environment variables
export POWERDRILL_USER_ID="your_user_id"
export POWERDRILL_PROJECT_API_KEY="your_project_api_key"O cree un archivo .env con estos valores.
Para usar este servidor MCP, necesitará una cuenta de Powerdrill con credenciales de API válidas ( ID de usuario y clave de API ). Para obtenerlas, siga estos pasos:
Regístrese para obtener una cuenta del equipo Powerdrill si aún no lo ha hecho
Vaya a la configuración de su cuenta
Busca la sección API donde encontrarás:
ID de usuario: un identificador único para su cuenta
Clave API: su token de autenticación para acceder a la API
Primero, mira este video tutorial sobre cómo crear tu equipo Powerdrill:
Luego, sigue este video tutorial para configurar tus credenciales de API:
La forma más sencilla de configurar el servidor es utilizar el script de configuración proporcionado:
# Make the script executable
chmod +x setup.sh
# Run the setup script
./setup.shEsto hará lo siguiente:
Instalar dependencias
Construir el código TypeScript
Crea un archivo .env si no existe
Generar archivos de configuración para Claude Desktop y Cursor con la configuración basada en npx (recomendado)
Luego edita tu archivo .env con tus credenciales reales:
POWERDRILL_USER_ID=your_actual_user_id
POWERDRILL_PROJECT_API_KEY=your_actual_project_api_keyTambién actualice las credenciales en los archivos de configuración generados antes de usarlos.
Si prefiere configurarlo manualmente:
# 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 startAbra Claude Desktop
Vaya a Configuración > Configuración del servidor
Agregue un nuevo servidor con una de las siguientes configuraciones:
{
"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"
}
}
}Guardar la configuración
Reiniciar Claude Desktop
Cursor abierto
Vaya a Configuración > Herramientas MCP
Agregue una nueva herramienta MCP con una de las siguientes configuraciones:
{
"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"
}
}
}Guardar la configuración
Reiniciar el cursor si es necesario
Una vez conectado, podrás utilizar las herramientas de Powerdrill en tus conversaciones con Claude Desktop, Cursor, Cline, Windsurf, etc.:
Lista de conjuntos de datos: What datasets are available in my Powerdrill account? o Show me all my datasets
Crear un conjunto de datos: Create a new dataset called "Sales Analytics" o Make a new dataset named "Customer Data" with description "Customer information for 2024 analysis"
Crear una fuente de datos desde un archivo local: Upload the file /Users/your_name/Downloads/sales_data.csv to dataset {dataset_id} o Add my local file /path/to/customer_data.xlsx to my {dataset_id} dataset
Obtener descripción general del conjunto de datos: Tell me more about this dataset: {dataset_id} o Describe the structure of dataset {dataset_id}
Crear un trabajo: Analyze dataset {dataset_id} with this question: "How has the trend changed over time?" o Run a query on {dataset_id} asking "What are the top 10 customers by revenue?"
Crear una sesión: Create a new session named "Sales Analysis 2024" for my data analysis o Start a session called "Customer Segmentation" for analyzing market data
Lista de fuentes de datos: What data sources are available in dataset {dataset_id}? o Show me all files in the {dataset_id} dataset
Listar sesiones: Show me all my current analysis sessions o List my recent data analysis sessions
Enumera los conjuntos de datos disponibles en su cuenta de Powerdrill.
Parámetros:
limit (opcional): número máximo de conjuntos de datos a devolver
Ejemplo de respuesta:
{
"datasets": [
{
"id": "dataset-dasfadsgadsgas",
"name": "mydata",
"description": "my dataset"
}
]
}Obtiene información general detallada sobre un conjunto de datos específico.
Parámetros:
datasetId (obligatorio): El ID del conjunto de datos para el cual se obtendrá información general
Ejemplo de respuesta:
{
"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"
]
}Crea un trabajo para analizar datos con preguntas en lenguaje natural.
Parámetros:
question (obligatoria): La pregunta o indicación en lenguaje natural para analizar los datos.
dataset_id (obligatorio): El ID del conjunto de datos a analizar
datasource_ids (opcional): Matriz de identificaciones de fuentes de datos específicas dentro del conjunto de datos para analizar
session_id (opcional): ID de sesión para agrupar trabajos relacionados
stream (opcional, valor predeterminado: falso): si se deben transmitir los resultados
output_language (opcional, predeterminado: "AUTO"): El idioma de salida
job_mode (opcional, predeterminado: "AUTO"): El modo de trabajo
Ejemplo de respuesta:
{
"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"
}
]
}Crea una nueva sesión para agrupar trabajos relacionados.
Parámetros:
name (obligatorio): el nombre de la sesión, que puede tener hasta 128 caracteres de longitud
output_language (opcional, predeterminado: "AUTO"): El idioma en el que se genera la salida. Las opciones incluyen: "AUTO", "EN", "ES", "AR", "PT", "ID", "JA", "RU", "HI", "FR", "DE", "VI", "TR", "PL", "IT", "KO", "ZH-CN", "ZH-TW"
job_mode (opcional, predeterminado: "AUTO"): Modo de trabajo de la sesión. Las opciones incluyen: "AUTO" y "DATA_ANALYTICS".
max_contextual_job_history (opcional, predeterminado: 10): la cantidad máxima de trabajos recientes que se conservan como contexto para el próximo trabajo (0-10)
agent_id (opcional, predeterminado: "DATA_ANALYSIS_AGENT"): El ID del agente
Ejemplo de respuesta:
{
"session_id": "session-abcdefghijklmnopqrstuvwxyz"
}Enumera las fuentes de datos en un conjunto de datos específico.
Parámetros:
datasetId (obligatorio): El ID del conjunto de datos del que se listarán las fuentes de datos
pageNumber (opcional, predeterminado: 1): el número de página para comenzar a enumerar
pageSize (opcional, predeterminado: 10): la cantidad de elementos en una sola página
status (opcional): Filtrar fuentes de datos por estado: sincronizando, no válido, sincronizado (separado por comas para varios)
Ejemplo de respuesta:
{
"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"
}
]
}Enumera las sesiones de su cuenta de Powerdrill.
Parámetros:
pageNumber (opcional): el número de página para comenzar a enumerar (predeterminado: 1)
pageSize (opcional): la cantidad de elementos en una sola página (predeterminado: 10)
search (opcional): buscar sesiones por nombre
Ejemplo de respuesta:
{
"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"
}
]
}Crea un nuevo conjunto de datos en su cuenta de Powerdrill.
Parámetros:
name (obligatorio): el nombre del conjunto de datos, que puede tener hasta 128 caracteres de longitud
description (opcional): La descripción del conjunto de datos, que puede tener hasta 128 caracteres de longitud
Ejemplo de respuesta:
{
"id": "dataset-adsdfasafdsfasdgasd",
"message": "Dataset created successfully"
}Crea una nueva fuente de datos cargando un archivo local en un conjunto de datos especificado.
Parámetros:
dataset_id (obligatorio): El ID del conjunto de datos en el que se creará la fuente de datos
file_path (obligatorio): La ruta local al archivo a cargar
file_name (opcional): nombre personalizado para el archivo, el valor predeterminado es el nombre del archivo original
chunk_size (opcional, predeterminado: 5 MB): tamaño de cada fragmento en bytes para carga multiparte
Ejemplo de respuesta:
{
"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"
}
}Si encuentra problemas:
Asegúrese de que sus variables de entorno estén configuradas correctamente en .env
Compruebe que el servidor se inicia correctamente con npm start
Verifique que la configuración de Claude Desktop apunte a las rutas de archivo correctas
Verifique la salida de la consola para ver si hay mensajes de error
Instituto Tecnológico de Massachusetts (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.