Making AI-Assisted Azure Development Reliable: The Azure Schema MCP Server

Let’s talk about a problem that anyone building Azure applications with GitHub Copilot (or any AI assistant, really) will have hit at some point. You ask Copilot for a KQL query or an API call, and it obligingly spits out code that looks plausible. Unfortunately, it’s often wrong on the details—column names, field names, schema layouts. You run the query and get an error like “column ‘SeverityLevel’ not found” because the actual column is called AlertSeverity. So you end up stuck in trial-and-error mode, burning time and Azure quota while Copilot guesses its way through your data structures.

I’ve seen this play out enough times to know it’s a productivity killer. Worse, it erodes trust in AI-assisted workflows. If we want to make Copilot actually useful for real-world cloud development, we need to give it access to the ground truth: accurate schema information. That’s where the Azure Schema MCP Server comes in.

The Problem: AI Guesswork and Its Cost

AI assistants are only as good as the information they have at hand. When Copilot tries to write KQL queries or hit Microsoft Graph API endpoints, it has no idea what your workspace schemas actually look like. It guesses at table columns (“SeverityLevel”) or API fields, which leads to:

Errors in KQL queries (wrong column names)
Failed API calls
Debugging cycles that waste both time and money
Frustration with “smart” tools that don’t feel all that smart in practice

Here’s a classic example from my own logs:

User: "Query SecurityAlert for high severity alerts"
AI: "SecurityAlert | where SeverityLevel == 'High'"
Result: Error - column 'SeverityLevel' not found
Actual column name: AlertSeverity

You get the idea—this isn’t just a minor inconvenience, it’s a recurring cost.

The Solution: Model Context Protocol (MCP) Server for Schema Discovery

What I needed was a way for Copilot (or any tool using AI assistance) to stop guessing and start asking for real schema information before generating code. Enter the Azure Schema MCP Server—a background service that exposes your real workspace schemas via MCP (Model Context Protocol).

The idea is simple enough on paper:

Copilot can query the MCP server to discover actual table columns and types before writing KQL or API code.
The server introspects both Log Analytics tables and Microsoft Graph API endpoints.
It works silently in the background—no user interaction required.
It supports global installation so all your projects can benefit.

This isn’t rocket science; it’s just giving the AI a map so it stops wandering blind.

What Does Azure Schema MCP Actually Do?

Ten Practical Tools Under One Roof

The heart of this project is its suite of ten MCP tools—each one targeting a common pain point in schema discovery or code generation. Here’s a quick rundown:

get_kql_table_schema: Discovers column names and data types for any Log Analytics table.
test_kql_query: Runs test queries against your workspace and returns sample results.
list_tables: Lists every available table in your Log Analytics workspace.
get_graph_api_schema: Inspects Microsoft Graph API endpoint schemas.
refresh_schema: Clears cached schemas to force fresh discovery (handy when things change).
generate_sdk_code: Generates working TypeScript/React code for querying tables—including authentication setup.
generate_example_query: Produces example KQL queries based on operation type (select, filter, aggregation—you name it).
detect_table_workspace: Finds which workspaces contain a specific table.
find_working_query_examples: Searches your codebase for existing queries (future integration planned here).
generate_graph_sdk_code: Generates Microsoft Graph API client code snippets.

No magic tricks—just targeted tools aimed at taking guesswork out of day-to-day development.

Authentication That Fits Real Workflows

A big stumbling block with many cloud tools is authentication that assumes someone is sitting at a keyboard ready to click through browser prompts (DeviceCodeCredential). But MCP servers run quietly in the background—they can’t do interactive logins.

Azure Schema MCP uses DefaultAzureCredential instead:

Tries credentials from Azure CLI (az login) first
Falls back to environment variables, VS Code sessions, or managed identity if available
Absolutely zero user interaction required

So once you’ve done az login, every background tool on your machine is good to go.

Automated Testing That Inspires Confidence

I’ve seen too many projects declare victory after “the server starts”, only to fall over when asked real questions. Here I insisted on comprehensive testing before calling anything production-ready:

Three-Tier Test Suite Using Vitest

Unit tests (12): Offline logic checks—no Azure needed.
Integration tests (13): Real connectivity with live Azure resources.
End-to-end tests (9): Actual protocol-level checks mimicking how Copilot would use each tool.

All told:

Test Files:  5 passed (5)
Tests:      34 passed (34)
Duration:   ~11–20 seconds total
Coverage:   31% statements (integration coverage higher)
Zero flaky tests, 100% pass rate

Not exactly world domination but more than enough confidence for active use.

Real Impact For Developers—and For AI Assistants

Let me show you what this means in practice:

Before MCP Server

You ask Copilot:

“Write a KQL query to get high severity SecurityAlert records from the last 7 days”

Copilot guesses:

SecurityAlert
| where TimeGenerated > ago(7d)
| where SeverityLevel == "High"
| project TimeGenerated, AlertName, SeverityLevel

Result? Error—wrong column name guessed again.

After MCP Server

Copilot now does its homework:

Calls get_kql_table_schema({ tableName: 'SecurityAlert' })
Gets actual columns (AlertSeverity, not SeverityLevel)
Writes correct query:

SecurityAlert
| where TimeGenerated > ago(7d)
| where AlertSeverity == "High"
| project TimeGenerated, AlertName, AlertSeverity, CompromisedEntity

Runs flawlessly (mostly) first time—no debugging required.

For anyone building cloud automation or analytics pipelines with AI assistance… well let’s just say this feels like cheating compared to how things used to work.

Strategic Value Beyond Just Correct Queries

This isn’t about showing off technical tricks—it genuinely changes how fast and confidently teams can deliver cloud solutions:

Instant schema discovery means less reading documentation and more writing actual code.
Automated code generation trims boilerplate out of every new project.
Shared authentication setup means one login serves all background services—across workspaces and projects.
Two-layer caching keeps response times snappy while keeping costs under control.
And yes—the whole thing is cross-platform compatible after some hard-won lessons around Windows/Unix script differences.

It also means knowledge gained in one project gets reused everywhere else—the patterns are now documented and ready for future teams or tools.

Where To Find It—and What Comes Next

If you want to dig into details or see how these tools fit together in practice, I’d encourage you to check out the GitHub repository:

Azure Schema MCP Server

There you’ll find installation steps, configuration guides (.env setup), usage documentation—and yes—a complete test suite summary if you like seeing passing green ticks as much as I do.

Future enhancements are already being considered around JSON field analysis—think case sensitivity bugs detected before they happen—but those will land incrementally rather than all at once (lesson learned from overambitious attempts elsewhere).

Want more cloud insights? Listen to Cloudy with a Chance of Insights podcast:
Spotify | YouTube | Apple Podcasts