Skip to main content
Glama
ComplianceCow

ComplianceCow MCP Server

publish_rule

Publish compliance rules to activate them for control attachment and organizational use within the ComplianceCow platform.

Instructions

Publish a rule to make it available for ComplianceCow system.

CRITICAL WORKFLOW RULES:

  • MANDATORY: Check rule status to ensure rule is fully developed before publishing

  • MUST FOLLOW THESE STEPS EXACTLY

  • DO NOT ASSUME OR SKIP ANY STEPS

  • APPLICATIONS FIRST, THEN RULE

  • WAIT FOR USER AT EACH STEP

  • NO SHORTCUTS OR BYPASSING ALLOWED

RULE PUBLISHING HANDLING:

WHEN TO USE:

  • After successful rule creation

  • User wants to make rule available for others

  • Rule has been tested and validated

WORKFLOW (step-by-step with user confirmation):

  1. Fetch applications and check status

  • Call fetch_applications() to get available applications

  • Extract appTypes from ALL tasks in rule spec.tasks[].appTags.appType - MUST TAKE ALL THE TASKS APPTYPE AND REMOVE DUPLICATES - CRITICAL: DO NOT SKIP ANY TASK APPTYPES

  • Match ALL task appTypes with applications app_type to get application_class_name

  • Call check_applications_publish_status() for ALL matched applications

  1. Present consolidated applications with meaningful format Applications for your rule: [1] App Name | Type: xyz | Status: Published | Action: Republish [2] App Name | Type: abc | Status: Not Published | Action: Publish

Select applications to publish: ___

  • MANDATORY: WAIT for user selection before proceeding to next step

  • DO NOT CONTINUE without explicit user input

  • BLOCK execution until user provides selection

  • STOP HERE: Cannot proceed to step 3 without user response

  • HALT WORKFLOW: Wait for user to select application numbers

  • NEVER SKIP THIS STEP: User must select applications first

  • ALWAYS ASK FOR SELECTION EVEN IF ALL APPLICATIONS ARE PUBLISHED

  1. Publish selected applications (BLOCKED until step 2 complete)

  • ENTRY REQUIREMENT: User selection from step 2 must be provided

  • PREREQUISITE CHECK: Verify user provided application numbers

  • CANNOT EXECUTE: Without completing step 2 user selection

  • Get user selection numbers

  • Call publish_application() for selected applications only

  • Inform user whether successfully published or not

  • CHECKPOINT: All applications must be published before rule steps

  1. Check rule publication status (APPLICATIONS MUST BE COMPLETE FIRST)

  • GATE KEEPER: Cannot proceed without application publishing completion

  • MANDATORY PREREQUISITE: All application steps finished

  • BLOCKED ACCESS: No rule operations until applications handled

  • Call check_rule_publish_status()

  • Check response valid field:

    • True = Already published

    • False = Not published

  1. Handle rule publishing based on status If valid=False (not published):

  • Show: "Rule is not published. Do you want to publish it? (yes/no)"

  • If yes: Proceed with publishing using current name

If valid=True (already published):

  • Show: "Rule is already published. Choose option:"

    • [1] Republish with same name

    • [2] Publish with another name

  • Get user choice

  1. Handle alternative name logic If "another name" chosen:

    1. Ask: "Enter new rule name: ___"

    2. Call check_rule_publish_status(new_name)

    3. If name exists: "Name already exists. Choose option:"

      • [1] Use same name (republish)

      • [2] Enter another name

    4. If name available: Proceed with new name

    5. Keep checking until user chooses available name or decides to republish existing

  2. Final publication

  • Call publish_rule() with confirmed name

  • Inform user: "Published successfully" or "Publication failed"

  1. Rule Association:

    • Publishes the rule to make it available for control attachment

    • Ask user: "Do you want to attach this rule to a ComplianceCow control? (yes/no)"

    • If yes: Proceed to associate the rule with control and request assessment name and control alias from the user

    • If no: End workflow

EXECUTION CONTROL MECHANISMS:

  • STEP GATE: Each step requires completion before next

  • USER GATE: Each step requires user input/confirmation

  • EXECUTION BLOCKER: No tool calls without user response

  • WORKFLOW ENFORCER: Steps cannot be skipped or assumed

  • SEQUENTIAL LOCK: Must complete in exact order

Args: rule_name: Name of the rule to publish cc_rule_name: Optional alternative name for publishing

Returns: Dict with publication status and details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rule_nameYes
cc_rule_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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

Mentions prerequisites (applications must be published first) and naming options, but lacks disclosure of error behaviors, idempotency, side effects, or state changes beyond the return value.

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

Conciseness1/5

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

Extremely verbose and repetitive with excessive capitalization and redundant warnings; the actual tool description is lost in procedural workflow documentation that belongs in system prompts rather than tool description.

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

Completeness2/5

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

Attempts to address workflow complexity but inappropriately embeds multi-tool orchestration logic instead of focusing on this tool's specific contract and prerequisites.

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?

With 0% schema description coverage, it provides minimal basic semantics ('Name of the rule to publish', 'Optional alternative name') but lacks constraints, format requirements, or examples for the parameters.

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

Purpose3/5

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

States the tool publishes a rule to make it available, but this is buried under extensive workflow instructions for multiple other tools, obscuring the specific action of this single tool.

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

Usage Guidelines3/5

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

Provides 'WHEN TO USE' context within a larger workflow, but fails to explicitly compare against sibling tools like publish_application or clarify when to use this specific tool versus alternatives.

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/ComplianceCow/cow-mcp'

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