Problem

The CommandExecutor currently has no rate limiting or concurrency controls, which poses several risks:

• Resource Exhaustion: Unlimited concurrent processes can overwhelm the system
• Security Risk: Potential for DoS attacks through command flooding
• Performance Issues: No protection against resource-intensive operations
• Fair Usage: No mechanism to ensure equitable resource distribution

Current State

• No limits on concurrent process execution
• No rate limiting for command requests
• No resource quotas or throttling
• Unlimited process spawning capability

Proposed Solution

1. Concurrency Controls

# Configuration options
self.max_concurrent_processes = 10      # Max simultaneous processes
self.max_processes_per_user = 5         # Per-user process limit
self.process_queue_size = 50            # Max queued requests

2. Rate Limiting

# Rate limiting configuration
self.rate_limit_requests_per_minute = 60    # Commands per minute
self.rate_limit_window_seconds = 60         # Rate limit window
self.rate_limit_burst_size = 10             # Burst allowance

3. Resource Quotas

# Resource limits
self.max_memory_per_process_mb = 512        # Memory limit per process
self.max_cpu_time_seconds = 300             # CPU time limit
self.max_execution_time_seconds = 600       # Wall clock time limit

Implementation Plan

Phase 1: Basic Concurrency Control

• Add max_concurrent_processes limit
• Queue requests when limit reached
• Return appropriate errors for queue overflow
• Add metrics for concurrent process count

Phase 2: Rate Limiting

• Implement token bucket or sliding window algorithm
• Add per-user/session rate limiting
• Return HTTP 429 (Too Many Requests) when rate limited
• Add rate limit headers in responses

Phase 3: Resource Monitoring

• Monitor memory usage per process
• Implement CPU time tracking
• Auto-terminate processes exceeding limits
• Add resource usage metrics

Phase 4: Advanced Features

• Priority queuing for different command types
• Adaptive rate limiting based on system load
• User-specific quotas and limits
• Graceful degradation under high load

API Changes

New Configuration

class RateLimitConfig:
    max_concurrent_processes: int = 10
    max_processes_per_user: int = 5
    requests_per_minute: int = 60
    burst_size: int = 10
    memory_limit_mb: int = 512
    cpu_time_limit_seconds: int = 300

New Methods

def check_rate_limit(self, user_id: str) -> bool
def check_concurrency_limit(self) -> bool
def queue_command(self, command: str, user_id: str) -> str
def get_queue_status(self) -> Dict[str, Any]

New Responses

# Rate limited response
{
    "error": "rate_limited",
    "message": "Too many requests",
    "retry_after": 30,
    "limits": {
        "requests_per_minute": 60,
        "current_usage": 65
    }
}

# Concurrency limited response
{
    "error": "concurrency_limited", 
    "message": "Too many concurrent processes",
    "queue_position": 3,
    "estimated_wait_seconds": 45
}

Benefits

• System Stability: Prevents resource exhaustion
• Security: Protects against abuse and DoS attacks
• Performance: Maintains responsive system under load
• Fair Usage: Ensures equitable resource distribution
• Observability: Better monitoring and metrics

Acceptance Criteria

• Configurable concurrency limits enforced
• Rate limiting with appropriate error responses
• Resource monitoring and limits
• Queue management for excess requests
• Comprehensive metrics and logging
• Backward compatibility maintained
• Performance impact minimized

Priority

P1 (High) - Important for production stability and security

Files to Modify

• mcp_tools/command_executor/executor.py
• mcp_tools/command_executor/types.py (new rate limit types)
• Configuration files
• API endpoints for rate limit info
• Tests for all rate limiting scenarios

Dependencies

• May depend on user authentication/identification system
• Requires metrics/monitoring infrastructure