Skip to main content
Glama
ComplianceCow

ComplianceCow MCP Server

generate_rule_readme_preview

Generate README.md previews for compliance rules to validate technical documentation including architecture, inputs, outputs, and configuration specifications before creation.

Instructions

Generate README.md preview for rule documentation before actual creation.

RULE README GENERATION:

This tool generates a complete README.md structure as a string for user review. The MCP will create comprehensive rule documentation with detailed sections based on rule context and metadata, then return it for user confirmation.

README TEMPLATE STRUCTURE REQUIREMENTS:

The MCP should generate a README.md with exactly these sections:

SECTION 1: Rule Header

DESCRIPTION: Rule identification and overview CONTENT REQUIREMENTS:

  • Rule name as main title (# {RULE_NAME})

  • Brief description from rule metadata

  • Status badges (Version, Application Type, Environment)

  • Purpose statement

  • Last updated timestamp FORMAT: Markdown header with badges and overview

SECTION 2: Overview

DESCRIPTION: High-level rule explanation CONTENT REQUIREMENTS:

  • What this rule does (purpose and description)

  • Target system/application

  • Compliance framework alignment

  • Key benefits and use cases

  • When to use this rule FORMAT: Markdown sections with bullet points

SECTION 3: Rule Architecture

DESCRIPTION: Technical architecture and flow CONTENT REQUIREMENTS:

  • Rule flow diagram (text-based)

  • Task sequence and dependencies

  • Data flow: Input → Processing → Output

  • Integration points

  • Architecture decisions FORMAT: Markdown with code blocks for diagrams

SECTION 4: Inputs

DESCRIPTION: Detailed input specifications CONTENT REQUIREMENTS:

  • Table of all rule inputs with:

    • Input Name

    • Data Type

    • Required/Optional

    • Description

    • Default Value

    • Example Value

  • Input validation rules

  • File format specifications (for FILE inputs) FORMAT: Markdown table with detailed explanations

SECTION 5: Tasks

DESCRIPTION: Individual task breakdown CONTENT REQUIREMENTS:

  • For each task in the rule:

    • Task name and alias

    • Purpose and functionality

    • Input requirements

    • Output specifications

    • Processing logic overview

    • Error handling

  • Task execution order

  • Dependencies between tasks FORMAT: Markdown subsections for each task

SECTION 6: Outputs

DESCRIPTION: Rule output specifications CONTENT REQUIREMENTS:

  • Table of all rule outputs with:

    • Output Name

    • Data Type

    • Description

    • Format/Structure

    • Example Value

  • Output file formats and schemas

  • Success/failure indicators FORMAT: Markdown table with examples

SECTION 7: Configuration

DESCRIPTION: Rule configuration and setup CONTENT REQUIREMENTS:

  • Application type and environment settings

  • Execution level and mode

  • Required permissions and access

  • System prerequisites

  • Configuration examples

  • Environment-specific settings FORMAT: Markdown with code blocks

SECTION 8: Usage Examples

DESCRIPTION: Practical usage scenarios CONTENT REQUIREMENTS:

  • Basic usage example

  • Advanced configuration example

  • Common use cases

  • Best practices

  • Troubleshooting tips FORMAT: Markdown with code examples

SECTION 9: I/O Mapping

DESCRIPTION: Data flow mapping details CONTENT REQUIREMENTS:

  • Complete I/O mapping visualization

  • Rule input to task input mappings

  • Task output to task input mappings

  • Task output to rule output mappings

  • Data transformation explanations FORMAT: Markdown with formatted mapping table

SECTION 10: Troubleshooting

DESCRIPTION: Common issues and solutions CONTENT REQUIREMENTS:

  • Common error scenarios

  • Input validation failures

  • Task execution errors

  • Output generation issues

  • Performance considerations

  • Support and contact information FORMAT: Markdown FAQ-style sections

SECTION 11: Version History

DESCRIPTION: Change log and versioning CONTENT REQUIREMENTS:

  • Current version information

  • Version history table

  • Change descriptions

  • Migration notes

  • Deprecation warnings FORMAT: Markdown table with version details

SECTION 12: References

DESCRIPTION: Additional resources and links CONTENT REQUIREMENTS:

  • Related documentation links

  • Compliance framework references

  • API documentation

  • Support resources

  • Contributing guidelines FORMAT: Markdown bullet list with links

MARKDOWN FORMATTING REQUIREMENTS:

  • Use proper Markdown syntax

  • Include table of contents with links

  • Use code blocks for examples

  • Include badges and shields

  • Proper heading hierarchy (H1, H2, H3)

  • Use tables for structured data

  • Include horizontal rules for section separation

MCP CONTENT POPULATION INSTRUCTIONS: The MCP should extract the following information from the rule context:

  • Rule name, purpose, description from rule metadata

  • System name from appType (clean by removing connector suffixes)

  • Task details from spec.tasks array (name, alias, purpose, appTags)

  • Input specifications from spec.inputs object

  • Output specifications from spec.outputsMeta__

  • I/O mappings from spec.ioMap array

  • Environment and execution settings from labels

  • Application type and integration details

PLACEHOLDER REPLACEMENT RULES:

  • {RULE_NAME} = meta.name

  • {RULE_PURPOSE} = meta.purpose

  • {RULE_DESCRIPTION} = meta.description

  • {SYSTEM_NAME} = extracted from appType

  • {VERSION} = meta.version or "1.0.0"

  • {ENVIRONMENT} = meta.labels.environment[0]

  • {APP_TYPE} = meta.labels.appType[0]

  • {EXEC_LEVEL} = meta.labels.execlevel[0]

  • {TASK_COUNT} = len(spec.tasks)

  • {INPUT_COUNT} = len(spec.inputs)

  • {OUTPUT_COUNT} = len(spec.outputsMeta__)

  • {TIMESTAMP} = current ISO timestamp

CONTENT GUIDELINES:

  • Use clear, technical language

  • Include practical examples

  • Provide comprehensive coverage

  • Make it developer-friendly

  • Include troubleshooting help

  • Keep sections well-organized

  • Use consistent formatting

WORKFLOW:

  1. MCP retrieves rule context using fetch_rule() (ensure only the fetch_rule tool is called, not fetch_cc_rule)

  2. MCP extracts metadata and technical details

  3. MCP generates complete README.md content using template above

  4. MCP populates all placeholders with actual rule data

  5. MCP returns complete README content as string for user review

  6. User reviews and confirms the content

  7. If approved, call create_rule_readme() to actually save the README

Args: rule_name: Name of the rule for which to generate README preview

Returns: Dict containing complete README.md content as string for user review

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rule_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Discloses return format (Dict with string), clarifies correct dependency tool (fetch_rule not fetch_cc_rule), and explains preview-only nature, though lacks side-effect or idempotency details.

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?

Extremely verbose with 12+ sections of template implementation details that don't aid tool selection; front-loaded with internal specifications rather than usage guidance.

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

Completeness4/5

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

Comprehensive coverage of output format and workflow despite bloat; adequately explains what the tool returns given the output schema exists.

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?

Compensates for 0% schema description coverage with explicit Args section defining rule_name as 'Name of the rule for which to generate README preview'.

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?

Clear specific purpose (generate README.md preview as string) and explicitly distinguishes from sibling create_rule_readme by stating this is for review before actual creation.

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?

Excellent workflow section explicitly states when to use this tool (for preview) vs alternatives (call create_rule_readme after approval) and prerequisites (call fetch_rule first).

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