Add client-side tool parameter validation

[kashifpk]

Summary

Implement client-side validation of tool parameters before sending requests, providing immediate feedback to users.

Background

Currently, invalid tool arguments are only caught when the server responds with an error. Client-side validation would:

• Provide immediate feedback as users type
• Reduce unnecessary server requests
• Improve the developer experience
• Help users understand parameter requirements

Proposed Implementation

Validation Rules (based on JSON Schema)

Schema Property	Validation
required	Field must have a value
type: string	Value must be a string
type: number	Value must be numeric
type: integer	Value must be a whole number
type: boolean	Value must be true/false
enum	Value must be one of the allowed values
minimum/maximum	Number within range
minLength/maxLength	String length constraints
pattern	String matches regex pattern

CLI Validation

# Show error before sending request
$ anvil call get_weather
Error: Missing required argument: city

$ anvil call get_weather --arg city=Berlin --arg days=abc
Error: Argument 'days' must be a number

$ anvil call get_weather --arg city=Berlin --arg units=invalid
Error: Argument 'units' must be one of: metric, imperial

Web UI Validation

• Real-time validation as users type
• Visual indicators:
  • Red border on invalid fields
  • Error message below field
  • Disable "Call Tool" button if invalid
• Required field indicator (asterisk) - already implemented
• Show validation errors inline

Visual Example

┌─────────────────────────────────────────┐
│ city *                          string  │
│ ┌─────────────────────────────────────┐ │
│ │                                     │ │
│ └─────────────────────────────────────┘ │
│ ⚠️ This field is required               │
├─────────────────────────────────────────┤
│ days                           integer  │
│ ┌─────────────────────────────────────┐ │
│ │ abc                                 │ │
│ └─────────────────────────────────────┘ │
│ ⚠️ Must be a whole number               │
└─────────────────────────────────────────┘

        [Call Tool] (disabled)

Technical Implementation

function validateField(field, value) {
  const errors = [];
  
  // Required check
  if (field.required && (value === undefined || value === '')) {
    errors.push('This field is required');
  }
  
  // Type checks
  if (value !== undefined && value !== '') {
    if (field.type === 'number' || field.type === 'integer') {
      if (isNaN(Number(value))) {
        errors.push(\`Must be a \${field.type === 'integer' ? 'whole ' : ''}number\`);
      } else if (field.type === 'integer' && !Number.isInteger(Number(value))) {
        errors.push('Must be a whole number');
      }
    }
    
    // Range checks
    if (field.minimum !== undefined && Number(value) < field.minimum) {
      errors.push(\`Must be at least \${field.minimum}\`);
    }
    if (field.maximum !== undefined && Number(value) > field.maximum) {
      errors.push(\`Must be at most \${field.maximum}\`);
    }
    
    // Enum check
    if (field.enum && !field.enum.includes(value)) {
      errors.push(\`Must be one of: \${field.enum.join(', ')}\`);
    }
  }
  
  return errors;
}

Acceptance Criteria

• CLI validates required fields before sending
• CLI validates types (string, number, integer, boolean)
• CLI validates enum constraints
• Web UI shows real-time validation errors
• Web UI disables submit when validation fails
• Validation respects minimum, maximum, minLength, maxLength
• Clear error messages guide users to fix issues
• Option to bypass validation if needed (--force flag)

Nice to Have

• Pattern (regex) validation
• Array item validation
• Nested object validation