Junction: one Rust binary for Microsoft's public APIs

Junction is a Rust runtime for Microsoft's public APIs. Instead of a hand-written SDK, it reads Microsoft's own specifications and normalises them into one versioned registry of operations. The default registry holds 20,081 operations across 10 products, and it rebuilds itself every day.

It's an independent open-source project. It isn't affiliated with or endorsed by Microsoft, and every call you make through it is still governed by your agreements with Microsoft.

Why I built it

Microsoft's security and admin surface is spread across Graph, Azure Resource Manager, Sentinel, Defender and Purview. Each has its own SDK, its own CLI, or in some cases no OpenAPI document at all. I wanted one tool that could answer the same questions for any of them. What is this operation called? What permissions does it need? Is it a read or a write? Then call it, with guard rails, from a terminal or from an AI agent.

The agent part matters. Handing an agent raw tokens and a pile of endpoints is a bad idea. Junction keeps policy on the operator's side.

How it works

The catalogues come from official sources: msgraph-metadata for Graph, azure-rest-api-specs for ARM, Sentinel, Defender for Cloud and Purview accounts, fabric-rest-api-specs for Fabric and the PowerBI-CSharp swagger for Power BI. Each document gets a receipt with its revision, SHA-256 and byte count.

A few products, like Defender for Endpoint, Defender XDR, Defender for Cloud Apps and Power Platform, don't publish OpenAPI at all. For those, Junction reads only the Microsoft Learn pages listed in each product's toc.json, pulls out the documented request templates, parameters, body tables, permission tables and paging, and builds an OpenAPI 3 document from them. That goes through the same normaliser as everything else.

Products with no separate API of their own, like Intune, Teams and SharePoint, get stable aliases over the matching Graph operations:

junction describe intune.devices.list
junction defender incidents list --input '{}'

Policy defaults to read-only. Destructive and privileged operations return approval_required, and agent input can't approve them. An operator can approve on the terminal with --approve, or issue a durable approval that lasts at most 24 hours and is bound to the exact operation, input and context. Isolating a device or changing a role counts as privileged. Offboarding counts as destructive.

Credentials cover client credentials, certificates, workload identity, managed identity, device code, PKCE, an optional existing az login and out-of-band API keys. Saved credentials go in the OS keychain only. There's no file fallback.

You can drive it four ways: the CLI, a Ratatui TUI for browsing the catalogue, a local HTTP API, or a native MCP server over stdio:

junction --context customer-a mcp serve --policy read-only

The MCP server exposes six tools for search, describe, execute, batch, permissions and context. Tool arguments can't supply credentials, endpoints, tenant switches or policy overrides. Those are fixed when the operator starts it.

Where it's at

It's prerelease. The catalogue, CLI, crates, MCP server, HTTP API and TUI are built and tested on Linux, macOS and Windows. On 2 October I ran a set of read-only calls against a real tenant: resource groups, the Graph organisation and users with paging, a Resource Graph query and the TUI runner. That run found and fixed two bugs. Write operations, sovereign clouds and most credential flows haven't been tested against live services yet, so treat it with care.

Try it

A GitHub Actions workflow refreshes the catalogues daily, bumps the patch version and publishes Linux, macOS and Windows binaries with SHA-256 checksums as prereleases. Grab one from the releases page, or build it yourself with Rust 1.89 or newer:

cargo build --release
./target/release/junction tui

No Python, Node.js, PowerShell or Azure CLI needed. The code is MIT licensed at github.com/jusso-dev/junction. Read the disclaimer before you point it at anything that matters.