Insight-Bridge

Why I built it

I built Insight-Bridge because AI assistants can reason through analytical questions, but they need explicit tools before they can work with real data systems. I wanted Azure Data Explorer to become a safe tool surface an MCP-capable assistant could call from a local session.

I chose Azure Data Explorer as the first provider because it is schema-rich, KQL-driven, and common in telemetry and operational analytics work. I was not trying to build another dashboard. I wanted an assistant to inspect tables, understand available functions, and run bounded KQL queries without forcing me to host a separate analytics service.

What it does

Insight-Bridge runs as an MCP server over stdio and can be launched with npx insightbridge. I use that shape so compatible clients can connect to ADX/Kusto clusters, list tables, describe a table, run a query, list functions, and describe a function.

I added markdown and JSON-style output because assistant workflows do not all want the same response shape. I also added result limiting because raw query output can blow through a context window quickly.

Technical shape

The project is a TypeScript package published as insightbridge. I designed it around an InsightProvider interface, with Azure Data Explorer implemented as the first verified provider.

How I route an AI assistant through MCP stdio into Azure Data Explorer without building a separate hosted analytics service.

I kept the MCP surface intentionally small: connect, list-tables, describe-table, run-query, list-functions, and describe-function. Authentication uses Azure CLI or DefaultAzureCredential from Azure Identity. Schema caching reduces repeated metadata calls, and OpenTelemetry support exists for tracing.

I organized the repository around src/core/, src/providers/, src/output/, and src/prompts/. End-to-end test evidence points at Microsoft’s public help.kusto.windows.net/ContosoSales cluster, which keeps testing grounded in a real Kusto endpoint without implying production adoption.

The request path I care about

The important part of this project is not that it can call a database. The important part is the shape of the conversation: the assistant should ask for schema first, choose a grounded KQL query second, and only then receive a bounded result it can explain back to the user.

This is the sequence I designed around: inspect first, query second, return a result small enough for an assistant to reason over.

That is why I kept table inspection and function inspection as first-class MCP tools. If the assistant jumps straight to run-query, it is guessing. If it can call list-tables, describe-table, and describe-function first, the query has a much better chance of matching the actual Kusto surface.

Key implementation decisions

• I used MCP instead of a custom chat UI so the same tool can work inside existing assistants.
• I used stdio instead of a hosted API to keep setup local and low-friction.
• I started with Azure Data Explorer while keeping the provider boundary explicit.
• I limited query responses because assistant contexts are finite.
• I used Azure’s default credential chain instead of storing credentials in this package.

Current status

Insight-Bridge is an open-source project with a source repository and no separate live site. Public evidence shows I packaged it for npm usage and built it around TypeScript.

The current verified provider is Azure Data Explorer. Additional providers would fit the architecture, but they should be treated as future work until they exist.

What I would improve next

I would add more provider examples, expand documentation around ADX authentication and network failures, and include richer safe-query workflows for common telemetry investigations. I would also mature release automation once the public tool contracts settle.