Skip to content

[Bug] async_pre_call_hook modifications not reflected in async_moderation_hook (MCP guardrails) #23

@kavyakoppanadham

Description

@kavyakoppanadham

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_argument

After 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)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions