Skip to main content
Glama
jakedx6

Helios-9 MCP Server

by jakedx6

execute_workflow_rule

Execute a workflow rule manually for testing. Simulate trigger events with test data to validate rule behavior.

Instructions

Manually execute a workflow rule for testing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rule_idYesID of the rule to execute
test_dataNoTest data to simulate the trigger event
dry_runNoIf true, only simulate execution without performing actions

Implementation Reference

  • The main handler function for execute_workflow_rule. Uses requireAuth wrapper, parses input with ExecuteWorkflowRuleSchema, fetches the rule via supabaseService, iterates over its actions calling executeAction(), logs execution, and returns results.
    export const executeWorkflowRule = requireAuth(async (args: any) => {
      const { rule_id, test_data, dry_run } = ExecuteWorkflowRuleSchema.parse(args)
      
      logger.info('Executing workflow rule', { rule_id, dry_run })
    
      const rule = await supabaseService.getWorkflowRule(rule_id)
      if (!rule) {
        throw new Error('Workflow rule not found')
      }
    
      if (!rule.enabled && !dry_run) {
        throw new Error('Cannot execute disabled rule (use dry_run for testing)')
      }
    
      const executionResults = []
      
      for (const action of rule.actions) {
        try {
          const result = await executeAction(action, test_data, dry_run)
          executionResults.push({
            action_type: action.action_type,
            success: true,
            result,
            dry_run
          })
        } catch (error) {
          logger.error(`Failed to execute action ${action.action_type}:`, error)
          executionResults.push({
            action_type: action.action_type,
            success: false,
            error: error instanceof Error ? error.message : 'Unknown error',
            dry_run
          })
        }
      }
    
      // Log execution if not dry run
      if (!dry_run) {
        await supabaseService.logWorkflowExecution({
          rule_id,
          trigger_data: test_data,
          execution_results: executionResults,
          executed_at: new Date().toISOString()
        })
      }
    
      return {
        rule_name: rule.name,
        executed_actions: executionResults.length,
        successful_actions: executionResults.filter(r => r.success).length,
        failed_actions: executionResults.filter(r => !r.success).length,
        results: executionResults,
        dry_run
      }
    })
  • Zod schema for input validation of execute_workflow_rule: rule_id (string, required), test_data (optional record), dry_run (boolean, default false).
    const ExecuteWorkflowRuleSchema = z.object({
      rule_id: z.string().min(1),
      test_data: z.record(z.any()).optional(),
      dry_run: z.boolean().default(false)
    })
  • Tool metadata registration: name 'execute_workflow_rule', description, and inputSchema defining the expected JSON properties.
    export const executeWorkflowRuleTool: MCPTool = {
      name: 'execute_workflow_rule',
      description: 'Manually execute a workflow rule for testing',
      inputSchema: {
        type: 'object',
        properties: {
          rule_id: {
            type: 'string',
            description: 'ID of the rule to execute'
          },
          test_data: {
            type: 'object',
            description: 'Test data to simulate the trigger event'
          },
          dry_run: {
            type: 'boolean',
            default: false,
            description: 'If true, only simulate execution without performing actions'
          }
        },
        required: ['rule_id']
      }
    }
  • Helper function executeAction that dispatches to the appropriate action type (create_task, update_task, send_notification, assign_task, move_task, create_document) via supabaseService calls.
    async function executeAction(action: any, testData: any, dryRun: boolean): Promise<any> {
      if (dryRun) {
        return { simulated: true, action_type: action.action_type, parameters: action.parameters }
      }
    
      switch (action.action_type) {
        case 'create_task':
          return await supabaseService.createTask({
            title: action.parameters.title,
            description: action.parameters.description,
            project_id: action.parameters.project_id || testData?.project_id,
            initiative_id: null,
            priority: action.parameters.priority || 'medium',
            assignee_id: action.parameters.assignee_id,
            status: 'todo',
            due_date: null
          })
    
        case 'update_task':
          return await supabaseService.updateTask(
            action.parameters.task_id || testData?.task_id,
            action.parameters.updates
          )
    
        case 'send_notification':
          // Would integrate with notification service
          return { 
            notification_sent: true, 
            recipient: action.parameters.recipient,
            message: action.parameters.message 
          }
    
        case 'assign_task':
          return await supabaseService.updateTask(
            action.parameters.task_id || testData?.task_id,
            { assignee_id: action.parameters.assignee_id }
          )
    
        case 'move_task':
          return await supabaseService.updateTask(
            action.parameters.task_id || testData?.task_id,
            { status: action.parameters.new_status }
          )
    
        case 'create_document':
          return await supabaseService.createDocument({
            title: action.parameters.title,
            content: action.parameters.content,
            project_id: action.parameters.project_id || testData?.project_id,
            document_type: action.parameters.document_type || 'note'
          })
    
        default:
          throw new Error(`Unknown action type: ${action.action_type}`)
      }
    }
  • Exported handler map wiring 'execute_workflow_rule' string key to the executeWorkflowRule function for runtime dispatch.
    export const workflowAutomationHandlers = {
      create_workflow_rule: createWorkflowRule,
      list_workflow_rules: listWorkflowRules,
      execute_workflow_rule: executeWorkflowRule,
      create_trigger_automation: createTriggerAutomation,
      get_automation_analytics: getAutomationAnalytics
    }
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only mentions 'testing' without detailing side effects, safety implications, or the role of the dry_run parameter. This is insufficient for an agent to understand real-world impacts.

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

Conciseness5/5

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

The description is a single sentence of 6 words that conveys the essential purpose without extraneous information. It is maximally concise.

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?

The tool has no output schema and a nested object parameter (test_data). The description lacks expectations for return values, execution results, or when to use dry_run vs. real execution, leaving the agent with incomplete context for effective use.

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?

The input schema has 100% description coverage for parameters, meeting the baseline. The description adds no new parameter information beyond what the schema already provides.

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?

The description 'Manually execute a workflow rule for testing' clearly states the action (execute), resource (workflow rule), and context (testing). It differentiates from siblings like create_workflow_rule and list_workflow_rule.

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?

The description implies use for testing but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or caveats.

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/jakedx6/helios9-MCP-Server'

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