[TT-16566] mcp policy filter tools resource prompt lists #7868
probelabs / Visor: architecture
succeeded
Apr 16, 2026 in 55s
✅ Check Passed (Warnings Found)
architecture check passed. Found 3 warnings, but fail_if condition was not met.
Details
📊 Summary
- Total Issues: 3
- Warning Issues: 3
🔍 Failure Condition Results
Passed Conditions
- global_fail_if: Condition passed
Issues by Category
Architecture (3)
⚠️ gateway/reverse_proxy.go:1399 - The Content-Length header is unconditionally deleted and ContentLength is set to -1 whenever any SSE hooks are present. This is overly broad and could have unintended consequences for other hooks that do not modify the body length. The logic should be more targeted to only apply when a hook that is known to modify content, like the new MCPListFilterSSEHook, is active.⚠️ internal/mcp/list_filter.go:181 - TheInferListConfigFromResultfunction relies on a hard-codedlookupOrderslice to resolve ambiguity when a JSON-RPC result contains multiple list keys (e.g., 'tools' and 'prompts'). This creates a brittle dependency on the order of keys, which is not guaranteed. If a future response contains both 'resources' and 'resourceTemplates', it would incorrectly match 'resourceTemplates' first, even if the primary data is in 'resources', because of the hardcoded check order. This design is not robust against future API changes.⚠️ gateway/res_handler_mcp_list_filter.go:105 - ThelistConfigmethod inMCPListFilterResponseHandlerduplicates the logic of mapping a method name to a filter configuration. A similar mapping is needed in the SSE hook, which infers the configuration from response keys. This suggests an opportunity for a more centralized and reusable mapping mechanism within theinternal/mcppackage.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 1403 in gateway/reverse_proxy.go
probelabs / Visor: architecture
architecture Issue
The Content-Length header is unconditionally deleted and ContentLength is set to -1 whenever any SSE hooks are present. This is overly broad and could have unintended consequences for other hooks that do not modify the body length. The logic should be more targeted to only apply when a hook that is known to modify content, like the new MCPListFilterSSEHook, is active.
Raw output
Refactor the logic to only delete the Content-Length header when a hook known to modify the response body is actually added to the chain. This could be achieved by having the `NewMCPListFilterSSEHook` function return an additional boolean indicating it may modify content, or by checking the type of hooks in the `WrappedServeHTTP` function. A more direct approach is to check if `filterHook` is not nil.
Check warning on line 186 in internal/mcp/list_filter.go
probelabs / Visor: architecture
architecture Issue
The `InferListConfigFromResult` function relies on a hard-coded `lookupOrder` slice to resolve ambiguity when a JSON-RPC result contains multiple list keys (e.g., 'tools' and 'prompts'). This creates a brittle dependency on the order of keys, which is not guaranteed. If a future response contains both 'resources' and 'resourceTemplates', it would incorrectly match 'resourceTemplates' first, even if the primary data is in 'resources', because of the hardcoded check order. This design is not robust against future API changes.
Raw output
Instead of relying on a fixed lookup order, the logic should be tied to the original request method if possible. Since the method is not available in the SSE hook context, an alternative is to log a warning when multiple known list keys are detected in a single response, as this likely indicates an unexpected upstream response that should be investigated. For the HTTP handler path, the method is known and should be used directly to select the config, avoiding inference altogether.
Check warning on line 105 in gateway/res_handler_mcp_list_filter.go
probelabs / Visor: architecture
architecture Issue
The `listConfig` method in `MCPListFilterResponseHandler` duplicates the logic of mapping a method name to a filter configuration. A similar mapping is needed in the SSE hook, which infers the configuration from response keys. This suggests an opportunity for a more centralized and reusable mapping mechanism within the `internal/mcp` package.
Raw output
Create a new function in the `internal/mcp` package, such as `GetListConfigForMethod(method string) *ListFilterConfig`, which contains the switch statement. This would centralize the method-to-config mapping, making it reusable and the single source of truth. The `MCPListFilterResponseHandler` can then call this new function, reducing code duplication and improving maintainability.
Loading