Provides read-only access to Apache Druid databases, enabling SQL query execution, table exploration, dashboard and data cube operations through the Imly Cloud API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@imply-druid-mcp list all tables in my Druid project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only MCP (Model Context Protocol) server for Imply Cloud/Druid databases. Query and explore your Druid data through Claude and other AI assistants.
SQL Query Execution
Synchronous query execution
Asynchronous query execution (for large datasets)
Query Management
Check query status
Retrieve query results
Cancel running queries
Table Operations
List all tables in project
Get table schema details
Dashboard Operations
List all dashboards
Get dashboard details
Data Cube Operations
List all data cubes
Get data cube details
Execute Pivot SQL queries
Data Ingestion
Table/Schema Creation or Modification
User/Permission Management
Supervisor Management
Related MCP server: starrocks-mcp
Tool | Description |
| Execute a SQL query synchronously and return results immediately |
| Execute a SQL query asynchronously for large datasets. Returns a query ID |
| Retrieve results from an async query using query ID |
| Check the execution status of an async query |
| Cancel a running async query |
Tool | Description |
| List all tables (datasources) in the Druid project |
| Get detailed schema information for a specific table |
Tool | Description |
| List all dashboards in the Imply project |
| Get detailed information about a specific dashboard |
Tool | Description |
| List all data cubes in the Imply project |
| Get detailed data cube information including dimensions and measures |
| Execute Pivot SQL query against a data cube |
This MCP server maps to the Imply Polaris API:
MCP Tool | Imply API Endpoint |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
uvx imply-druid-mcppip install imply-druid-mcp
imply-druid-mcppipx install imply-druid-mcp
imply-druid-mcpEnvironment Variable | Required | Default | Description |
| Yes | - | Imply Cloud organization name |
| Yes | - | Region (e.g., |
| Yes | - | Cloud provider: |
| Yes | - | Imply project ID |
| Yes* | - | Imply API key |
| Yes* | - | OAuth access token (alternative) |
| No |
| Logging level |
| No |
| Default query timeout (ms) |
| No |
| Maximum SQL query length |
*Either IMPLY_API_KEY or IMPLY_ACCESS_TOKEN is required.
Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"imply-druid": {
"command": "uvx",
"args": ["imply-druid-mcp"],
"env": {
"IMPLY_ORGANIZATION": "your-org",
"IMPLY_REGION": "us-east-1",
"IMPLY_CLOUD_PROVIDER": "aws",
"IMPLY_PROJECT_ID": "your-project-id",
"IMPLY_API_KEY": "your-api-key"
}
}
}
}User: Show me all tables in my Druid project
Claude: [Uses list_tables]
- wikipedia (datasource)
- events (datasource)
- metrics (datasource)User: Query the top 10 records from wikipedia table
Claude: [Uses execute_sql_query with "SELECT * FROM wikipedia LIMIT 10"]
[Results displayed]User: Show me all data cubes
Claude: [Uses list_data_cubes]
- sales_cube: Sales Analytics (source: sales_table)
- events_cube: Events Tracking (source: events)User: Query the sales data cube for top cities
Claude: [Uses query_data_cube with Pivot SQL syntax]
SELECT "DIM:city" AS "City", MEASURE_BY_ID('total_sales') AS "Sales"
FROM "datacube"."sales_cube"
ORDER BY 2 DESC
LIMIT 10git clone https://github.com/yeongbin-hwang/imply-druid-mcp.git
cd imply-druid-mcp
pip install -e ".[dev]"MIT License - see LICENSE for details.
Cancel a running query.
| Name | Required | Description | Default |
|---|---|---|---|
| query_id | Yes | Query ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose side effects, requirements (e.g., query must be running), error handling, or return behavior.
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?
A single concise sentence that is front-loaded with the action verb, but lacks context that could be added without bloating.
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?
For a cancellation command with no output schema and minimal description, important details like expected input format or prerequisites are missing.
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?
Schema coverage is 100% with a clear parameter description; the tool description adds no additional semantic value beyond the schema.
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?
The description uses a specific verb 'Cancel' and resource 'a running query', clearly distinguishing it from sibling tools like execute_async_query or get_query_status.
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?
No explicit guidance on when to use this tool versus alternatives like get_query_status to check completion, though the purpose is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an asynchronous SQL query for large datasets or long-running queries. Returns a query ID.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute | |
| timeout_ms | No | Query timeout in milliseconds (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is asynchronous and returns a query ID, but with no annotations, it fails to explain that results must be retrieved later (e.g., via get_query_results), potential failure modes, or that the query is queued. This is a significant omission for an async tool.
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?
Two sentences with no wasted words: the first states the core purpose and context, the second specifies the return value. Perfectly front-loaded and concise.
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?
The tool has asynchronous behavior requiring subsequent polling to retrieve results, but the description omits this crucial workflow. It also lacks any explanation of error handling or timeouts beyond the parameter. Given the complexity and no output schema, the description is incomplete.
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?
Schema coverage is 100% and the schema already describes both parameters adequately. The description adds no additional meaning beyond restating the schema descriptions, so baseline score of 3 is appropriate.
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?
The description clearly states the action ('execute'), the resource ('asynchronous SQL query'), and the context ('for large datasets or long-running queries'), and distinguishes from siblings like execute_sql_query (presumably synchronous) by specifying it returns a query ID.
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?
The description indicates when to use this tool ('for large datasets or long-running queries'), implying an alternative is the synchronous query tool. While it doesn't explicitly list alternatives or when-not-to-use, the context of sibling tools provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query against Druid and return results. Use this for synchronous queries on small datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute | |
| timeout_ms | No | Query timeout in milliseconds (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions synchronous execution but fails to disclose important traits like whether the query can modify data (SQL can be DDL/DML), error behavior, rate limits, or result size limits. This is a significant gap for a potentially mutation-capable tool.
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?
Two sentences, no redundancy, front-loaded with key information. Every sentence earns its place without waste.
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?
Given 2 parameters, no output schema, and sibling tools, the description is mostly sufficient. However, lacks details on query restrictions (e.g., read-only recommended) or security considerations. For a simple tool, it's adequate but could be more complete.
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?
Schema description coverage is 100% (both parameters have descriptions in schema). The description adds context about synchronous and small datasets but does not provide additional parameter-specific meaning beyond the schema. Baseline 3 applies.
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?
Description clearly states verb (execute), resource (SQL query against Druid), and action (return results). It distinguishes from siblings by specifying synchronous queries on small datasets, contrasting with execute_async_query.
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?
Explicitly states 'Use this for synchronous queries on small datasets', providing clear context for when to use. Implies not for large datasets or async needs, but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific dashboard including its configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| dashboard_id | Yes | ID of the dashboard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It mentions 'Get' implying read-only, but does not disclose return format, authentication needs, rate limits, or that it only retrieves one dashboard at a time.
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?
The description is a single concise sentence front-loading the purpose. However, it lacks additional structural elements like usage notes, which would improve clarity without harming conciseness.
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?
Given the simple tool (one param, no output schema), the description adequately explains the core action. However, completeness is hampered by missing usage guidance and behavioral details, especially with many sibling tools.
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?
Schema description coverage is 100%, with 'dashboard_id' described. The description adds no extra meaning beyond the schema, meeting the baseline for high schema coverage.
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?
The description clearly states the tool retrieves detailed information for a specific dashboard, including its configuration. It distinguishes from the sibling 'list_dashboards' which lists dashboards without details.
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?
The description does not explicitly state when to use this tool versus alternatives like 'list_dashboards' for summaries. Usage is implied (need detailed info), but no exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific data cube including dimensions and measures.
| Name | Required | Description | Default |
|---|---|---|---|
| cube_id | Yes | ID of the data cube (from list_data_cubes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes a read operation ('Get'), which implies non-destructive behavior, but does not explicitly state this or other aspects like error handling or restrictions.
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?
The description is a single sentence with no unnecessary words, front-loading the key action and resource.
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?
Given no output schema, the description only mentions 'dimensions and measures' but does not detail the return structure or other fields. While sibling tools provide context, the description is minimally adequate for a simple retrieval tool.
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?
Schema coverage is 100% with one parameter. The description adds context that cube_id comes from list_data_cubes, which provides meaningful information beyond the schema's basic 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?
The description clearly states 'Get detailed information about a specific data cube', using a specific verb and resource. It distinguishes from sibling tools like list_data_cubes (which lists cubes) and query_data_cube (which queries data).
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?
The description implies usage by requiring a cube_id from list_data_cubes, but it does not explicitly state when to use this tool versus alternatives like get_table_schema or query_data_cube. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get results from an asynchronous query using its query ID.
| Name | Required | Description | Default |
|---|---|---|---|
| query_id | Yes | Query ID from execute_async_query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as that the query must have completed, potential pagination, data retention limits, or error states. This is insufficient for safe invocation.
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?
The description is a single, concise sentence with no wasted words. However, its brevity sacrifices useful information, so not a 5.
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?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description should cover prerequisites, potential errors, and return expectations. It does not, making it incomplete for effective use.
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?
The input schema has 100% coverage, describing the parameter as 'Query ID from execute_async_query'. The description adds no additional meaning beyond that, so baseline of 3 is appropriate.
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?
The description clearly states the verb 'Get results' and the resource 'asynchronous query', and specifies using the query ID. This distinguishes it from sibling tools like get_query_status or cancel_query.
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?
No guidance on when to use this tool versus alternatives like get_query_status (for checking progress) or execute_async_query (for starting). The description implies it follows an async query but does not explicitly state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an asynchronous query.
| Name | Required | Description | Default |
|---|---|---|---|
| query_id | Yes | Query ID to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose expected return values, status states (e.g., pending, completed, failed), or whether the tool is read-only. The minimal description does not provide sufficient behavioral context.
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?
The description is a single, concise sentence without unnecessary words. However, it lacks any structure or additional elaboration that could improve usability.
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?
Despite low complexity (one parameter, no output schema), the description is insufficient. It does not explain what 'status' means, possible values, or how to interpret the response, leaving an agent uninformed.
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?
Schema description coverage is 100% with a clear description for the sole parameter. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline.
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?
The description clearly states the tool checks the status of an asynchronous query, which is a specific verb and resource. However, it does not distinguish it from siblings like 'get_query_results', but the name and context imply a status check rather than result retrieval.
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?
No guidance is provided on when to use this tool versus alternatives like 'execute_async_query' or 'cancel_query'. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema information for a specific table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the basic action without disclosing side effects, auth needs, or return behavior, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could be more informative without becoming verbose.
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?
The tool has one parameter and no output schema, so the description must compensate. It fails to mention the return format, possible errors, or that the table must exist, leaving the agent underspecified.
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?
Schema coverage is 100% (the only parameter 'table_name' is described in the schema). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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?
The description clearly states the tool gets schema information for a specific table, using a specific verb and resource. However, it does not detail what 'schema information' includes (e.g., columns, data types), missing some precision.
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?
No guidance is provided on when to use this tool versus siblings like list_tables or other query tools. The agent has no context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dashboards in the Imply project with their metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists dashboards with metadata but does not disclose any behavioral traits such as side effects, rate limits, or read-only nature.
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?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It clearly specifies what the tool does without needing additional elaboration.
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?
The tool has no parameters, so schema coverage is 100%. The description adds context about metadata inclusion, which is helpful. Baseline is 4 for 0 parameters.
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?
The description clearly states the verb ('list'), resource ('dashboards'), and scope ('all', 'with their metadata'). It distinguishes from sibling tool 'get_dashboard' which likely retrieves a single dashboard.
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?
The description implies the tool is for listing all dashboards, but does not provide explicit guidance on when to use it versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data cubes in the Imply project with their metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'lists all data cubes' and returns 'metadata', but does not mention whether it is read-only, required permissions, rate limits, or any side effects. The agent must assume it is safe, but that is not explicitly stated.
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?
The description is a single sentence of 12 words, front-loading the core purpose. It contains no redundancy or unnecessary information, achieving maximum conciseness.
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?
Given no parameters and no output schema, the description is minimal but adequate for a simple listing tool. However, it does not specify what metadata fields are returned, whether pagination exists, or any default behavior, which could be useful for an agent.
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?
With zero parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter details (none needed) but clarifies that the tool returns metadata, which is sufficient.
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?
The description uses a specific verb ('List') and resource ('data cubes') with scope ('in the Imply project') and output ('with their metadata'). It clearly distinguishes from related tools like 'get_data_cube' (singular) and 'list_dashboards' (different resource).
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_data_cube' for a specific cube). It does not mention exclusions, prerequisites, or context, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in the Druid project with their metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only states 'List all tables with their metadata', but does not disclose whether it is read-only, requires authentication, or any side effects. Minimal behavioral context.
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?
Single sentence with verb-first structure. No wasted words; front-loaded and efficient.
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?
Given no output schema, the description leaves 'metadata' ambiguous. It does not specify what metadata is returned (e.g., names, sizes, creation dates). For a listing tool, this is incomplete without further detail.
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?
Input schema has no parameters, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline score of 4 for zero parameters is appropriate.
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?
Description clearly states verb 'list', resource 'tables', scope 'in the Druid project', and mentions 'metadata'. It distinguishes from siblings like 'get_table_schema' (specific table) and 'list_dashboards' (different resource).
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?
Implied usage for listing tables, but no explicit guidance on when to use this vs alternatives like 'get_table_schema' or 'execute_sql_query'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SQL query against a data cube (Pivot). Use 'source' from list_data_cubes. Syntax: FROM "datacube"."SOURCE", "DIM:dimension_name", MEASURE_BY_ID('measure_id')
| Name | Required | Description | Default |
|---|---|---|---|
| query_string | Yes | SQL query with data cube syntax | |
| exact_results_only | No | Use exact results for TopN/COUNT DISTINCT (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the data cube SQL syntax and effect of 'exact_results_only' parameter, but does not mention read-only nature, rate limits, or other behavioral traits. Adequate but not comprehensive.
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?
The description is concise (one sentence plus syntax hint), front-loaded with purpose, and contains no redundant information. Every sentence adds value.
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?
Given the complexity of data cube SQL queries, the description fairly complete with syntax and parameter notes. Lacks details on error handling or output, but no output schema exists. Context of using list_data_cubes for 'source' is helpful.
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?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra meaning beyond the schema, only providing a syntax example. Baseline 3 is appropriate given high coverage.
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?
The description clearly states the tool's purpose: 'Execute SQL query against a data cube (Pivot).' It specifies the verb and resource, and provides syntax hints. Distinguishes from sibling tools like execute_sql_query which target general SQL tables.
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?
The description gives context by mentioning 'source from list_data_cubes' and syntax, but does not explicitly state when to use this tool versus siblings like execute_sql_query or cancel_query. Some implicit guidance exists but could be more explicit.
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.
v0.2.0cancel_queryexecute_async_queryexecute_sql_queryget_dashboardget_data_cubeget_query_resultsget_query_statusget_table_schemalist_dashboardslist_data_cubeslist_tablesquery_data_cubeScored across 12 tools
Each tool has a clear, distinct purpose. Sync and async queries are separated, and the data cube query uses a different syntax. No two tools appear to do the same thing.
All tool names follow a consistent verb_noun pattern (e.g., list_*, get_*, execute_*, cancel_*, query_*). No mixing of conventions or vague verbs.
12 tools appropriately cover the core functionalities of querying Druid, managing dashboards, data cubes, and tables. Not too few nor too many.
The tool set provides full lifecycle coverage for querying (sync, async, cancellation, status, results) and browsing resources (list, get details, schema). No obvious gaps for a query-oriented server.
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
