feat: propose an optional Baizhi Agent Toolkit MCP preset

Feature Request

Hi Langflow team,

I maintain the Baizhi Cloud Agent Toolkit integrations and coordinate product operations. I am participating through ct-jaryn on behalf of Baizhi Cloud. We would like to contribute an optional Baizhi Agent Toolkit MCP preset, subject to your integration and bundle inclusion policies.

Baizhi Agent Toolkit is a hosted commercial MCP tool service for web search, page reading, and structured extraction. It is not an LLM inference provider. Users supply their own Baizhi account and API key; tool usage can consume service credits. Our official integration repository contains integration configuration, documentation, and tests, not the hosted backend source code.

Proposed user flow

1. Add an optional Baizhi Agent Toolkit preset from the component palette, in the location agreed with maintainers.
2. Enter a personal API key through Langflow's existing SecretStrInput / credential-variable mechanism. Provide a link to the service console and make account, cost, and data-transfer requirements visible. The user enters the key itself, without an extra Bearer prefix.
3. On explicit connection or tool refresh, use the fixed HTTPS endpoint https://agent-toolkit.app.baizhi.cloud/mcp, Streamable HTTP, and Authorization: Bearer <user-provided key>.
4. Inspect discovered tools, then connect the component's Toolset output to an Agent's Tools input. A proposed initial scope is websearch_search, web_scrape, and web_extract; this must be an actual toolset restriction if approved, not merely the selected value in a direct-response dropdown. Additional tools would remain an explicit user choice.

This would reuse the existing MCP engine, not introduce a vendor SDK, local proxy process, separate HTTP stack, automatic tool execution, or a model-provider change. Adding the component should not contact the service until the user deliberately connects or refreshes it.

Motivation

Langflow already supports configuring this transport through MCP Tools, so this is not a request to add generic MCP support. Manual configuration remains a valid alternative, including a Credential global variable containing the complete Bearer header value, as your MCP client documentation describes.

The incremental value would be a discoverable, maintained preset: fixed endpoint and transport, a dedicated key input instead of hand-assembling an Authorization header, a clearly limited initial toolset, and service-specific setup/troubleshooting documentation. We would like to confirm that this benefit justifies a curated integration rather than assume that every compatible MCP service belongs in Langflow.

Existing implementation to reuse

Source review at 5621dcfd84e11108e4cc1ecb0c51f41053c4211c found:

• MCPPresetComponent already provides a shared fixed-server component pattern, MCP tool loading, and an Agent Toolset output. Its current Tool Mode exposes the loaded tools; the proposed initial restriction needs explicit implementation and tests.
• WatsonxDataMCPComponent is an existing preset using Bearer headers and Streamable_HTTP through that shared engine.
• SecretStrInput marks the input as a password, supports database-backed values, and disables value tracking in telemetry. Masked input alone is not evidence that every persistence, export, or error path is safe; those paths would be verified for this integration.

We would follow your current package/bundle placement guidance rather than add another generic MCP client implementation.

Your Contribution

If this direction is welcome, we can contribute the agreed preset, documentation, and tests, and maintain the integration with your team. Before implementation, could you confirm whether a curated preset is appropriate and which bundle/package and release branch it should target? If an external bundle, template, or documentation-only example is preferred, we would welcome that direction instead.

Proposed acceptance checks:

• Missing or canceled key input makes no authenticated connection and does not overwrite unrelated server or credential settings.
• A synthetic credential is bound only to the fixed Baizhi endpoint's Authorization header in a local mock MCP test; TLS verification stays enabled. Redirect and error handling must not disclose the credential.
• Keys are excluded from logs, telemetry, model-visible content, and shared flow exports. Credential-variable storage, replacement, saved-flow reload, and removal follow Langflow's existing user-scoping rules and are tested explicitly.
• Tool discovery refreshes from the server; the proposed initial three-tool scope is enforced on the Agent Toolset output. Refresh does not execute a tool or silently expose every newly discovered capability.
• Tests cover authentication failure, unavailable service, empty tool lists, key replacement, component/flow reload, and unaffected generic MCP components.
• Documentation covers setup, connection verification, tool selection, credential rotation/revocation, removing the component, and data/credit implications. Tool inputs are sent to the hosted service; users should not submit sensitive material without their organization's approval.
• Any live-account test is opt-in and recorded separately from mocked/source-review results. Public CI will not contain a real API key or call paid tools.

We have reviewed the relevant source and contribution guidance; we have not completed a Baizhi-specific Langflow implementation or real-key end-to-end test and are not claiming one. No API key is included in this request. We understand that an eventual PR must target the active release-X.Y.Z candidate branch, not main, and will re-confirm the appropriate branch before opening it.

Thank you for considering the proposal. We would be glad to collaborate on a focused integration that fits Langflow's architecture, security expectations, and maintenance standards.