idea: Document Baizhi Agent Toolkit and confirm a secure remote MCP preset path

Problem Statement

Hi Jan maintainers, I maintain and operate Baizhi Agent Toolkit and am proposing this integration on behalf of Baizhi Cloud through ct-jaryn.

Jan already supports remote Streamable HTTP MCP servers and user-supplied Authorization headers. We would like to make our service easier to discover and configure without asking users to copy credentials into a shared JSON example or mistake a hosted service for an offline tool.

Agent Toolkit is a hosted commercial tool service, not a model provider. It requires the user's own Baizhi account and API key; tool calls may consume service credits. Its fixed MCP endpoint is https://agent-toolkit.app.baizhi.cloud/mcp, authenticated with the user's Authorization: Bearer <key>. The public integration repository contains configuration, documentation, and tests, not the hosted backend source.

We reviewed Jan's MCP documentation, the existing disabled third-party entries in DEFAULT_MCP_CONFIG, and the remote server form at main revision 7205d770. At that revision, the Header value field is an ordinary text input, so we do not want to present a new header placeholder as if it already provided a dedicated hidden-key setup flow or independently protected credential storage. This is source review of main, not verification of a stable desktop release.

Feature Idea

Would a focused integration recipe under the MCP documentation be an appropriate first contribution, with a disabled-by-default remote preset only if that fits Jan's intended MCP server discovery design?

The proposed scope would be:

• Document the fixed endpoint, Streamable HTTP transport, user-managed Bearer credential, account requirement, service costs, and the fact that tool inputs are sent to Baizhi's hosted service.
• Keep published configuration free of real keys. If an in-app preset is preferred, first agree on the appropriate reusable credential-input path, including visibility, replacement, persistence, export/backup, and removal behavior, rather than assuming the OAuth token store also protects static headers.
• Preserve explicit user enablement and Jan's tool approvals; do not enable the global allow-all setting, add local commands or hooks, change model settings, or claim all exposed tools are read-only.
• Use web search, webpage reading, and structured extraction as initial verification scenarios. These are examples, not a claim that configuration restricts discovery to three tools.

This request is for direction before implementation. We have not completed Jan desktop installation, authenticated production discovery, or tool-call verification, and are not claiming an accepted listing or partnership. If the direction is welcome, we can prepare the smallest agreed configuration/documentation change, follow the signed-commit and main PR contribution requirements, and clearly report test coverage and remaining limitations.

Product overview · Service console

Thank you for maintaining Jan. We would be glad to collaborate within the project's scope and follow whichever distribution or documentation approach you prefer.