mirror of
https://github.com/langflow-ai/langflow.git
synced 2026-07-24 15:47:29 +08:00
3bc012440f
* fix(mcp): support real-time tool onboarding via per-request auth headers
Problem
-------
When Langflow runs an agent that has an MCPTools component attached and an
API request supplies authentication headers via tweaks, the MCP server can
legitimately return an *expanded* tool list that is broader than the
unauthenticated base set (the server filters its listing by the caller's
identity). Today those extra tools never reach the agent at runtime: the
component always binds the first preloaded tool list and ignores the new
auth context for the lifetime of the flow.
Root cause
----------
Several caching / binding layers combine to prevent per-request tool
refresh:
1. Flow JSON persists ``component_as_tool`` with ``cache: true`` and
Langflow's ``Output`` memoization reuses the first ``to_toolkit()``
result for all subsequent requests regardless of headers.
2. The shared MCP server cache was keyed by server name only, so
requests with different auth contexts collided on the same cache slot.
3. In tool-mode, ``_get_tools()`` returned ``[]`` when
``_not_load_actions`` was true, starving the agent of MCP tools.
4. Concurrent ``update_tool_list`` calls raced on the same Streamable
HTTP client session, producing intermittent HTTP 404 /
"Session terminated" errors from the MCP SDK.
What changed
------------
``src/lfx/src/lfx/components/models_and_agents/mcp_component.py``:
- FIX 1 - Output cache bypass: ``_build_tool_output`` declares the
Toolset output with ``cache=False``, and ``map_outputs`` overrides any
``cache: true`` value persisted in saved flow JSON. Together these
guarantee every run resolves a fresh ``to_toolkit()`` call regardless
of whether the flow was loaded from disk. Independent of the
user-facing ``use_cache`` / "Use Cached Server" toggle.
- FIX 2 - Header-aware cache key: ``_mcp_servers_cache_key`` now hashes
the component headers into the shared server-cache key so requests
with different auth contexts land in distinct cache slots instead of
masking each other. The shared cache is bounded at
``SHARED_SERVERS_CACHE_MAX_ENTRIES`` = 64 with FIFO eviction so a
tenant rotating session tokens does not grow the map without limit.
- FIX 3 - ``_get_tools`` always fetches: removed the ``_not_load_actions``
short-circuit that returned ``[]`` in tool-mode, so the agent always
binds the current (possibly expanded) tool list. ``_not_load_actions``
still gates only the UI build_config dropdown.
- FIX 4 - Serialized ``update_tool_list``: an ``asyncio.Lock`` prevents
concurrent refreshes from racing on the same Streamable HTTP client
session, eliminating the intermittent HTTP 404 / "Session terminated"
errors the MCP SDK raised when session DELETE and POST overlapped.
- FIX 5 - TTL tool cache: ``_get_tools`` keeps a per-instance,
header-hash-keyed TTL cache (``TOOL_TTL_SECS`` = 30s, disable with 0)
bounded at ``TOOL_TTL_MAX_ENTRIES`` = 32 with FIFO eviction and
stale-on-read drop. Parallel agent steps that share the same auth
reuse the tool list instead of each paying for a fresh MCP round-trip.
This is deliberately distinct from ``use_cache`` / "Use Cached Server"
which controls the cross-request shared cache. The dict is initialized
in ``__init__`` so every instance gets its own cache.
Impact on users
---------------
- Backward compatible. Unauthenticated / non-tweaked flows behave
identically: the TTL cache is per-instance and scoped to a single
(server, header-hash) pair, and the base-class ``to_toolkit`` chain is
unchanged (no override of filtering via ``tools_metadata`` /
``enabled_tools``).
- New behaviour only triggers when tweaks/UI headers include an auth
context; the header-hash cache key then isolates per-caller tool lists
and the agent binds the correctly-filtered expanded set.
- No changes to ``lfx/services/settings/base.py``: the global
``mcp_server_timeout`` default stays at its existing value.
Test plan
---------
- ``python -m py_compile`` passes on the edited module.
- ``python -m ruff check`` reports no new violations introduced by this
change.
- Local verification against an MCP server that returns different tool
lists per caller identity:
* Unauthenticated request returns the base tools as before.
* Authenticated request (auth headers via tweaks) returns the
expanded tool set on the first call and on subsequent calls with
the same auth - TTL cache hits log
``MCP _get_tools: TTL cache hit``.
* Switching to a different auth context on the same flow returns the
correct per-caller tool list (header-hash cache key isolates the
two contexts).
* Parallel agent runs no longer surface HTTP 404 / "Session
terminated" from the MCP SDK.
* Disabling a tool via the UI (``tools_metadata``) correctly hides it
from the bound agent - base-class filtering is preserved.
* [autofix.ci] apply automated fixes
* [autofix.ci] apply automated fixes (attempt 2/3)
* [autofix.ci] apply automated fixes (attempt 3/3)
* test(mcp): cover dynamic-tool onboarding fixes
Add unit coverage for the fixes introduced in this PR so regressions in the
cache-key, TTL cache, concurrency lock, shared-cache eviction, and Toolset
Output.cache=False behaviour are caught by CI instead of by users:
- Header normalization across list / dict / None / malformed shapes
- `_mcp_servers_cache_key` determinism + header-hash scoping across auth
contexts (different headers → different keys; order-independent)
- Per-instance `_ttl_tool_cache` isolation (no cross-instance leakage)
- `_get_tools` TTL cache: hit skips `update_tool_list`, expired entries are
refetched, FIFO-eviction caps growth at `TOOL_TTL_MAX_ENTRIES`, and TTL=0
disables the cache
- `_update_tool_list_lock` serialises concurrent calls (peak concurrency 1)
- Shared `servers` cross-request cache evicts oldest entry when the map
reaches `SHARED_SERVERS_CACHE_MAX_ENTRIES`
- `_build_tool_output` declares `cache=False`; `map_outputs` overrides
persisted `cache=True` from saved flow JSON
* [autofix.ci] apply automated fixes
---------
Co-authored-by: Mansura <mansura.nw@gmail.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Eric Hare <ericrhare@gmail.com>
Langflow is a powerful platform for building and deploying AI-powered agents and workflows. It provides developers with both a visual authoring experience and built-in API and MCP servers that turn every workflow into a tool that can be integrated into applications built on any framework or stack. Langflow comes with batteries included and supports all major LLMs, vector databases and a growing library of AI tools.
✨ Highlight features
- Visual builder interface to quickly get started and iterate.
- Source code access lets you customize any component using Python.
- Interactive playground to immediately test and refine your flows with step-by-step control.
- Multi-agent orchestration with conversation management and retrieval.
- Deploy as an API or export as JSON for Python apps.
- Deploy as an MCP server and turn your flows into tools for MCP clients.
- Observability with LangSmith, LangFuse and other integrations.
- Enterprise-ready security and scalability.
🖥️ Langflow Desktop
Langflow Desktop is the easiest way to get started with Langflow. All dependencies are included, so you don't need to manage Python environments or install packages manually. Available for Windows and macOS.
⚡️ Quickstart
Install locally (recommended)
Requires Python 3.10–3.13 and uv (recommended package manager).
Install
From a fresh directory, run:
uv pip install langflow -U
The latest Langflow package is installed. For more information, see Install and run the Langflow OSS Python package.
Run
To start Langflow, run:
uv run langflow run
Langflow starts at http://127.0.0.1:7860.
That's it! You're ready to build with Langflow! 🎉
📦 Other install options
Run from source
If you've cloned this repository and want to contribute, run this command from the repository root:
make run_cli
For more information, see DEVELOPMENT.md.
Docker
Start a Langflow container with default settings:
docker run -p 7860:7860 langflowai/langflow:latest
Langflow is available at http://localhost:7860/. For configuration options, see the Docker deployment guide.
🛡️ Security
For security information, see our Security Policy.
🚀 Deployment
Langflow is completely open source and you can deploy it to all major deployment clouds. To learn how to deploy Langflow, see our Langflow deployment guides.
⭐ Stay up-to-date
Star Langflow on GitHub to be instantly notified of new releases.
👋 Contribute
We welcome contributions from developers of all levels. If you'd like to contribute, please check our contributing guidelines and help make Langflow more accessible.