ComplianceCow MCP Server

Create a rule with the provided structure.

COMPLETE RULE CREATION PROCESS WITH PROGRESSIVE SAVING:

This tool now handles both initial rule creation and progressive updates during the rule creation workflow. It intelligently detects the completion status and sets appropriate metadata automatically. It returns the URL to view the rule in the UI once it is created display the URL in chat.

ENHANCED FOR PROGRESSIVE SAVING:

• Automatically detects rule completion status based on rule structure content

• Determines if rule is in-progress, ready for execution, or needs more inputs

• Handles both initial creation and updates of existing rules

• No additional parameters needed - analyzes rule structure intelligently

• Maintains all existing validation and creation logic

• Preserves all original docstring instructions and requirements

CRITICAL REQUIREMENT - INPUTS META:

• spec.inputsMeta__ is mandatory for all rules, and rule creation cannot proceed without it.

AUTOMATIC STATUS DETECTION:

• DRAFT: Rule has tasks but missing inputs or I/O mapping (5-85% complete)

• READY_FOR_CREATION: All inputs collected but I/O mapping incomplete (85% complete)

• ACTIVE: Complete rule with tasks, inputs, and I/O mapping (100% complete)

RULE COMPLETION ANALYSIS:

• Checks if tasks are defined in spec.tasks

• Validates that spec.inputsMeta__ exists

• Counts collected inputs in spec.inputs vs spec.inputsMeta__

• Validates I/O mapping presence and completeness in spec.ioMap

• Analyzes outputsMeta__ for mandatory compliance outputs

• Sets appropriate status and creation phase automatically

PROGRESSIVE CREATION PHASES (Auto-detected):

1. "initialized" - Basic rule info provided (5%)

2. "tasks_selected" - Tasks chosen and defined (25%)

3. "collecting_inputs" - Individual inputs being collected (25-85%)

4. "inputs_collected" - All inputs gathered, ready for I/O mapping (85%)

5. "completed" - Final rule creation complete with I/O mapping (100%)

ORIGINAL REQUIREMENTS MAINTAINED:

• All existing validation rules still apply

• Task alias validation in I/O mappings preserved

• Primary app type determination logic maintained

• Mandatory output requirements (CompliancePCT_, ComplianceStatus_, LogFile)

• YAML preview and user confirmation workflow preserved

• All existing error handling and validation checks

CRITICAL: This tool should be called:

1. After planning phase to create initial rule structure

2. After each input collection to update rule progressively

3. After input verification to finalize rule with I/O mapping

4. Rule status and progress automatically detected each time

PRE-CREATION REQUIREMENTS (Original):

1. spec.inputsMeta__ must be defined and contain valid input definitions

2. All inputs must be collected through systematic workflow

3. User must provide input overview confirmation

4. All template inputs processed via collect_template_input()

5. All parameter values collected and verified

6. User must confirm all input values before rule creation

7. Primary application type must be determined

8. Rule structure must be shown to user in YAML format for final approval

STEP 1 - PRIMARY APPLICATION TYPE DETERMINATION (Preserved): Before creating rule structure, determine primary application type:

1. Collect all unique appType tags from selected tasks

2. Filter out 'nocredapp' (dummy placeholder value)

3. Handle app type selection:

   • If only one valid appType: Use automatically

   • If multiple valid appTypes: Ask user to choose primary application

   • If no valid appTypes (all were nocredapp): Use 'generic' as default

4. Set primary app type for appType, annotateType, and app fields (single value arrays)

STEP 2 - RULE STRUCTURE WITH TASK ALIASES (Preserved):

    apiVersion: rule.policycow.live/v1alpha1
    kind: rule
    meta:
        name: MeaningfulRuleName # Simple name. Without special characters and white spaces
        purpose: Clear statement based on user breakdown
        description: Detailed description combining all steps
        labels:
            appType: [PRIMARY_APP_TYPE_FROM_STEP_1] # Single value array CRITICAL: Must be extracted from spec.tasks[].appTags.appType - NEVER use random values or user requirements
            environment: [logical] # Array
            execlevel: [app] # Array
        annotations:
            annotateType: [PRIMARY_APP_TYPE_FROM_STEP_1] # Same as appType - MUST match a task's appType
    spec:
        inputs:
        InputName: [ACTUAL_USER_VALUE_OR_FILE_URL]  # Use original or unique names based on conflicts, omit duplicates
        inputsMeta__:
        - name: InputName             # unique name for the input
        description:                # purpose of the input
        dataType: FILE|HTTP_CONFIG|STRING|INT|FLOAT|BOOLEAN|DATE|DATETIME
        repeated:                   # true = multiple values allowed, false = single value
        allowedValues:              # if repeated=true: comma-separated input is split into array
        required:                   # value must be taken from task details.
        defaultValue: [ACTUAL_USER_VALUE] #values are collected from users, If the dataType is FILE or HTTP_CONFIG then the value should be filepath URL.
        format: [ACTUAL_FILE_FORMAT]      # only include for FILE types (json, yaml, toml, xml, etc.)
        showField: true                   # true = most important field, false = optional/less important
        outputsMeta__:
        - name: FinalOutput
        dataType: FILE|STRING|INT|FLOAT|BOOLEAN|DATE|DATETIME
        required: true
        defaultValue: [ACTUAL_RULE_OUTPUT_VALUE]
        tasks:
        - name: Step1TaskName # Original task names
        alias: step1 # Meaningful task aliases (simple descriptors)
        type: task
        appTags:
            appType: [COPY_FROM_TASK_DEFINITION] # Keep original task appType
            environment: [logical] # Array
            execlevel: [app] # Array
        purpose: What this task does for Step 1
        - name: Step2TaskName
        alias: validation # Another meaningful alias
        type: task
        appTags:
            appType: [COPY_FROM_TASK_DEFINITION]
            environment: [logical] # Array
            execlevel: [app] # Array
        purpose: What this task does for validation
        ioMap:
        - step1.Input.TaskInput:=*.Input.InputName  # Use task aliases in I/O mapping
        - validation.Input.TaskInput:=step1.Output.TaskOutput
        # MANDATORY: Always include these three outputs from the last task
        - '*.Output.FinalOutput:=validation.Output.TaskOutput'
        - '*.Output.CompliancePCT_:=validation.Output.CompliancePCT_'    # Compliance percentage from last task
        - '*.Output.ComplianceStatus_:=validation.Output.ComplianceStatus_'  # Compliance status from last task
        - '*.Output.LogFile:=validation.Output.LogFile'  # Log file from last task

STEP 3 - I/O MAPPING WITH TASK ALIASES (Preserved):

• Use golang-style assignment: destination:=source

• 3-part structure: PLACE.DIRECTION.ATTRIBUTE_NAME

• Always use EXACT attribute names from task specifications

• Use meaningful task aliases instead of generic names

• Ensure sequential data flow: Rule → Task1 → Task2 → Rule

• Mandatory compliance outputs from last task

STEP 4 - inputsMeta__ Cleanup: In spec.inputsMeta__, retain only the entries whose keys exist in spec.inputs. Remove any fields in spec.inputsMeta__ that are not present in spec.inputs.

VALIDATION CHECKLIST (Preserved): □ Rule structure validation against schema □ Task alias validation in I/O mappings □ Primary app type determination □ Input/output specifications validation □ Mandatory compliance outputs present □ Sequential data flow in I/O mappings

Args: rule_structure: Complete rule structure with any level of completion

Returns: Result of rule creation including auto-detected status and completion level