-
Notifications
You must be signed in to change notification settings - Fork 149
Open
Description
Problem
Currently, MCPB 0.3 user_config only supports primitive types: string, number, boolean, directory, file. This limits configuration UX when extensions need users to select from a predefined set of options.
Use Case (Anonymized)
A monitoring extension tracks various SaaS platforms. The extension has pre-built scrapers for certain platforms (e.g., Platform A, Platform B, Platform C) with rich data sources, while unsupported platforms fall back to basic RSS scraping.
Current workaround:
"user_config": {
"platforms": {
"type": "string",
"description": "Comma-separated list: PlatformA, PlatformB, PlatformC",
"default": "PlatformA, PlatformB"
}
}Problems with this approach:
- Users can enter unsupported platform names → silent failures or degraded experience
- No validation at configuration time
- Unclear which platforms are fully supported vs experimental
- Poor UX (manual typing vs dropdown selection)
Proposed Solution
Add enum type support for user_config:
"user_config": {
"platforms": {
"type": "enum",
"title": "Platforms to Monitor",
"options": ["PlatformA", "PlatformB", "PlatformC"],
"multiple": true,
"default": ["PlatformA", "PlatformB"],
"required": false
}
}UI behavior:
- Renders as dropdown (single) or multi-select (when
multiple: true) - Validates at configuration time
- Clear set of supported values
Alternative Syntax
Could also extend existing string type:
"platforms": {
"type": "string",
"enum": ["PlatformA", "PlatformB", "PlatformC"],
"multiple": true
}Benefits
- Prevents user errors - No typos or unsupported values
- Better UX - Dropdown selection vs manual typing
- Clear expectations - Users see exactly what's supported
- Validation - Errors caught at config time, not runtime
Related
Similar to how directory and file types provide specialized UI (file pickers), enum would provide specialized UI (dropdowns/multi-select).
Metadata
Metadata
Assignees
Labels
No labels