Model Context Protocol server for Azure Data Explorer (ADX/Kusto) providing KQL query execution and database exploration for AI assistants
This server provides 5 read-only tools for Azure Data Explorer (ADX) with fastmcp. All tools are registered with names, descriptions, and input schemas. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool naming is clear and action-oriented (execute_query, list_tables, get_table_schema, etc.), following verb-noun conventions. Descriptions are present but variable in quality and lack dependency hints or recovery guidance. No input validation constraints (enums, ranges, patterns) are visible in schemas. Output structures are not explicitly documented. This represents a typical community server with good foundation but incomplete production-readiness.
Executes a Kusto Query Language (KQL) query against the configured Azure Data Explorer database and returns the results as a list of dictionaries.
Retrieves information about the configured Azure Data Explorer database, including database name, size, and other metadata.
Retrieves a sample of rows from a specified table in the Azure Data Explorer database, useful for understanding table structure and data patterns.
Retrieves the schema information for a specified table in the Azure Data Explorer database, including column names, data types, and other schema-related metadata.
Retrieves a list of all tables available in the configured Azure Data Explorer database, including their names, folders, and database associations.
Output schemas not documented. Tools return results but LLMs cannot see what fields to expect. This violates the principle that agents need to know what structure to expect for downstream planning.
No pagination support visible for list_tables. A 'list_' tool that returns all results without limit/offset will blow context windows on large databases. No pagination parameters (limit, offset, cursor) documented in schema.
Parameter constraints missing. No enums, length limits, or ranges visible for any parameter. 'sample_size' can be unbounded integer (agent could request millions of rows). 'table_name' has no pattern validation. This invites invalid queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error handling guidance absent. Tools make external queries (KQL execution, schema retrieval) which can fail in many ways (auth, syntax, timeout, resource limits). No error classification or recovery hints documented. LLM cannot determine if error is retryable, user-fixable, or fatal.
No parameter descriptions for critical fields. While schemas show 'query' and 'sample_size' parameters, descriptions are minimal. 'query' says 'KQL query string to execute' but does not explain KQL syntax, common patterns, or constraints. 'sample_size' lacks guidance on recommended values.
Tool descriptions lack dependency/prerequisite hints. E.g., execute_query does not mention 'Call list_tables first to see available tables' or 'Call get_table_schema to understand column types before querying'. This forces LLMs to discover workflows without guidance.
Result limits not enforced or documented. execute_query and get_table_sample can return unbounded results. For execute_query, a KQL query could return millions of rows, exhausting context. No guidance on result capping or truncation.