feat: Add enabled field to plugin configuration to control plugin load

[crivetimihai]

feat: Add enabled field to plugin configuration to control plugin loading

Implements plugin enable/disable functionality as requested in issue #679. Individual plugins can now be enabled or disabled via the 'enabled' field in plugins/config.yaml.

Changes Made

Schema Updates

• Add enabled: bool = True field to PluginConfig model in framework/models.py
• Defaults to True for backward compatibility with existing configurations
• Field is properly validated by Pydantic schema

Plugin Loading Logic

• Update PluginManager.initialize() in framework/manager.py to check enabled field
• Plugins are only loaded if both enabled=True AND mode \!= DISABLED
• Added descriptive logging to distinguish between disabled methods:
  • "enabled=false" for plugins disabled via enabled field
  • "mode=disabled" for plugins disabled via mode field

Configuration Examples

• Update plugins/config.yaml to demonstrate usage:
  • PIIFilterPlugin and ReplaceBadWordsPlugin: enabled=true
  • DenyListPlugin: enabled=false (example of disabled plugin)
• Add inline comments explaining the field usage

Key Features

✅ Backward Compatible: Existing configs without 'enabled' default to true
✅ Dual Control: Plugins can be disabled via enabled=false OR mode=disabled
✅ Clear Logging: Descriptive messages distinguish disabling methods
✅ Schema Validation: New field properly validated by Pydantic
✅ Comprehensive Testing: All doctests and unit tests passing (1190 passed)

Testing

• Schema validation confirmed working with new enabled field
• Plugin loading logic tested with both enabled=true/false scenarios
• Configuration loading successfully validates YAML with new field
• All existing tests pass, confirming backward compatibility maintained
• Code coverage maintained at 80%

Closes #679

[imolloy]

Maybe swap these? I think the mode is the coarser level of granularity and might take precedence for the debug statement.

[terylt]

Hi @crivetimihai

Nice updates. My one comment is just about the difference between mode=disabled and enabled=True. Is there a case where we'd use on over the other? My thought would be if we want to break enabled out separately, we could have mode just be enforce/permissive.

Is there a use case where we would need both?

[araujof]

Nice updates. My one comment is just about the difference between mode=disabled and enabled=True. Is there a case where we'd use on over the other? My thought would be if we want to break enabled out separately, we could have mode just be enforce/permissive.

Is there a use case where we would need both?

My thoughts, exactly. We define the enabled/disabled state in the mode.

mcp-context-forge/mcpgateway/plugins/framework/models.py

Lines 32 to 43 in 70f1a7e

	class PluginMode(str, Enum):
	"""Plugin modes of operation.
	Attributes:
	enforce: enforces the plugin result.
	permissive: audits the result.
	disabled: plugin disabled.
	"""
	ENFORCE = "enforce"
	PERMISSIVE = "permissive"
	DISABLED = "disabled"

Do you prefer to have it as a new field instead? If so, we could remove the DISABLED mode from the enum, simplifying a bit the usage and implementation.

Maybe, the question is whether CF allows the PluginConfig options to be changed without reloading the server. If not, how do we differentiate the semantics between the config's enabled flag and the plugin model DISABLED state?