Skip to main content
Glama
ComplianceCow

ComplianceCow MCP Server

configure_rule_output_schema

Configure the output schema for compliance rules by selecting standard, extended, or both formats and mapping mandatory evidence fields before rule execution.

Instructions

PREREQUISITE — MUST RUN FIRST (NON-SKIPPABLE) This tool is a hard prerequisite and MUST be executed successfully before the prepare_input_collection_overview() tool (and any downstream rule-creation or evaluation steps). If this tool has not run or did not complete, the workflow MUST fail fast with an explicit error.

PURPOSE Establish the rule's output schema policy for ComplianceCow and apply any required transformations. In ComplianceCow, we maintain a standard format for storing evidence records. The user MUST choose one of the following rule output options:

  1. Standard schema only (ComplianceCow structured response fields)

  2. Extended schema only (all fields from the source response)

  3. Both standard + extended

USER PROMPT (MANDATORY — NEVER SKIPPABLE) The workflow MUST always pause and explicitly prompt the user before proceeding.
This step CANNOT be bypassed, defaulted, auto-selected, or inferred.
If the user has not actively selected one of (a), (b), or (c), this tool MUST fail fast with a clear error message and stop execution.

VALIDATION & ENFORCEMENT

  • This tool is NON-SKIPPABLE. If not executed, or if the user does not provide an explicit choice (a/b/c), the workflow MUST stop immediately with an error.

  • No implicit defaults, assumptions, or auto-selections are allowed.

  • Mandatory Key mapping rules still apply if Standard schema is chosen.

BEHAVIOR BY SELECTION

A) If user selects STANDARD ONLY:

  • If the pipeline already ends with a Transformation task, reuse the existing Transformation task instead of appending a new one.

  • Otherwise, append a Transformation task at the END of the selected task pipeline.

  • In the Transformation task, map ALL Mandatory Keys (listed below).

  • Values for these keys MUST be taken from the pipeline's input file(s) and/or upstream task outputs, following the Deeper Analysis Rules.

  • Continue collecting inputs for the Transformation task using: collect_template_input() or collect_parameter_input().

  • For each input that requires user guidance, call: get_template_guidance('{task.name}', '<input_name>') to display the expected input format to the user.

  • Ask the user to review and confirm OR edit the configuration before proceeding.

  • Do not proceed unless all Mandatory Keys are mapped and the configuration is confirmed (fail fast with guidance).

B) If user selects EXTENDED ONLY:

  • The Extended schema is a NON-STANDARD structure. It preserves the raw fields from the source response without enforcing ComplianceCow's standard schema format or mandatory key order.

  • Use the LAST task's output directly as the Extended schema output.

  • No mandatory field ordering or schema enforcement is applied — the structure is kept as-is for completeness and traceability.

C) If user selects BOTH:

  • Perform all steps from (A) to create the Standard schema:

  • Append a Transformation task at the END of the selected task pipeline.

  • Map ALL Mandatory Keys in the exact required order.

  • Include as needed for compliance.

  • Also add the Extended schema as a NON-STANDARD structure:

  • Create exactly ONE output field named: ExtendedData_. MUST be determinable from the use case (e.g., source, resource, or input artifact name).

  • Map the SAME LAST task output that is used as the input to the Transformation task into ExtendedData_.

  • Do NOT create duplicate extended outputs (for example, do not add both ExtendedData_JSONToCSV and ConvertedCSVFile if they contain the same data). Only ExtendedData_ must exist.

  • Continue collecting inputs for the Transformation task using: collect_template_input() or collect_parameter_input().

  • For each input that requires user guidance, call: get_template_guidance('{task.name}', '<input_name>') to display the expected input format to the user.

  • Ask the user to review and confirm OR edit the configuration before proceeding.

  • Do not proceed unless:

  • All Mandatory Keys are mapped and validated in order

  • Configuration is confirmed by the user

DEEPER ANALYSIS RULES

  • Always extract and map the core Mandatory Keys required for compliance.

  • For , determine the minimal required fields based on the user's specific use case and map them under the Standard schema.

  • If additional fields are critical for the use case, map them explicitly into the Standard schema.

  • If fields are non-critical but useful, preserve them under ExtendedData_<filename>.

  • If MCP cannot store certain fields, the tool MUST explain the omission clearly to the user before proceeding and request confirmation if needed.

MANDATORY KEYS (MUST ALWAYS BE MAPPED — IN THIS EXACT ORDER)

  • System

  • Source

  • ResourceID

  • ResourceName

  • ResourceType

  • ResourceLocation

  • ResourceTags

  • <Important Keys Based On User's Use Case> (for example: fields from the response file such as user_id, username, email, license_type, assigned_date, last_login_date, last_activity_date)

  • ValidationStatusCode

  • ValidationStatusNotes

  • ComplianceStatus

  • ComplianceStatusReason

  • EvaluatedTime

  • UserAction

  • ActionStatus

  • ActionResponseURL

VALIDATION & ENFORCEMENT

  • This tool is NON-SKIPPABLE. If not executed, or if any Mandatory Key mapping is missing for the chosen Standard schema path, the workflow MUST stop with an error.

  • Key names are case-sensitive and MUST NOT be renamed.

  • The tool MUST persist the chosen option and mappings so that downstream tools consume a consistent schema contract.

  • The workflow MUST NOT proceed to prepare_input_collection_overview() until:

    • Inputs are collected via collect_template_input() or collect_parameter_input()

    • get_template_guidance() has been used for each input needing guidance

    • The user has confirmed or edited the configuration

    • All Mandatory Keys are mapped and validated in order

  • Mandatory, a JS chart (Mermaid/D3) MUST be generated to visualize the rule's I/O field structure. The chart must be displayed in this chat immediately after user input, and no further processing is allowed until this step is completed.

EXECUTION ORDER GUARANTEE On success, and ONLY after input collection and configuration confirmation, the next tool to run MUST be prepare_input_collection_overview().

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries full burden and extensively discloses behavior: mandatory user prompting, fail-fast conditions, Transformation task appending/reuse, Mandatory Key mapping requirements, Mermaid chart generation, and execution order guarantees.

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

Conciseness3/5

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

Well-structured with clear headers and front-loaded prerequisite warnings, but excessively verbose (functional specification length); while every sentence earns its place for workflow compliance, the density hinders quick parsing.

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

Completeness5/5

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

Given the high complexity of orchestrating multi-step workflow logic (input collection, validation, chart generation), the description is complete with mandatory keys, downstream dependencies, and user confirmation requirements fully specified.

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?

Input schema has 0 parameters, meeting the baseline of 4; description compensates by explaining that user selection (a/b/c) is collected through mandatory prompting rather than schema parameters.

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?

Explicitly states it establishes the rule's output schema policy with three specific options (Standard/Extended/Both) and clearly distinguishes itself as the mandatory first step before prepare_input_collection_overview.

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 (MUST RUN FIRST), when not to use (never skip), and details the three mutually exclusive behavioral paths (A/B/C) with specific consequences for each selection.

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