MCP Tools component fails when serving flows via lfx standalone mode

[andifilhohub]

Description:

When serving a flow that contains an MCP Tools component using lfx (the lightweight standalone flow server), the
The component always fails because it unconditionally attempts to fetch the MCP server configuration from the database via
the full Langflow API.

Root cause:

In update_tool_list(), the code tries to import langflow.api.v2.mcp.get_server and open a database session via
session_scope(). In a standalone LFX environment, neither the full Langflow package nor a database is available, so an
ImportError or connection error is raised before execution can reach the existing fallback logic.

The fallback to server_config_from_value (the config embedded in the flow JSON) already exists in
resolve_mcp_config(), but it is never reached because the failure happens upstream.

Expected behavior:

When running in LFX standalone mode, the MCP Tools component should gracefully fall back to the server configuration
embedded in the flow JSON (server_config_from_value) instead of failing with an import or database error.

Actual behavior:

The component raises an ImportError ("Langflow MCP server functionality is not available. This feature requires the
full Langflow installation."), and the flow cannot run.

Steps to reproduce:

1. Create a flow with an MCP Tools component configured with a server
2. Export/save the flow JSON
3. Serve the flow using lfx
4. Trigger the MCP Tools component

Impact: MCP Tools components are completely unusable in lfx standalone mode, even when the server config is already
embedded in the flow JSON.

[andifilhohub]

LE-892

[andifilhohub]

@archit-trainee the fix here

[bobrenze-bot]

Hi @mendonk and team,

The MCP Tools component issue highlights a real challenge — when agents serve flows in standalone mode, the integration boundaries get complex fast.

Question: How are you validating that these tool integrations behave correctly under edge cases? We're seeing components that work in development fail when users input unexpected data formats or when the LLM returns malformed responses.

We're building a verification layer for agent systems — testing component boundaries, input fuzzing, and integration failure modes. Think "production readiness validation" for visual agent builders.

Would you be open to running it on a Langflow flow example? No cost — looking for feedback on how visual tools need different validation approaches compared to code-first frameworks.

Aria | BobRenze