Skip to main content
Glama
cloudcwfranck

@cloudcraftwithfranck/govcloud-mcp

contingency_plan

Generate a NIST 800-34 compliant contingency plan for Azure government systems, defining BCP/DR procedures, RTO/RPO targets, activation criteria, and recovery tests.

Instructions

Generate a NIST 800-34 compliant Contingency Plan (CP) for an Azure government system. Covers BCP/DR procedures, RTO/RPO targets, activation criteria, recovery procedures, and test schedule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
systemNameYesSystem name
systemDescriptionYesWhat the system does
azureServicesYesAzure services that need recovery procedures
impactLevelYes
rtoHoursNoRecovery Time Objective in hours (default: 4)
rpoHoursNoRecovery Point Objective in hours (default: 1)
systemOwnerNoSystem owner name and organization

Implementation Reference

  • The handler function that executes the contingency plan tool logic. Takes validated args, calls Anthropic API with a detailed NIST SP 800-34 prompt, and returns the generated plan text.
    export async function handleContingencyPlan(args: unknown): Promise<string> {
      return runTool('contingency_plan', args, Schema, async ({ systemName, systemDescription, azureServices, impactLevel, rtoHours, rpoHours, systemOwner }) => {
        const response = await anthropic.messages.create({
          model: MODEL,
          max_tokens: getTokenBudget('contingency_plan'),
          system: DOCUMENT_SYSTEM,
          messages: [
            {
              role: 'user',
              content: `Generate a complete NIST SP 800-34 Contingency Plan for **${systemName}** at **${impactLevel}**.
    
    **System:** ${systemName}
    **Description:** ${systemDescription}
    **Azure Services:** ${azureServices.join(', ')}
    **System Owner:** ${systemOwner}
    **RTO:** ${rtoHours} hours
    **RPO:** ${rpoHours} hours
    
    Generate a complete, eMASS-ready Contingency Plan with these sections:
    
    ## 1. Introduction and Purpose
    - Applicable laws, policies, and regulations (FISMA, FedRAMP, DoDI 8500.01)
    - Scope and applicability
    
    ## 2. System Description and Architecture
    - ${systemName} overview
    - Azure services in scope with criticality ratings
    - Dependencies (external systems, network connectivity, personnel)
    
    ## 3. Roles and Responsibilities
    - Contingency Plan Coordinator
    - System Owner (${systemOwner})
    - IT Security Manager
    - Cloud Service Provider (Microsoft Azure) responsibilities
    - Communication tree
    
    ## 4. Activation and Notification
    - Activation criteria (what triggers the CP)
    - Notification procedures and contact list template
    - Initial assessment checklist
    
    ## 5. Recovery Objectives
    - RTO: ${rtoHours} hours — what must be restored and by when
    - RPO: ${rpoHours} hours — maximum acceptable data loss
    - Minimum Operating Requirements (MOR) for each service
    
    ## 6. Recovery Procedures — for each Azure service (${azureServices.join(', ')}):
    - Backup strategy (Azure Backup, geo-redundant storage, snapshots)
    - Step-by-step recovery procedure
    - Verification steps to confirm successful recovery
    - Azure CLI / PowerShell commands for recovery
    
    ## 7. Reconstitution Procedures
    - System validation checklist
    - Security scan requirements before returning to production
    - Change management for recovery actions
    
    ## 8. Testing and Exercises
    - ${impactLevel}-required test frequency (annual tabletop, functional, full-scale)
    - Test scenario templates
    - Lessons learned process
    
    ## 9. Plan Maintenance
    - Review schedule
    - Update triggers (significant changes, annual review, after exercises)
    
    Write in formal third-person government document style. Include actual Azure recovery commands and service-specific procedures.`,
            },
          ],
        });
    
        return response.content[0].type === 'text' ? response.content[0].text : '';
      });
    }
  • Zod schema for input validation of the contingency plan tool, defining and constraining all input fields (systemName, systemDescription, azureServices, impactLevel, rtoHours, rpoHours, systemOwner).
    const Schema = z.object({
      systemName: z.string().max(500),
      systemDescription: z.string().max(2000),
      azureServices: z.array(z.string().max(500)).min(1).max(50),
      impactLevel: z.enum(['fedramp-moderate', 'fedramp-high', 'il4', 'il5']),
      rtoHours: z.number().default(4),
      rpoHours: z.number().default(1),
      systemOwner: z.string().max(500).default('System Owner'),
    });
  • Tool definition object containing name ('contingency_plan'), description, and JSON Schema input schema for MCP registration.
    export const contingencyPlanTool = {
      name: 'contingency_plan',
      description:
        'Generate a NIST 800-34 compliant Contingency Plan (CP) for an Azure government system. Covers BCP/DR procedures, RTO/RPO targets, activation criteria, recovery procedures, and test schedule.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          systemName: { type: 'string', description: 'System name' },
          systemDescription: { type: 'string', description: 'What the system does' },
          azureServices: {
            type: 'array',
            items: { type: 'string' },
            description: 'Azure services that need recovery procedures',
          },
          impactLevel: {
            type: 'string',
            enum: ['fedramp-moderate', 'fedramp-high', 'il4', 'il5'],
          },
          rtoHours: {
            type: 'number',
            description: 'Recovery Time Objective in hours (default: 4)',
          },
          rpoHours: {
            type: 'number',
            description: 'Recovery Point Objective in hours (default: 1)',
          },
          systemOwner: {
            type: 'string',
            description: 'System owner name and organization',
          },
        },
        required: ['systemName', 'systemDescription', 'azureServices', 'impactLevel'],
      },
    };
  • Import and export of contingencyPlanTool and handleContingencyPlan; registration in allTools array (line 55) and routing in handleToolCall switch (line 82).
    import { contingencyPlanTool, handleContingencyPlan } from './documents/contingency-plan.js';
    
    import { govcloudQuickstartTool, handleGovcloudQuickstart } from './govcloud-quickstart.js';
    
    export const allTools = [
      // Compliance
      bicepAnalyzeTool,
      bicepRemediateTool,
      controlLookupTool,
      controlNarrativeTool,
      poamGenerateTool,
      atoReadinessTool,
      oscalFragmentTool,
      // Architecture
      landingZoneTool,
      landingZoneReferenceTool,
      serviceSelectTool,
      gccHighTool,
      privateEndpointTool,
      // Platform One
      bigbangValidateTool,
      bigbangHardenTool,
      ironbankLookupTool,
      addonConfiguratorTool,
      // Pipeline
      pipelineAuditTool,
      signingConfigTool,
      devsecopsScoreCardTool,
      // Documents
      sspSectionTool,
      contingencyPlanTool,
      // Meta
      govcloudQuickstartTool,
    ];
    
    export async function handleToolCall(name: string, args: unknown): Promise<string> {
      switch (name) {
        case 'bicep_analyze':         return handleBicepAnalyze(args);
        case 'bicep_remediate':       return handleBicepRemediate(args);
        case 'control_lookup':        return handleControlLookup(args);
        case 'control_narrative':     return handleControlNarrative(args);
        case 'poam_generate':         return handlePoamGenerate(args);
        case 'ato_readiness':         return handleAtoReadiness(args);
        case 'oscal_fragment':        return handleOscalFragment(args);
        case 'landing_zone_design':   return handleLandingZone(args);
        case 'landing_zone_reference': return handleLandingZoneReference(args);
        case 'azure_service_selector': return handleServiceSelect(args);
        case 'gcc_high_guidance':     return handleGccHigh(args);
        case 'private_endpoint_map':  return handlePrivateEndpoint(args);
        case 'bigbang_validate':      return handleBigbangValidate(args);
        case 'bigbang_harden':        return handleBigbangHarden(args);
        case 'ironbank_lookup':       return handleIronbankLookup(args);
        case 'addon_configurator':    return handleAddonConfigurator(args);
        case 'pipeline_audit':        return handlePipelineAudit(args);
        case 'signing_config':        return handleSigningConfig(args);
        case 'devsecops_scorecard':   return handleDevsecopsScorecard(args);
        case 'ssp_section':           return handleSspSection(args);
        case 'contingency_plan':      return handleContingencyPlan(args);
        case 'govcloud_quickstart':   return handleGovcloudQuickstart(args);
        default:
          throw new Error(`Unknown tool: ${name}`);
      }
    }
  • Token budget configuration for contingency_plan (8192 tokens) in the tool-runner utility.
    contingency_plan: 8192,
  • Timeout configuration for contingency_plan (60000ms) in the tool-runner utility.
    contingency_plan: 60000,
  • Minimum response length validation for contingency_plan (600 characters) in the response-validator utility.
    contingency_plan: 600,
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It only describes the content of the generated plan (coverage areas) but does not explain tool behavior: whether it creates a file, outputs text, requires permissions for Azure resources, or has side effects. Without this, an agent cannot anticipate outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the tool's purpose and output coverage. Every phrase adds value, with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool generates a compliance document with 7 parameters and no output schema, the description provides a high-level overview of the document's content. However, it lacks details on output format, storage location, prerequisites (e.g., Azure subscription), or error handling. It is adequate for basic understanding but incomplete for advanced use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (86%), and the schema descriptions adequately document parameters. The description's list of coverage areas (BCP/DR, RTO/RPO, etc.) does not directly explain parameter meanings but aligns with them. It adds minimal value beyond the schema, hence baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a NIST 800-34 compliant Contingency Plan for Azure government systems, listing specific coverage areas (BCP/DR, RTO/RPO, activation criteria, recovery procedures, test schedule). It is specific and distinguishes itself from sibling tools, which cover other compliance tasks (e.g., ATO readiness, control lookup).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for generating a contingency plan for Azure government systems, which is distinct from siblings. It does not explicitly state when to use or include exclusions, but the context is clear: it's the only tool generating CP documents among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cloudcwfranck/govcloud-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server