Scott Wilson 9858d021ee fix(guardrails): record MCP tool guardrail evaluations and blocks in usage monitor ... MCP tool calls run their guardrails against a throwaway LLM-shaped dict built by `ProxyLogging._convert_mcp_to_llm_format`, not against the dict the tool call is logged from. `@log_guardrail_information` therefore appended `standard_logging_guardrail_information` to that throwaway dict's metadata bucket, where `get_standard_logging_object_payload` never saw it, so the Guardrails Monitor reported zero evaluations and zero blocks for all MCP traffic. Thread the request's `litellm_logging_obj` into `pre_call_tool_check` and `_create_during_hook_task` and bridge the guardrail records onto it: - Seed `data["litellm_logging_obj"]`, which unified guardrails read and pass into `apply_guardrail`. - Call `_sync_guardrail_info_to_logging_obj` in a `finally`, which is what native guardrails need and what makes the block path work: a blocked call raises straight out of `pre_call_tool_check`, so the record has to be attached before the exception leaves the frame. Only the guardrail evaluation records are copied. The synthetic request's messages and tool arguments are deliberately left behind -- they can carry end-user data and nothing in the monitor needs them. In `call_mcp_tool`, flush the failure handlers before `post_call_failure_hook` so the `status="failure"` standard logging object exists when `_ProxyDBLogger.async_post_call_failure_hook` writes the spend-log row the monitor's "Total Blocked" counts. Both handlers gate on `should_run_logging("sync_failure")` / `("async_failure")` and then mark it, so the `@client` wrapper's own post-raise logging is a no-op and nothing is double-counted -- the same pattern `_fire_mcp_tool_call_logging` already uses for `isError=True`. Threaded through every MCP tool entry point: the managed-server path, the local-OpenAPI registry path, the legacy registry fallback, and the Responses API's `_execute_tool_calls`.		2026-08-14 17:52:36 -04:00
..
mcp_server	fix(guardrails): record MCP tool guardrail evaluations and blocks in usage monitor	2026-08-14 17:52:36 -04:00