BerriAI/litellm · error · ValueError

No guardrail translation mapping found for call_type: {call_

Error message

No guardrail translation mapping found for call_type: {call_type}. Available mappings: {list(endpoint_guardrail_translation_mappings.keys())}

What it means

Raised by get_guardrail_translation_mapping when the requested call_type has no registered guardrail translation handler. Mappings are lazily discovered via discover_guardrail_translation_mappings(), which collects handlers (including MCP guardrail translation mappings from litellm.proxy._experimental.mcp_server.guardrail_translation) keyed by CallTypes. Requesting a call type outside the discovered set — or when discovery silently failed — raises this ValueError, and the message lists the valid keys so you can self-correct.

Source

Thrown at litellm/llms/__init__.py:178

    Args:
        call_type: The type of call (e.g., completion, acompletion, anthropic_messages)

    Returns:
        The translation handler class for the given call type

    Raises:
        ValueError: If no translation mapping exists for the given call type
    """
    global endpoint_guardrail_translation_mappings

    # Lazy load the mappings on first access
    if endpoint_guardrail_translation_mappings is None:
        endpoint_guardrail_translation_mappings = discover_guardrail_translation_mappings()

    # Get the translation handler class for the call type
    if call_type not in endpoint_guardrail_translation_mappings:
        raise ValueError(
            f"No guardrail translation mapping found for call_type: {call_type}. "
            f"Available mappings: {list(endpoint_guardrail_translation_mappings.keys())}"
        )

    # Return the handler class directly
    return endpoint_guardrail_translation_mappings[call_type]

View on GitHub (pinned to 6c2dcb801b)

Solutions

1. Read the message: it lists the available call types — switch your call to one of those.
2. If you need the unsupported call type, implement and register a BaseTranslation handler for it in the guardrail translation mappings dict.
3. Check litellm logs for 'Error discovering guardrail translation mappings' — a failed import (e.g. missing optional deps) may have emptied the mappings; fix the import error and restart.
4. Upgrade/downgrade litellm so the CallTypes enum and translation handlers are from the same release.

Example fix

# before
handler = get_guardrail_translation_mapping(CallTypes.RERANK)  # not registered

# after (register a handler, or use a supported call type)
from litellm.proxy._experimental.mcp_server.guardrail_translation import guardrail_translation_mappings

class RerankGuardrailTranslation(BaseTranslation):
    ...

guardrail_translation_mappings[CallTypes.RERANK] = RerankGuardrailTranslation
handler = get_guardrail_translation_mapping(CallTypes.RERANK)

from litellm.llms import load_guardrail_translation_mappings

def supports_guardrail_translation(call_type) -> bool:
    return call_type in load_guardrail_translation_mappings()

from litellm.llms import load_guardrail_translation_mappings

def is_supported_call_type(call_type) -> bool:
    try:
        return call_type in load_guardrail_translation_mappings()
    except Exception:
        return False

try:
    handler = get_guardrail_translation_mapping(call_type)
except ValueError as e:
    raise HTTPException(400, f"unsupported call type: {e}")

When it happens

Trigger: Calling get_guardrail_translation_mapping(call_type) with a CallTypes enum member that has no registered translation handler — e.g. a rarely-used call type (embeddings, rerank, transcription) when only completion/anthropic-style handlers installed; or when discovery hit an exception (logged as 'Error discovering guardrail translation mappings') leaving an empty/partial mapping cache.

Common situations: Extending the MCP guardrail server to a new endpoint whose call type lacks a handler; version drift between litellm core CallTypes enum and the proxy experimental MCP package (new call types added before handlers); an ImportError inside discovery silently shrinking the mapping set; typos/renames of CallTypes values across versions.

Related errors

• Setting tag based guardrail modes is only available in litel
• Unsupported call_type={call_type!r} for compression. Expecte
• Missing botocore to use AWS SigV4 authentication. Run 'pip i
• No AWS credentials found. Provide aws_access_key_id and aws_
• stdio_config is required for stdio transport

AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/29311865f6f3d30b. Report an issue: GitHub.