[Feature] Remote MCP catalog entries with user API-key input — Baizhi Agent Toolkit proposal

Problem Description

Hi Chatbox 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, user-configured integration for Baizhi Cloud Agent Toolkit. This is a hosted commercial MCP tool service, not an LLM inference provider. A user supplies their own account and API key; tool usage consumes service credits.

The intended flow is find the entry → enter a personal key → connect and inspect tools → save/enable. We are opening this feature request to confirm whether you would welcome the integration and agree on the shared remote-entry and credential design before submitting code.

Current implementation

Source review at 0cf406cbd93197a89487c740cb101bef36641d35 indicates:

• The custom MCP form already accepts a remote URL and HTTP headers, with connection testing and tool display.
• However, the registry entry type only describes command, args, and optional env.
• Selecting a registry entry currently constructs a stdio transport. Adding only a URL to that catalog would therefore not deliver the intended remote installation flow.

Manual remote configuration is a possible alternative, but it leaves users constructing an Authorization header themselves and does not provide a dedicated masked key-entry experience.

Proposed Solution

We propose a small, reusable remote-MCP catalog capability, with Baizhi as an optional entry only if it meets your inclusion policy:

1. Extend the registry configuration to represent the existing HTTP transport as well as stdio, and preserve the declared transport when opening the install form. Do not add a local proxy process or change model-provider behavior.
2. Declare a required secret input named BAIZHI_API_KEY, with a masked field and a link to the Baizhi console. The user enters the key only, without the Bearer prefix. Bind it as Authorization: Bearer <user-provided key> for the fixed endpoint https://agent-toolkit.app.baizhi.cloud/mcp using Streamable HTTP. Do not put a usable key, credentials, or a nonfunctional environment placeholder in the public catalog.
3. Require explicit user confirmation before connection or enabling. Blank/canceled input should neither connect nor save a partial entry. Keep credentials out of logs, telemetry, model-visible content, exports intended for sharing, and error messages. We would follow the credential-storage approach agreed with maintainers; masking alone must not be described as encrypted storage.
4. Reuse connection testing and discovered-tool display. Document account/credit requirements, key replacement and revocation, which data is sent to the remote service, and disabling/removing the entry. A minimal initial web-research selection would be websearch_search, web_scrape, and web_extract where the client supports selecting individual tools; do not imply that listing the server automatically enforces this filter.

We are happy to contribute the agreed UI/configuration changes, English and Chinese setup documentation, and regression tests. Catalog placement and any verification or endorsement labels should remain your decision.

Proposed acceptance checks

• Existing stdio entries, custom HTTP servers, and JSON import keep working.
• The remote catalog entry opens with the correct URL/transport and a masked required key input.
• Empty/canceled input makes no network request and leaves existing settings unchanged.
• A synthetic key reaches only the expected Authorization header in a local mock MCP test and is absent from captured logs, telemetry, and shared exports.
• Connection failure, key replacement, restart, disabling, and removal have clear behavior and preserve unrelated servers.
• Real-account testing is recorded separately; an installed entry is not presented as authenticated until connection/tool discovery succeeds.

Additional Context

• Official integration repository: chaitin/baizhi-agent-toolkit. It publishes integration manifests and documentation, not the hosted backend source code.
• Published MCP metadata: io.github.ct-jaryn/[email protected]. Registry publication does not imply Chatbox approval or a verified Chatbox connection.
• This request is based on source review. We have not completed a real-key Chatbox end-to-end test and are not claiming one. No API key is included.

Would this shared remote-entry approach and optional Baizhi listing fit your roadmap? If you prefer a documentation-only integration or a different discovery channel, we would welcome that guidance. Thank you for considering the proposal; our team would be glad to collaborate on implementation, testing, and ongoing maintenance.