Blog Post

Apps on Azure Blog
6 MIN READ

Plugin Marketplace for Azure SRE Agent: Build Once, Install Anywhere

Vineela-Suri's avatar
Vineela-Suri
Icon for Microsoft rankMicrosoft
Apr 29, 2026

Your organization's operational expertise lives in internal APIs, team runbooks, and policies that no external tool can access natively. The Plugin Marketplace lets any team package their domain knowledge and internal API integrations into a plugin — create it once, and every SRE Agent across the org can install it with one click.

What's a Plugin?

A plugin bundles two things:

  • Skills — Operational knowledge (triage runbooks, policy rules, known issues) the agent reads at runtime to guide its reasoning
  • MCP Connectors — Live integrations to your internal APIs (deployment tracker, cost dashboard, CMDB) the agent can query during an investigation

This is the key distinction: a plugin doesn't just tell the agent what your policies are — it gives the agent tools to query your internal systems and apply those policies with real data.

 

Plugin detail view showing the AKS Runbooks plugin with its 2 skills and 1 MCP connector listed.
A plugin bundles skills and MCP connectors as a single installable unit.

The Marketplace Model: Create Once, Install Everywhere

The marketplace is a GitHub repository with a marketplace.json manifest. Any team pushes their plugin to the repo. Every SRE Agent in the org can discover it and install it with one click — no need for each team to manually recreate skills and configure connectors.

How it works:

  1. A specialist team creates a plugin (skills + MCP connector config) and pushes it to the shared GitHub repo
  2. Any SRE Agent user browses the marketplace, sees what's available, and clicks Install
  3. The plugin's skills and connectors are deployed to that agent instance instantly

Contoso runs multiple SRE Agent instances — payments team, platform team, data team. The same marketplace serves all of them. Each team installs exactly the plugins they need.

Architecture diagram showing GitHub marketplace flowing into multiple SRE Agent instances, each connecting to internal APIsOne marketplace, many agents. Teams publish plugins once — every agent in the org can install them.

The Scenario: AKS Incident Investigation with Plugins

Contoso runs a payment processing service on AKS. Three teams have contributed plugins to the company's internal marketplace:

PluginTeamSkillsMCP Connector
AKS RunbooksK8s Platform Teamaks-incident-triage, aks-deployment-analysisDeployment Tracker API
Cost & CapacityCloud FinOps Teamcost-analysis, capacity-planningCost Dashboard API
Service CatalogSRE Leadershipservice-ownership-lookup, dependency-impact-analysisCMDB API

All three are installed on the payments team's SRE Agent. Let's see what happens when an incident hits.

Building and Publishing the Plugins

Each team creates their plugin independently and pushes it to the shared marketplace repo.

1. AKS Runbooks (Kubernetes Platform Team)

The K8s Platform Team packages their triage procedures, node pool naming conventions, PDB policies, known issues registry, and deployment gates.

Skills:

  • aks-incident-triage — Per-symptom triage procedures (OOMKill, NodePressure, CrashLoop), PDB-first policy checks, Tier-0 escalation rules, and a known issues registry
  • aks-deployment-analysis — Correlates incidents with recent deployments, surfaces resource spec diffs and gate violations, provides a rollback decision tree

MCP Connector:

  • contoso-deploy-tracker — Exposes get_deployments: recent deployments by namespace with deployer, image versions, resource diffs, and gate status

2. Cost & Capacity (Cloud FinOps Team)

The FinOps team packages their SKU approval matrix, team budget allocations, chargeback model, and scaling governance.

Skills:

  • cost-analysis — Team budget tiers, cost dashboard API usage, incident cost impact calculations
  • capacity-planning — "Scale-out before scale-up" rule (CCP-001), SKU approval matrix (B-series = team lead, D-series = director, E/N-series = VP/CTO), auto-scale thresholds

MCP Connector:

  • contoso-cost-dashboard — Exposes get_team_spend (budget, burn rate) and get_resources_cost (resource-level cost with utilization)

3. Service Catalog (SRE Leadership)

SRE Leadership packages service ownership, SLA tiers, escalation paths, and the dependency graph.

Skills:

  • service-ownership-lookup — Maps namespaces to owning teams, on-call contacts, SLA tiers (Tier-0 through Tier-3), escalation policies
  • dependency-impact-analysis — Dependency classification (hard/soft/async), blast radius assessment, security implications

MCP Connector:

  • contoso-cmdb — Exposes get_service_info (ownership, SLA), get_service_dependencies, and get_blast_radius

