Read this case study on its own page
Challenge
Running a small business on Azure, Microsoft 365, Azure DevOps and two ad platforms means constant context-switching between portals for low-value questions: what's the pipeline doing, what's in that mailbox, what did that keyword cost. Each answer is easy; getting to it isn't.
Approach
An internal Model Context Protocol server that gives an AI assistant structured, authenticated, purpose-scoped access to those systems — repositories, pipelines, work items and pull requests; mail, calendar and files; Azure resources and metrics; advertising and search-performance data. Every tool that can change something follows a dry-run/confirm protocol: the change is previewed and must be explicitly confirmed before it runs. Errors come back with their status and a remediation hint, transient failures retry automatically, and read-only tools return compact, structured data designed to be reasoned about. When a capability is missing, the assistant can raise a work item for it from inside the conversation — the server's own backlog is fed by its use.
Outcome
- Operational questions answered in seconds instead of a tour of portals
- Pull requests created, reviewed, voted on and completed without leaving the conversation
- No accidental writes — every mutation previewed and confirmed
- Used daily across development, infrastructure and operations work; this website's own maintenance runs through it
Where judgement mattered
- Dry-run/confirm on every write as a non-negotiable design rule, not a per-tool option
- Narrow, purpose-scoped tools rather than one general-purpose "run anything" tool
- Errors that tell you what to do next, because an assistant that can't recover is worse than no assistant
Technology stack
Model Context Protocol · C# / .NET · Azure DevOps REST APIs · Microsoft Graph · Azure Resource Manager and Monitor · Google and Microsoft advertising and search APIs