Kusto Query Language is a parser and analyzer, not a query engine

A grammar with a front end in two languages

The single most important thing to know about this repository is what it is not. It is not a Kusto client and it does not execute queries against Azure Data Explorer or any other backend. What it is, according to the README, is a parser and a semantic analyzer in C# together with a translator project that generates the same libraries in JavaScript. That is a narrower and less glamorous product than a query engine, and it is the piece that everything else in the Kusto ecosystem is built on top of. A tool that offers syntax highlighting, completion, formatting, linting or query analysis needs a machine-readable description of the language, and the same description has to exist in whichever language the tool is written in. A C#-only implementation would force JavaScript editors to go through a server, so the translator project exists to generate the equivalent libraries on that side. The README points to usage examples in src/Kusto.Language/readme.md for how the API is meant to be consumed, which is the first file to read if you are deciding whether this suits your integration.

The repository layout separates grammar from implementation

The top level of the repository is deliberately small. It holds .gitattributes, .github/, .gitignore, CODE_OF_CONDUCT.md, LICENSE, README.md, SECURITY.md, a grammar/ directory and a src/ directory. That split between grammar/ and src/ is the architecture in miniature. The grammar is the language definition, the formal description of what a valid KQL expression looks like, and src/ holds the C# implementation and, by inference from the translator project, the code that projects that grammar into other languages. Keeping the definition in one place and the code that consumes it elsewhere is the arrangement that makes multi-target output practical, because the grammar is the thing that has to stay in agreement across languages. There is also the ordinary governance layer, a CODE_OF_CONDUCT.md and a SECURITY.md, which for a Microsoft-maintained repository means the disclosure process for vulnerabilities in the parser itself is documented rather than improvised. Since the repository has no GitHub releases and its default branch is master, the commit history rather than a release page is where you would look to see how the language has moved.

The language the parser targets is built for telemetry

The README describes KQL as a language for querying structured, semi-structured and unstructured data, and the design assumptions are stated plainly. It assumes a relational data model of tables and columns with a minimal set of data types. That minimalism is the design decision that makes the language readable. The README makes a specific claim about that, that the language is very expressive, easy to read and understand the query intent, and optimized for authoring experiences. In practice it means the type system is small enough that a reader holds it in their head, and the shapes of a query are predictable across data sources. The second half of the README describes what the language is optimised for, and the list is a good indication of the workload. It is optimal for querying telemetry, metrics and logs, with deep support for text search and parsing, time-series operators and functions, analytics and aggregation, geospatial work, vector similarity searches, and many other language constructs. Vector similarity search and geospatial operators sitting alongside time-series functions tells you this is a language for observability workloads, where a single query window may combine log lines, metric series and a map.

Getting the parser as a NuGet package

The distribution story is short and there is no build step in the README to follow, which is the correct approach for a library like this. The source code is also available as a package on nuget.org, published under the name Microsoft.Azure.Kusto.Language. The identifier is what you would put in your project file or on the command line, so the shape of the reference is:

Microsoft.Azure.Kusto.Language

There is no CLI to invoke here, and that is worth being explicit about. This is a class library, not a command line tool, so there is nothing to install globally and nothing to run against a query file. If you want a working end-to-end example, the README's advice is to look at the usage examples in src/Kusto.Language/readme.md, and for the language itself, the documentation is on Microsoft Learn under the Kusto Query Language overview, with the Azure Data Explorer view selected. The distinction between the two documents matters when you are new to the project, because the Learn page explains what KQL can express and this repository explains how the implementation is packaged. The repository carries no GitHub releases, so if you need to trace which version introduced a given behaviour, the commit history on master is the record.

If you are building a query editor, Monaco already has a plugin

There is a shortcut for the most common consumer of this repository, and the README offers it explicitly. If you need to provide a query authoring experience for the language, the recommendation is to consider using the Kusto language plugin for the Monaco Editor, maintained in the Azure organisation. That is a meaningful piece of advice, because authoring experience is the problem this parser exists to solve, and an editor plugin already solves the syntax highlighting, the completion and the formatting. What the plugin does not give you is a way to apply your own rules, and that is where the parser earns its place. A linter with company specific rules, a formatter with an agreed style, a migration tool that rewrites queries, or a tool that extracts table references from a query all need the grammar and the semantic analyzer rather than a colour scheme. The trade-off in going that route is that you own the integration work, the diagnostics wiring and the editor plumbing, and the plugin would have given you a working baseline for none of that cost.

Support routes are split by service and by library

The README separates help for the language from help for this library, which is a sensible division and worth following rather than guessing where to ask. For language questions, the route is Stack Overflow, and the advice is to start posts with KQL, since the tag is how the Kusto team members who monitor it find the question. Feature requests and changes go to User Voice, and the Azure Data Explorer web interface has a feedback button in the top right, near the settings, for reporting problems with the service itself. Problems with the Azure service as a hosted product belong to Azure Support, through the standard supportability request path. Problems with this library, meaning the parser, the analyzer and the translator, belong in the GitHub issues or discussions for this repository. The README also points at the Microsoft Open Source Code of Conduct with its FAQ and a contact address, and the repository has adopted that code of conduct as a project. This is a well-maintained help topology, and the last push on 2026-10-20 shows the code itself is still being worked on.

Editorial conclusion

Adopt this repository when you are writing an editor, linter, formatter or custom analysis tool that has to understand KQL rather than merely send it to a server, and when you want the same grammar available from C# and from JavaScript. Do not adopt it if you need a client for Azure Data Explorer, because the repository contains no client and no execution engine, and the query documentation lives on learn.microsoft.com rather than here. Verify first that the version of the NuGet package matches the KQL feature set your users are writing, since the repository carries no GitHub releases to pin against, and read the usage examples in src/Kusto.Language/readme.md before designing your own integration.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. microsoft/Kusto-Query-Language on GitHub
4. README