The Marketplace Manifest

All three plugins are described in a single marketplace.json that the SRE Agent discovers:

{
  "name": "Contoso SRE Plugins",
  "description": "Internal plugin marketplace for Contoso SRE teams",
  "version": "1.0.0",
  "plugins": [
    {
      "id": "aks-runbooks",
      "name": "AKS Runbooks",
      "description": "Kubernetes Platform Team's operational runbooks and deployment correlation",
      "author": "K8s Platform Team",
      "source": "./aks-runbooks",
      "category": "Operations"
    },
    {
      "id": "cost-capacity",
      "name": "Cost & Capacity",
      "description": "FinOps team's cost governance, SKU approval matrix, and capacity planning",
      "author": "Cloud FinOps Team",
      "source": "./cost-capacity",
      "category": "Cost Management"
    },
    {
      "id": "service-catalog",
      "name": "Service Catalog",
      "description": "Service ownership, SLA tiers, dependency graphs, and escalation paths",
      "author": "SRE Leadership",
      "source": "./service-catalog",
      "category": "Governance"
    }
  ]
}
GitHub repository showing the plugin marketplace structure — marketplace.json at .github/plugin/ and three plugin directories (aks-runbooks, cost-capacity, service-catalog) each with skills/ and .mcp.jsonThe internal plugin marketplace on GitHub. Each directory is a plugin contributed by a different team. The marketplace.json manifest tells the SRE Agent what's available.

Registering the Marketplace and Installing Plugins

Step 1: Add the Marketplace

In the SRE Agent, navigate to Builder → Plugins → Browse and click "Add Marketplace". Enter the GitHub repository path (contoso/sre-agent-plugins) and click Add.

The agent fetches marketplace.json and displays the marketplace card with all three plugins discovered.

SRE Agent "Add Marketplace" dialog with the GitHub repository URL enteredAdding the internal marketplace — just point to the GitHub repo.

Step 2: Browse the Catalog

The Browse tab now shows the Contoso SRE Plugins marketplace. Clicking into it reveals three plugin cards — one from each contributing team — with descriptions, skill counts, and connector details.

Marketplace browse view showing three plugin cards — AKS Runbooks, Cost & Capacity, Service Catalog — with author teams, skill counts, and install buttonsThree plugins from three teams. Each one brings skills (organizational knowledge) and an MCP connector (internal API access).

Step 3: Install All Three Plugins

Click into each plugin to review what it installs — skills and MCP connectors — then click "Install Plugin" for each one.

After installing all three:

  • 6 skills loaded (2 per plugin) — organizational knowledge documents the agent reads at runtime
  • 3 MCP connectors registered — internal API integrations the agent can call as tools
Plugin detail view showing the AKS Runbooks plugin with its 2 skills and 1 MCP connector listed, alongside the Install button
Each plugin clearly shows what it installs — skills and connectors — before you commit.
The Plugins page showing all three installed plugins with green "Installed" badges, green borders, and skill/connector countsAll three plugins installed — each card shows its "Installed" status, the authoring team, and exactly what it brings (2 skills, 1 connector). The green border and badge make installed plugins immediately recognizable.

The Agent in Action

Now let's ask the question:

"Pods are crashing in payments-prod on aks-payments-prod-eastus2 in sre-marketplace-demo-rg. Investigate and give me a full incident report."

The agent investigates — combining its native Kubernetes capabilities with the organizational context from all three plugins.

Agent conversation showing the full org-aware RCA — same kubectl forensics as before, now enriched with deployment correlation, known issue match, policy violation, cost analysis with budget context, blast radius with dependency classifications, and escalation path
The same strong Kubernetes diagnosis, now enriched with organizational context. Deployment correlation, policy violations, cost governance, blast radius, and escalation paths — all layered on top of the agent's native investigation.

Why This Matters: Different Teams, One Agent

The K8s Platform Team writes triage procedures and known issues. The FinOps Team writes budget governance and SKU rules. SRE Leadership defines service ownership and escalation paths.

Each team packages their domain expertise independently. The SRE Agent combines all of it at runtime — producing a response no single team could have written alone, drawn from three internal systems and three bodies of institutional knowledge.

This is how organizational knowledge scales: composable plugins that the agent reasons with in real-time, not longer wikis that nobody reads.

Learn More

 
Updated Apr 21, 2026
Version 1.0
No CommentsBe the first to comment