resilience-management-operations

Azure Resilience Management Operations

For operational Azure Resilience Management requests, use the Azure Resilience Management MCP tools when a registered tool supports the operation. If no registered tool supports the requested resilience operation, ask the user for explicit permission before using Azure CLI (az), az rest, direct HTTP/REST calls, PowerShell Azure commands, or SDK code as a fallback. This fallback restriction does not apply to non-resilience Azure operations or to development tasks such as implementing, testing, recording, or debugging tools; follow the applicable workflow and required tooling. This skill covers all tools registered under the resilience namespace.

• See tool reference for exact tool names, parameters, and enum values.
• See workflow recipes for end-to-end operation sequences and state gates.
• See payload reference before composing plan actions, groups, or recovery-resource updates.
• See recorded test guidance for the repository-wide recording architecture, sanitizers, matchers, and troubleshooting.

Operating Rules

1. Use get/list tools to resolve unknown IDs and inspect current state before mutations.
2. Never invent service groups, recovery plans, drill names, job IDs, source locations, recovery-resource IDs, identity IDs, or runbook IDs.
3. Use a tenant or subscription only when supplied by the user, available from the active environment, or returned by a preceding tool call.
4. Treat an explicit user request for a named mutation as authorization for that mutation. Ask only for missing choices that cannot be inferred safely.
5. Before irreversible deletion, identify the exact resource. A request such as “delete X” is sufficient confirmation; an ambiguous request is not.
6. Report operation IDs and recovery job IDs returned by asynchronous operations. Use the corresponding get tool to inspect status when requested.
7. Do not claim an accepted asynchronous operation has completed.
8. Do not retry stale jobs to represent a fresh operation. Start a new readiness or validation operation when current state must be assessed.
9. If a prerequisite fails, report per-resource blockers and do not start the dependent destructive operation.
10. Use recoveryplan as the recovery plan parameter for every tool.
11. For Recovery Orchestration (RO) recovery plan updates only, do not use or imply HTTP PATCH; the current SDK does not support RO recovery plan PATCH. Get the existing plan and preserve unchanged values in the create-or-update request.
12. For operational Azure Resilience Management requests, if no registered Resilience Management MCP tool supports the requested operation, explain that the operation is unavailable through the current toolset and ask the user for explicit permission to use az, REST, or another execution surface. Use a fallback only after the user approves it.
13. Distinguish parent usage-plan deletion from enrollment deletion by the requested outcome. “Delete/remove the usage plan” means delete the entire plan even when the request mentions its service group; never reinterpret it as deleting only an enrollment. “Unenroll/remove the service group association but keep the plan” means delete the enrollment only.

Route the Request

• Usage plan or enrollment → mcp_azure_mcp_ser_resilience_usageplan_*
• Goal template, assignment, or member → mcp_azure_mcp_ser_resilience_goal_*
• Drill definition, execution, run, or target → mcp_azure_mcp_ser_resilience_drill_*
• Recovery plan lifecycle or recovery operation → mcp_azure_mcp_ser_resilience_recoveryplan_*
• Recovery plan membership/protection → mcp_azure_mcp_ser_resilience_recoveryplan_resource_*
• Recovery job, paused action, retry, or job target → mcp_azure_mcp_ser_resilience_recoveryjob_*

Standard Procedure

Resolve context

1. Extract all identifiers and explicit choices from the current request.
2. Reuse identifiers from the current conversation only when they unambiguously refer to the same operation and target.
3. If a target name is known, call its get tool directly with name; do not list first unnecessarily.
4. If a target is described but not named, list the narrowest parent collection, present matching candidates, and ask only when multiple candidates remain.
5. Never choose among multiple subscriptions, service groups, plans, drills, jobs, locations, or resources without user direction.

Read-only requests

1. Call the matching get tool without name to list resources, or with name when the target is already known.
2. If a list response contains only IDs and names and full details are needed, call get again with name.
3. Return relevant status, IDs, state, errors, and attention reasons. Do not dump unrelated properties.

Create or update requests

1. Get the existing resource when update semantics depend on omitted values.
2. Collect conditionally required choices.
3. Call the create/update tool with the intended changes and all values required by its schema.
4. Re-read the resource when the response does not prove the intended state.

Delete requests

1. Get the named resource and verify it is the intended target.
2. Check for active drill runs, recovery operations, or other state that blocks deletion.
3. A request to delete a usage plan does not authorize deleting its child enrollments. If dependent enrollments block deletion, list their exact names and get explicit confirmation before removing any of them.
4. Call delete only for an explicit, unambiguous request.
5. Re-read the exact parent after deletion or confirmed prerequisite cleanup when a get tool is available.
6. Report whether the resource existed and whether deletion was accepted or completed.

Long-running or destructive requests

1. Resolve and inspect the exact target.
2. Run the mandatory pre-validation in the matching workflow recipe.
3. Stop if no resources qualify, readiness fails, or the state does not support the operation.
4. Execute only after required selectors and choices are provided.
5. Report the status returned by the command. If it returns Accepted, include operation/job IDs and inspect subsequent status only through get tools; otherwise, report the completed result.

Monitor asynchronous operations

1. Preserve every returned operation ID and recovery job ID.
2. Use recovery-job get for job state and drill-run get for drill execution history.
3. If a response is Accepted, say “accepted” or “started,” not “completed.”
4. On timeout, query state once if a suitable get tool and identifier exist; otherwise report that completion is unknown.
5. Do not poll indefinitely. Return the latest observed state and IDs when the operation remains in progress.

Failure Handling

• Surface service error codes, blocking reasons, attention reasons, and recommendations.
• A timeout means completion is unknown; do not report failure or success without a subsequent get.
• AutomationRunbookExistenceCheckUnavailable blocks readiness-dependent recovery operations until runbook accessibility is corrected.
• A test-proxy 404 that reports no matching recording is a playback infrastructure failure; do not mutate Azure to work around it. An Azure 404 intentionally preserved in a recording can validly represent a missing plan, job, or other resource.
• When an MCP call fails, retry only when the failure is transient and the operation is safe to repeat. Never switch to Azure CLI or direct REST to bypass the MCP failure.

Tool Development Standards

For the generic authoring lifecycle, follow add-azure-mcp-tools. Then apply the Resilience Management development requirements, including its stricter ToolDescriptionEvaluator gate.

Every new or behaviorally changed Resilience Management tool must have at least two distinct E2E evaluation prompts. For every prompt, the expected tool must rank #1 with a score of at least 0.6. This is an intentional Resilience-specific override of the repository-wide top-three and 0.4 baseline.

Tests for every new or behaviorally changed Resilience Management tool must always cover both positive and negative scenarios.

Result Format

State what was attempted, identify the target, summarize the outcome, and include operation/job IDs. For validation, list qualified and unqualified resources with reasons. For blocked mutations, state the prerequisite that must be corrected.