-
Notifications
You must be signed in to change notification settings - Fork 46
Description
Description
When using MCP guardrails for data modification or masking, the changes applied in async_pre_call_hook are not reflected in async_moderation_hook.
Expected Behavior
The arguments modified in async_pre_call_hook should be passed to async_moderation_hook, so that tool call happens on the updated data instead of the original request.
Actual Behavior
async_moderation_hook receives the original unmodified arguments, causing masking or modification logic to fail.
Root Cause
In the original mcp_server_manager.py, the method self.pre_call_tool_check() does not return any value.
As a result, the original arguments are used in subsequent steps (including moderation).
My Observation / Suggested Fix
While debugging, I found that the issue occurs because self.pre_call_tool_check() does not return the modified arguments.
When I locally updated the call_tool method in mcp_server_manager.py to capture and reassign the returned arguments, the issue was resolved.
(Sample code for reference)
modified_argument = await self.pre_call_tool_check(
name=original_tool_name,
arguments=arguments,
server_name_from_prefix=server_name_from_prefix,
user_api_key_auth=user_api_key_auth,
proxy_logging_obj=proxy_logging_obj,
server=mcp_server,
)
if modified_argument is not None:
arguments = modified_argumentAfter this change, the modified arguments from async_pre_call_hook are correctly passed to async_moderation_hook, and the masking logic works as expected.
This is just an observation from my local testing.
Tested On
LiteLLM version: 1.78.0
Context: MCP guardrails (async_pre_call_hook + async_moderation_hook)