Proposal: declarative remote MCP extensions with native BYOK onboarding — Baizhi Agent Toolkit

[ct-jaryn]

Hello AionUi maintainers,

I'm ct-jaryn, an official maintainer and operations representative of Baizhi Cloud. We would welcome the opportunity to contribute a maintainable integration for Baizhi Agent Toolkit, subject to your preferred scope and review process.

This is a hosted MCP tool service, not a model provider or ACP agent. It offers tools through Streamable HTTP at https://agent-toolkit.app.baizhi.cloud/mcp, authenticated with the user's own Bearer API key. Initial validation scenarios would use websearch_search, web_scrape, and web_extract; these examples are not the complete service catalog or an implemented three-tool restriction. A Baizhi account and key are required, and calls may consume service credits. The public integration repository contains configuration, documentation, and tests, not the commercial hosted backend's source code.

Existing extension direction

We would like to reuse the existing Extension/AionHub infrastructure, not introduce another marketplace or plugin format. This proposal is narrower than #954 and #3924: it concerns accepting a pure remote MCP contribution and providing its configuration step, not redesigning extension distribution or per-Assistant assignment.

At AionUi commit 6744099, the examples already declare HTTP MCP contributions. However, the existing Hub agent selector filters for acpAdapters, and the published AionHub index contains seven ACP integrations. We have not established that adding a pure MCP manifest alone would provide a discoverable installation flow or a native secure credential prompt.

Proposed minimum scope

Would you consider a declarative remote MCP extension, with no local server wrapper or installation script, together with an upstream-approved native configuration flow?

• A clearly identified remote-service entry with a fixed HTTPS endpoint, initially unconfigured and inactive.
• A required, masked API-key input and explicit user confirmation before connection; cancellation or a missing key must not initiate authentication.
• An agreed secure credential/reference mechanism, with no real key committed, embedded in the manifest, exported as ordinary configuration, or exposed in logs. We are requesting this capability, not claiming it already exists.
• Documentation covering BYOK, possible charges, what data is sent to Baizhi, revocation, removal, and the existing per-Assistant controls.
• Preserve user enablement and tool approvals; no model configuration changes, automatic approval, or claim that every service tool is read-only.

We can contribute the manifest, documentation, and focused tests after the scope is agreed. Acceptance should cover selection, credential entry, cancellation, invalid credentials, restart/persistence, actual tool discovery and approvals, and backend-specific compatibility. No AionUi runtime integration or real-key end-to-end test has been completed for this proposal, and no production credentials would be posted to GitHub.

Does this fit your roadmap, and how would you prefer to divide an accepted proposal across AionUi, AionCore, and AionHub? We are happy to adapt to your existing design and collaborate on review and ongoing maintenance. Thank you for considering it.

[github-actions[bot]]

Thanks for posting! @IceyLiu will take a look soon. / 感谢发帖！@IceyLiu 会尽快跟进。