feat: add Baizhi Agent Toolkit to the MCP integration catalog

[ct-jaryn]

Motivation

Hi OpenHands team,

I maintain Baizhi Cloud's Agent Toolkit integrations and coordinate product operations. I am submitting this proposal through ct-jaryn on behalf of Baizhi Cloud, and would welcome the opportunity to maintain a focused integration with your community.

Baizhi Agent Toolkit is a hosted commercial MCP service for web search, page scraping, and structured extraction. It is a tool service, not an LLM inference provider. Each user supplies their own Baizhi account and API key; tool calls can consume service credits. The official integration repository contains integration configuration, documentation, and tests, not the hosted backend's source code.

OpenHands already supports remote MCP servers. The proposed addition is a discoverable catalog entry using that existing implementation, not another MCP client or provider-specific runtime.

Desired Behavior

Add baizhi-agent-toolkit to integrations/catalog/ with one connection option:

• Transport: shttp (Streamable HTTP).
• Fixed endpoint: https://agent-toolkit.app.baizhi.cloud/mcp.
• Authentication: the catalog's existing bearer strategy, with a required Baizhi API key and a console link in the credential help text. Users enter only the key, without the Bearer prefix.
• Existing Agent Canvas installation UI: select the entry, enter the key in its password field, then explicitly install/connect. No local proxy, OAuth client, or model-provider change is needed.
• Visible account, service-credit, and data-transfer guidance. The full discovered tool set is determined by the server; this metadata does not enforce a three-tool allowlist or automatically approve tools.

The entry would not set a popularity rank, claim OpenHands endorsement, or additionally copy the MCP credential into an automation secret. Credential persistence remains the responsibility of the existing host flow; a masked field alone is not a claim of verified encryption across deployments.

Acceptance Criteria

• The new entry validates against the catalog schema and is returned by the JavaScript and Python MCP catalog APIs, but not the OAuth-only filter.
• The generated catalog index is in sync; no separate provider catalog or application-specific runtime is introduced.
• The fixed HTTPS URL, required Bearer credential, console link, and cost/tool-scope disclosures are covered by a catalog regression test.
• In a supported Agent Canvas build consuming the proposed catalog, missing input cannot install the server; cancellation does not change existing server settings; the key field is masked and the payload uses the fixed endpoint and Bearer credential type.
• Before claiming production compatibility, perform a separately authorized live test covering discovery, an explicitly chosen tool, key replacement, failure handling, and removal. Public CI and artifacts contain no real API keys.

Proposed Contribution and Validation

A small catalog contribution is prepared against OpenHands/extensions@3b31849893dbd665e7bfd92afc313524cccef7f6: one hand-authored JSON entry, the generated index, and a catalog contract test. npm run build:integrations and the three relevant catalog test modules pass locally (117 tests).

The existing password input, required-key validation, fixed-URL handling, and explicit submission path were reviewed in OpenHands/OpenHands@9737f713616a1e452f822c2967f0e2c8bf2dc308. This is source review, not a completed Agent Canvas UI or real-key end-to-end test. The Cloud path's synthetic connection result must not be reported as production verification.

Please let us know if the curated catalog is the appropriate place for this hosted service. We are happy to adjust the presentation and complete the agreed compatibility checks. We will preserve the repository's human-test checkbox and readiness requirements; this request does not imply a partnership or prior approval.

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label):

• The ### Actual Behavior section must describe reproducible steps
  and include a command such as uv run pytest, pytest, python,
  pip, npm run, or node.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] ...).

Enhancements (enhancement label):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• The issue has neither the bug nor enhancement label, so its readiness criteria cannot be evaluated. Add the appropriate label.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

This is an automated readiness check posted by a workflow.