api-patterns
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there…
Onboarding the azure-mcp connector in the WYRE MCP Gateway: Azure service-principal registration, the tenantId/clientId/clientSecret triple, least-privilege Reader-tier RBAC assignments, the gateway's read-only namespace allowlist, and connection verification and failure modes
Claude Code
$ npx -y skills add wyre-ai/msp-claude-plugins --skill connection --agent claude-code
Codex
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a codex -y
Cursor
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a cursor -y
Gemini CLI
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a gemini-cli -y
GitHub Copilot
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a github-copilot -y
OpenCode
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a opencode -y
Windsurf
$ npx skills add wyre-ai/msp-claude-plugins --skill connection -a windsurf -y
name: "azure-mcp-connection" description: > Onboarding the azure-mcp connector in the WYRE MCP Gateway: Azure service-principal registration, the tenantId/clientId/clientSecret triple, least-privilege Reader-tier RBAC assignments, the gateway's read-only namespace allowlist, and connection verification and failure modes (expired secret, missing role assignment). when_to_use: >- When setting up or troubleshooting the azure-mcp connector — creating an Azure service principal, choosing RBAC roles, or explaining the read-only constraint to an MSP onboarding a tenant. Use when: connect azure mcp, azure mcp setup, azure service principal, azure mcp credentials, azure rbac for mcp, azure connector, azure mcp permissions, register azure app, or least privilege azure.
The `azure-mcp` vendor runs Microsoft's official Azure MCP Server (`mcr.microsoft.com/azure-sdk/azure-mcp`) as a WYRE-built sidecar inside the MCP gateway. Each connecting MSP supplies its own Azure **service principal**; the gateway isolates credentials per tenant and scopes every request to the principal you registered.
"Azure tenant" almost always means the M365 tenant. This connector reaches Azure Resource Manager only. Tenant onboarding, GDAP, and CSP relationships are `cipp-tenants`; Graph app registrations are `microsoft-graph-connection`.
`azure-mcp-observability` or `azure-mcp-cost-and-capacity`.
The gateway runs the Azure MCP Server with the `--read-only` flag and a deliberately constrained namespace allowlist. The live connector lists eleven tools:
subscription_list group_list group_resource_list advisor monitor resourcehealth applens pricing quota foundry search
`subscription_list`, `group_list`, `group_resource_list` and `advisor` are classified `read` in Conduit. The rest are unclassified and enforce at `admin`; `foundry` (Azure AI Foundry) and `search` (Azure AI Search) are newer namespaces that this plugin does not otherwise cover.
Write- and delete-capable namespaces (`storage`, `keyvault`, `compute`, `role`, `aks`, and others) are **not enabled**. This is intentional defense-in-depth: even if a service principal were over-privileged, the gateway cannot route a mutating call. As shipped, `azure-mcp` is an Azure observability, cost, and resource-health tool — nothing it does changes infrastructure.
Because the deployment is read-only, the service principal you connect should also be read-only. Grant Reader-tier roles and nothing more.
In the Azure tenant you want to manage, create an Azure AD **app registration** with a client secret. Either the portal (**Microsoft Entra ID → App registrations → New registration**) or the CLI works:
az ad sp create-for-rbac \ --name "wyre-azure-mcp" \ --role "Reader" \ --scopes "/subscriptions/<subscription-id>"
This emits three values you will need for the gateway:
If you reuse an existing app registration, generate a fresh client secret under **Certificates & secrets** and note its expiry — the connector stops working when the secret lapses.
Assign **Reader-tier roles only**, at **subscription scope** (or management-group scope to cover several subscriptions). These two built-in roles cover all eight enabled namespaces:
| Role | Why it is needed | Covers | |------|------------------|--------| | `Reader` | Read-only visibility into resources, metrics, health, and inventory | `monitor`, `resourcehealth`, `applens`, `advisor`, `subscription`, `group` | | `Cost Management Reader` | Read access to cost, pricing, and usage data | `pricing`, `quota`, cost-focused `advisor` recommendations |
az role assignment create \ --assignee "<service-principal-client-id>" \ --role "Reader" \ --scope "/subscriptions/<subscription-id>" az role assignment create \ --assignee "<service-principal-client-id>" \ --role "Cost Management Reader" \ --scope "/subscriptions/<subscription-id>"
For Log Analytics KQL queries via the `monitor` namespace, `Reader` on the subscription is sufficient because it inherits to the workspace. If a workspace lives outside the granted scope, add `Log Analytics Reader` on that specific workspace — still a Reader-tier role.
`Contributor`, `Owner`, `User Access Administrator`, `Key Vault Secrets User`, and similar write/secret roles are **unnecessary and must not be granted**. The connector cannot use them — the gateway runs `--read-only` and the write namespaces are not in the allowlist. Granting them only widens the blast radius of a leaked secret with zero functional benefit. Least privilege here is both a security control and a no-cost decision.
In the gateway connection UI, choose the **`azure-mcp`** vendor and supply:
1. **Tenant ID** — the directory the service principal lives in 2. **Service Principal Client ID** — the app registration's `appId` 3. **Service Principal Client Secret** — the secret from Step 1
The gateway authenticates the Azure MCP sidecar with these credentials and routes the enabled namespaces' 11 tools into your session. No Azure credentials are stored client-side.
After connecting, confirm the connector is live with a harmless read:
1. List subscriptions (`subscription_list`) — confirms the service principal authenticated and has at least Reader visibility. 2. List resource groups (`group_list`) for one subscription, then one group's resources (`group_resource_list`) — confirms scope is correct. 3.
One command to supercharge Claude Code for MSP workflows. Then restart Claude Code. That's it. Documentation: mcp.wyre.ai
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there…
3CX's live-operations surface: read-only visibility into active calls, recordings, voicemail, department and queue membership,…
3CX's read-only directory surface: resolving a caller by email or by exact extension, searching the PBX's own phonebooks,…
3CX's system-and-configuration surface: server time, PBX event log and application log search, service status, database schema…
Abnormal Security abuse mailbox cases: user-reported email submissions, case statuses and judgments, the case lifecycle, bulk and…
Abnormal Security message analysis: message retrieval, email header inspection, attachments, sender reputation, delivery context,…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.