- 
                Notifications
    
You must be signed in to change notification settings  - Fork 29
 
Support --allowed-rules filtering with MCP server #358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support --allowed-rules filtering with MCP server #358
Conversation
- Apply global allowedRules setting to MCP server default config - Add allowed_rules parameter to all MCP tool definitions - Update all handler functions to parse and apply allowed_rules parameter - Ensure consistent behavior between CLI and MCP server for rule filtering Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com>
- Add test cases for analyze_manifest with allowed_rules parameter - Verify filtering works correctly with single rule, multiple rules, and non-existent rules - Confirm both global flag and per-request parameter functionality - All tests pass demonstrating successful implementation Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com>
| 
           @copilot We got some linting issues  | 
    
- Remove trailing whitespace in cmd/handle_analyze_manifest_test.go and cmd/mcp_server.go - Replace assert.Len(t, ..., 0, ...) with assert.Empty(t, ...) for testifylint compliance - All tests still pass and functionality remains intact Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com>
          
 ... Fixed all linting issues in commit ac6de7b: 
 All tests continue to pass and the build is successful.  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| 
           @copilot I tested it with an MCP client, basically a coding agent that support MCP server and it appears that even though I configured it with   | 
    
- Modify startMCPServer to create mcpDefaultConfig with global allowedRules applied - Update all handler functions to accept and use the mcpDefaultConfig instead of global config - Add comprehensive test to verify global allowed rules are properly inherited - Handlers now properly inherit global --allowed-rules setting when no per-request rules specified - CLI and MCP server behavior now consistent for global rule filtering Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com>
          
 Fixed the bug in commit 59526f7. The issue was that MCP server handlers were using the global  The handlers now properly inherit the global  Added a comprehensive test that verifies global allowed rules are properly inherited by the MCP server.  | 
    
* Initial plan * Implement --allowed-rules filtering support for MCP server - Apply global allowedRules setting to MCP server default config - Add allowed_rules parameter to all MCP tool definitions - Update all handler functions to parse and apply allowed_rules parameter - Ensure consistent behavior between CLI and MCP server for rule filtering Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com> * Add comprehensive tests for --allowed-rules filtering in MCP server - Add test cases for analyze_manifest with allowed_rules parameter - Verify filtering works correctly with single rule, multiple rules, and non-existent rules - Confirm both global flag and per-request parameter functionality - All tests pass demonstrating successful implementation Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com> * Fix linting issues: gofmt formatting and testifylint violations - Remove trailing whitespace in cmd/handle_analyze_manifest_test.go and cmd/mcp_server.go - Replace assert.Len(t, ..., 0, ...) with assert.Empty(t, ...) for testifylint compliance - All tests still pass and functionality remains intact Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com> * Fix global --allowed-rules flag not being honored by MCP server handlers - Modify startMCPServer to create mcpDefaultConfig with global allowedRules applied - Update all handler functions to accept and use the mcpDefaultConfig instead of global config - Add comprehensive test to verify global allowed rules are properly inherited - Handlers now properly inherit global --allowed-rules setting when no per-request rules specified - CLI and MCP server behavior now consistent for global rule filtering Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: fproulx-boostsecurity <76956526+fproulx-boostsecurity@users.noreply.github.com>
✅ MCP Server --allowed-rules Support Implementation Complete
Problem: The MCP server does not honor the
--allowed-rulesfilter that is available in other CLI commands.Root Cause:
defaultConfig := *configbut doesn't apply the globalallowedRulesvariableallowed_rulesas a parameternewOpaWithConfig()which doesn't inherit the global flag settingsImplementation Plan:
allowed_rulesparameter to MCP server tool definitionsallowed_rulesparameterallowedRulessetting to MCP server's default configTechnical Changes Implemented:
allowed_rulesstring array parameter to all MCP tool definitions usingmcp.WithArray()andmcp.WithStringItems()allowed_rulesparameter usingrequest.GetStringSlice()allowedRulesto the default config instartMCPServer()allowed_rulesparameter is provided--allowed-rulesflag was not inherited by MCP handlersFiles Modified:
cmd/mcp_server.go- Added parameter definitions, handler logic, and fixed global flag inheritancecmd/handle_analyze_manifest_test.go- Added test coverage and fixed lint issuesBug Fix Details:
The original implementation had a critical bug where MCP server handlers used
requestConfig := *configinstead of themcpDefaultConfigthat had globalallowedRulesapplied. This meant that when users ranpoutine mcp-server --allowed-rules injection, the global setting was ignored. The fix ensures all handlers inherit the global configuration properly.Validation Results:
--allowed-rulesfiltering works correctly (baseline confirmed)injectionfilter: Only matching findings returnedImpact:
The MCP server now fully supports
--allowed-rulesfiltering at both:poutine mcp-server --allowed-rules injectionapplies to all requests"allowed_rules": ["injection"]for per-request filteringThis provides consistent behavior between the CLI and MCP server interfaces.
Original prompt
Fixes #357
💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.