[Plugin Request]: Baizhi Agent Toolkit - web search, scraping, and extraction

Plugin Name

Baizhi Agent Toolkit

Function Description

Hi Dify team,

I maintain Baizhi Cloud's Agent Toolkit integrations and coordinate product operations. I am submitting this request through ct-jaryn on behalf of Baizhi Cloud. We would like to contribute and maintain a native Tool Plugin, and would appreciate feedback on whether the following scope fits the Marketplace's expectations for a distinct integration.

Baizhi Agent Toolkit is a hosted commercial tool service, not an LLM inference provider. Users need their own Baizhi account and API key; tool calls can consume service credits. Our official integration repository publishes integration configuration, documentation, and tests, not the hosted backend implementation.

The proposed plugin itself would be free and open source; Baizhi's hosted service usage would be billed separately under its service terms.

Proposed user experience

Install the plugin, authorize it with a required provider-level secret-input and a link to the Baizhi console, then select one of three typed tools in a Workflow or Agent:

• Web search (websearch_search): search public web sources with query, freshness, result-count, and source-filter parameters.
• Read a web page (web_scrape): retrieve a page's content from a user-supplied HTTP(S) URL.
• Extract structured information (web_extract): request specified fields or instruction-driven extraction from a page.

The plugin would use a fixed Streamable HTTP endpoint, https://agent-toolkit.app.baizhi.cloud/mcp, with Authorization: Bearer <user-provided key>. The credential would not be a model-supplied tool parameter. Public examples, source code, packages, and CI would contain no real key.

Difference from existing MCP support

Dify already supports remote MCP and custom headers, and the Marketplace already has general-purpose MCP clients. We are not requesting another generic MCP connector or claiming that native MCP support is missing.

The intended contribution is a service-specific provider credential flow and three stable, typed workflow tools, with maintained parameter/output mapping, bounded errors, documentation, and compatibility tests. The plugin would not accept arbitrary remote tool names or automatically expose newly discovered capabilities. Provider credential validation would use initialization and tool discovery only, not a billable tool invocation. This needs to earn its place as a focused integration rather than merely rebrand a generic client.

Safety and review scope

Although the plugin's own MCP connection has a fixed destination, page scraping and extraction delegate user-supplied URL retrieval to the hosted service. We would conservatively disclose High risk under the current arbitrary-URL-fetching/crawling criteria, document request timeouts and data flow, and not infer low risk from the fixed transport endpoint. No code execution, shell access, cloud sandbox, payment, or arbitrary-tool forwarding is proposed.

The plugin would need an accurate privacy policy covering the data sent to Baizhi and relevant downstream services, plus credential/logging safeguards. We will not invent data-retention, residency, or no-logging guarantees. The adapter's open-source license and the hosted service's account/usage terms would be disclosed separately.

Contribution status and next steps

We have completed a local three-tool prototype from a previously recorded, credential-free tool-schema snapshot. Its 55 offline tests pass with the actual Dify and MCP SDKs and in-memory HTTP transports; a separate local review and rerun also passed. The tests cover provider declarations, typed input mapping, discovery-only credential checks, the fixed endpoint, redirect rejection, bounded discovery, and credential/error/log redaction. These are local results; reviewable source and release artifacts have not yet been published.

The prototype has not been accepted into the Marketplace, validated in a real Dify Community Edition or Cloud workspace, or newly tested against the production service. Historical schemas may have changed. URL validation is not a complete server-side request-forgery defense, and a post-parse output-size check is not a strict transport-memory bound. This issue remains a plugin-scope request, not a packaged submission or a completed compatibility claim.

Before a release PR, we would publish reviewable plugin source and setup/troubleshooting documentation, verify current tool schemas and a limited live flow with a dedicated revocable key, complete Dify installation/credential/tool tests, confirm the privacy disclosure and Developer Agreement, and submit one validated .difypkg through this repository's current template. Agreement and unperformed-test checkboxes will not be pre-checked.

We would welcome guidance if an existing integration or a different contribution route is more appropriate. Thank you for considering the proposal; the Baizhi team would be glad to cooperate on a maintainable integration that fits Dify's architecture and review standards. This request does not imply Dify endorsement or an established partnership.

Official Website URL

https://baizhi.cloud/landing/agent-toolkit

No repository files or test paths are named; start with the current plugin template and existing remote MCP support described in the issue. Review the proposed credential flow, three typed tools, safety disclosures, and compatibility requirements before implementation. Done means reviewable source, documentation, validated installation and credential/tool tests, and one compliant .difypkg submission.