From Error Log to Closed Ticket, Without Leaving Your Terminal

You describe the problem. The assistant pulls the context from what you already have, drafts the ticket, files it, tracks the replies, and closes it out, and it asks before it does anything irreversible. No portal tabs. No re-typing the resource ID Azure already knows.

See a quick demo or jump straight to the code: https://github.com/Azure-Samples/azure_support_ticket_mcp

The common challenge

Every team running on Azure eventually opens a support ticket. Here is the catch: the investigation happens in your terminal or editor, but the ticket frequently happens in a browser. Bridging those two worlds is pure overhead, and you pay it at the worst possible moment, mid-incident.

Opening one ticket means stepping through:

• Confirm the tenant, pick the subscription.
• Find the right support service among hundreds.
• Drill down a per-service problem-classification tree.
• Set severity, enter contact details, write up the issue.
• Re-type the resource ID and error you were just looking at.

And filing is only the start. A support ticket is a conversation: replies to read, follow-up questions to answer, logs to attach, a status to flip when it resolves. Each one is another trip to the portal, another context switch out of the place you actually work.

The value proposition is simple: collapse that entire lifecycle into the place you already work, in plain language, in seconds. Stay in flow. Let the assistant do the mechanical parts and keep the decisions for yourself.

How the lifecycle works

Every ticket follows the same path, and the same safety gate sits in the middle of it. Opening a ticket runs left to right; once it exists, the same conversational interface carries it through the rest of its life.

The second lane is the part most ticket tools skip. Once a ticket is open, support is a two-way conversation, and the server handles that side too: read the full thread of customer and Microsoft replies, get a local summary of where things stand, reply to the support engineer, and attach logs, traces, or screenshots, all without returning to the portal.

That preview-then-confirm gate is the whole trust model. The first call returns exactly what is about to happen; the second call carries it out, and only if nothing changed in between. Reading, summarizing, and triaging are instant, with nothing to approve; creating, replying, attaching, and closing always pause for your yes.

The Solution

The Azure Support Ticket MCP is a Model Context Protocol (MCP) server that exposes the Azure support ticket lifecycle as a set of conversational tools. Three things make it more than a thin API wrapper:

• It infers context. Give it a resource ID or a portal URL and it reads the subscription, resource group, and service from it, then ranks the right problem classification from your description instead of making you walk the tree.
• It is local-first. The Azure support catalog, the services and their problem-classification trees, is cached on disk, so the common path is instant and works even on a flaky connection.
• It is safe by design. Every action that changes something is preview-then-confirm: nothing reaches Azure until you approve the exact payload.

Getting started

1. Install the binary (a single command, the repo README has the current one-liner).
2. Register it with your MCP-capable assistant.
3. Start describing problems in plain language.

The fastest way in is to pipe a failure straight from your terminal into a ticket:

From that raw output, the server extracts the resource IDs, error codes, correlation IDs, and HTTP status, takes a first guess at severity, and scrubs obvious secrets on a best-effort basis. You then review and approve the full draft before any ticket is created, so anything the scrub might miss is still in front of you to catch first. Prefer plain English? That works too:

copilot -i "open a ticket — my AKS cluster prod-aks can’t scale out"

In short

• The problem: filing and managing Azure support tickets pulls you out of your flow into a multi-step portal process, again and again, over the life of each ticket.
• MCP: an open standard that lets AI assistants take real, permissioned actions through tools, not just answer questions.
• The solution: an open-source MCP server that runs the whole ticket lifecycle from your terminal, context-aware, local-first, and gated by preview-then-confirm.