LiteLLM

LiteLLM — litellm-algenta

A config generator, linter, and per-profile YAML templates for LiteLLM's MCP Gateway — not a library wrapper. LiteLLM's gateway is a proxy server process configured by YAML; there is no AlgentaToolset to call. The honest shape of "integrating a proxy" is generating and validating its config, and testing that config against the real proxy.

Install

pip install litellm-algenta      # generator + linter; needs nothing but pyyaml
pip install 'litellm[proxy]'     # separately, only when you actually run the gateway

Quickstart

from pathlib import Path
from litellm_algenta.config import build_mcp_server_entry, merge_into_config_file

fragment = build_mcp_server_entry(profile="observe", server_name="algenta")
merge_into_config_file(Path("config.yaml"), fragment)  # idempotent — re-run-safe

export ALGENTA_MCP_URL="http://localhost:8000/mcp"   # your own self-hosted engine
export ALGENTA_MCP_TOKEN="..."                        # your engine's bearer credential
litellm --config config.yaml --port 4000

Or without writing Python: python -m litellm_algenta.config --profile observe --merge-into config.yaml, or start from a checked-in template — configs/observe.yaml / govern.yaml / execute.yaml / full.yaml (regenerated from code by scripts/render_configs.py; CI fails if they drift).

Profiles

All four, mapped onto LiteLLM's real, call-time-enforced allowed_tools — and for execute_decision, allowed_params restricting its arguments. full omits allowed_tools (LiteLLM's own "unrestricted") but still gets the allowed_params scrub — the never-model-facing rule admits no exceptions. See Tool Contract.

Notes

• Verified against a real litellm proxy (1.98.0): calling a tool outside allowed_tools gets a real 403 from the gateway itself, even if a caller bypasses the filtered tools/list; force: true against allowed_params gets a real 403 before the upstream is contacted. This satisfies the contract's server-side-enforcement requirement.
• What the gateway genuinely cannot do, said plainly: it cannot strip force/override_safety from the advertised schema (the engine's job, not a config key); it has no approval-pause primitive (the real tool never needs one — denials arrive as isError: true with the gate inside); response headers don't round-trip (correlate by the receipt's decision_id).
• lint_mcp_server_entry / assert_safe work on hand-written configs too — catching a missing scrub, an Algenta-hosted URL, or a malformed oauth2 block before litellm starts.
• Auth: gateway→engine auth (bearer_token, oauth2, true_passthrough, …) is a separate plane from caller→gateway keys; mid-session 401 behavior differs per type (the README's table has the verified details).
• Tests: spawn a real litellm proxy subprocess in front of a real stub MCP server — uv run pytest litellm-algenta -v.

Full reference: package README (auth-type table, trace headers, why no algenta-sdk dependency).