Skip to main content
Glama
ComplianceCow

ComplianceCow MCP Server

publish_rule

Makes a rule available for control attachment in the ComplianceCow system by first publishing its associated applications and then publishing the rule itself.

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

Behavior4/5

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

No annotations provided, so description carries full burden. It transparently discloses the multi-step orchestration, user gating, and execution blockers. However, it does not explicitly warn about destructive side-effects of publishing, only implies caution via status checks.

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

Conciseness2/5

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

The description is excessively long and repetitive, with multiple identical cautions and blockages. While structured, it could be condensed significantly without losing meaning.

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?

The description is very thorough about the procedural workflow, but it lacks a precise output schema (just 'Dict with publication status and details') and does not cover error handling scenarios. Given the complexity, this is a gap.

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

Parameters4/5

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

Schema coverage is 0%, so description must compensate. It explains rule_name as the primary name and cc_rule_name as an optional alternative, with detailed logic for alternative name handling in step 6. Adds significant meaning beyond the bare schema.

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

Purpose4/5

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

The description states it publishes a rule to make it available for ComplianceCow, which is clear. It distinguishes from siblings by including a multi-step workflow that calls other tools, but the composite nature blurs the tool's specific action.

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

Usage Guidelines5/5

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

Explicitly states when to use (after successful rule creation, rule tested) and mandates checking rule status first. Provides step-by-step workflow with alternatives (e.g., handle existing name) and enforces user interaction, making usage guidance very strong.

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