Skip to main content
Glama
ComplianceCow

ComplianceCow MCP Server

collect_parameter_input

Gathers validated parameter inputs for compliance workflows with mandatory confirmation and default value handling.

Instructions

Collect user input for non-template parameter inputs.

PARAMETER INPUT PROCESSING:

  • Collects primitive data type values (STRING, INT, FLOAT, BOOLEAN, DATE, DATETIME)

  • Stores values in memory (NEVER uploads files for primitive types)

  • Handles optional vs required inputs based on 'required' attribute

  • Supports default value confirmation workflow

  • Validates data types and formats

  • MANDATORY: Gets final confirmation for EVERY input before proceeding

INPUT REQUIREMENT RULES:

  • MANDATORY: Only if input.required = true

  • OPTIONAL: If input.required = false, user can skip or provide value

  • DEFAULT VALUES: If user requests defaults, must get confirmation

  • FINAL CONFIRMATION: Always required before proceeding to next input

DEFAULT VALUE WORKFLOW:

  1. User requests to use default values

  2. Show default value to user for confirmation

  3. "I can fill this with the default value: '[default_value]'. Confirm?"

  4. Only proceed after explicit user confirmation

  5. Store confirmed default value in memory

FINAL CONFIRMATION WORKFLOW (MANDATORY):

  1. After user provides value (or confirms default)

  2. Show final confirmation: "You entered: '[value]'. Is this correct? (yes/no)"

  3. If 'yes': Store value and proceed to next input

  4. If 'no': Allow user to re-enter value

  5. NEVER proceed without final confirmation

DATA TYPE VALIDATION:

  • STRING: Any text value

  • INT: Integer numbers only

  • FLOAT: Decimal numbers

  • BOOLEAN: true/false, yes/no, 1/0

  • DATE: YYYY-MM-DD format

  • DATETIME: ISO 8601 format

COLLECTION PRESENTATION: "Now configuring: [X of Y inputs]

Task: {task_name} Input: {input_name} ({data_type}) Description: {description} Required: {Yes/No} Default: {default_value or 'None'}

Please provide a value, type 'default' to use default, or 'skip' if optional:"

CRITICAL RULES:

  • NEVER upload files for primitive data types

  • Store all primitive values in memory only

  • Always confirm default values with user

  • ALWAYS get final confirmation before proceeding to next input

  • Respect required vs optional based on input.required attribute

  • Validate data types before storing

Args: task_name: Name of the task this input belongs to input_name: Name of the input parameter user_value: Value provided by user (optional) use_default: Whether to use default value (requires confirmation)

Returns: Dict containing parameter value and storage info

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_nameYes
input_nameYes
user_valueNo
use_defaultNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Extensively documents behavioral traits with no annotations present: mandatory confirmation workflows, in-memory storage only, validation rules for six data types, and strict rules about never proceeding without confirmation.

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 section headers, but excessively verbose with heavy ALL CAPS usage throughout; could convey the same critical rules more concisely while maintaining the workflow clarity.

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?

Comprehensively covers the complex interaction model including presentation templates, validation rules, and confirmation loops; appropriately brief on return values since 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 effectively for 0% schema description coverage by defining all four parameters in the Args section, adding semantic context like 'requires confirmation' for use_default and 'optional' for user_value.

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?

Clearly states it collects 'non-template parameter inputs' for primitive data types, explicitly distinguishing from template-based siblings and file upload tools via 'NEVER uploads files' and 'non-template' qualifiers.

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

Usage Guidelines4/5

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

Provides explicit when-to-use rules (primitive types, required vs optional) and detailed workflows, though it doesn't explicitly contrast with sibling tool 'confirm_parameter_input' or 'collect_template_input'.

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