release: v0.22.0 (MCP proxy operator allowlist/denylist for tools/list and tools/call)#113
Merged
Conversation
…t and tools/call Bumps version 0.21.0 → 0.22.0 across pyproject.toml and clients/ts/package.json. Promotes the [Unreleased] CHANGELOG entry to [0.22.0] - 2026-05-20 with explicit Added / Verified / Use case subsections. Updates README MCP proxy section with a paragraph on the new --allow-tool / --deny-tool flags. Extends the mcp_proxy.py module docstring to note the optional filtering behaviour.
📝 WalkthroughWalkthroughRelease v0.22.0 documents the operator-side MCP tool filtering feature. Changelog and README describe the new allow/deny tool flags, their effect on ChangesRelease v0.22.0 Documentation and Versioning
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/vaara/integrations/mcp_proxy.py`:
- Around line 9-12: The module docstring incorrectly says the proxy "forwards
every request" while the implementation optionally filters and blocks some
requests; update the top-level docstring in mcp_proxy.py to state that the proxy
normally forwards requests but, when operator-side filtering
(--allow-tool/--deny-tool) is enabled, it will filter the upstream tools/list
response and may block tools/call at the perimeter (returning a FILTERED block
payload) instead of forwarding them upstream; mention the relevant endpoints
(tools/list, tools/call) and the filtering flags so the contract is unambiguous.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 0c22e8fc-5779-47ee-ba1f-50305d8e8d68
📒 Files selected for processing (5)
CHANGELOG.mdREADME.mdclients/ts/package.jsonpyproject.tomlsrc/vaara/integrations/mcp_proxy.py
Comment on lines
+9
to
+12
| Optional operator-side filtering (``--allow-tool``/``--deny-tool``): when set, | ||
| the proxy filters the upstream's ``tools/list`` response before the client | ||
| sees it, and rejects ``tools/call`` to a filtered tool at the perimeter with | ||
| a ``FILTERED`` block payload, without contacting the upstream. |
There was a problem hiding this comment.
Docstring now conflicts with forwarding semantics.
With filtering enabled, not every request is forwarded upstream (tools/call can be blocked at the perimeter). Please adjust the earlier “Forwards every request” sentence so the module contract is unambiguous.
✏️ Proposed wording adjustment
-Forwards every request to the upstream, but
-routes ``tools/call`` through Vaara's interception pipeline first. Allowed
-calls flow through transparently. Blocked calls return an MCP tool error.
+Forwards MCP traffic to the upstream, with ``tools/call`` routed through
+Vaara's interception pipeline first. Allowed calls flow through transparently.
+Blocked calls (policy or operator filter) return an MCP tool error without
+contacting the upstream.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/vaara/integrations/mcp_proxy.py` around lines 9 - 12, The module
docstring incorrectly says the proxy "forwards every request" while the
implementation optionally filters and blocks some requests; update the top-level
docstring in mcp_proxy.py to state that the proxy normally forwards requests
but, when operator-side filtering (--allow-tool/--deny-tool) is enabled, it will
filter the upstream tools/list response and may block tools/call at the
perimeter (returning a FILTERED block payload) instead of forwarding them
upstream; mention the relevant endpoints (tools/list, tools/call) and the
filtering flags so the contract is unambiguous.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds operator-side tool filtering to the MCP proxy via two new repeatable CLI flags:
--allow-tool NAME: if any are given, only those tools pass through.--deny-tool NAME: those tools are filtered. Denylist wins on overlap.Effects:
tools/listresponses are filtered before the client sees them. The LLM never learns that hidden tools exist.tools/callto a filtered tool is rejected at the perimeter with an MCPisError: truepayload (decision: "FILTERED",reason: "Tool filtered by operator policy"). The upstream is not contacted and the risk pipeline is not invoked.Backward compatible: no flags means current passthrough behavior. The pipeline-based interception path is unchanged for non-filtered tool calls.
Why
The proxy already governs each
tools/callthrough the risk pipeline at runtime. That covers the "is this specific call safe right now" question. It does not cover the "should the LLM ever see this tool at all" question.Example: an MCP client running against
github/github-mcp-serveris exposed to write tools likedelete_repository,create_branch,merge_pull_request. A deployment may want a read-only posture without depending on the LLM to refrain. Denying those tools at the perimeter shapes the LLM's tool surface to match operator policy, independent of the risk score.Small surface, real policy-semantic upgrade: from "score every call" to "score every call AND control what's reachable."
Usage
Read-only against GitHub MCP. Anything else returns
Tool filtered by operator policyon call, and never appears intools/listto begin with.Test plan
pytest tests/test_integrations_mcp_proxy.py— 14 tests pass (8 new, covering denylist drops, allowlist restricts, denylist-wins-on-overlap, no-policy passthrough, filtered tools/call returns block, allowlist tools/call still pipelines)github-mcp-serverwith--deny-tool delete_repositoryand verifytools/listandtools/callboth reject (deferred to follow-up unless reviewer wants it pre-merge)Summary by CodeRabbit
Release Notes v0.22.0
New Features
--allow-tooland--deny-toolCLI flags to control tool exposureDocumentation