BailingHub for Business Operations MCP server

BailingHub MCP Server

0.6.0: longer tasks, attachments and original-call recovery

Retain the correct target while moving between edits and queries, reuse uploaded image URLs and inspect original calls after reopening. Task budgets survive turn changes. Pair Core 0.8.0 / SDK 0.6.0 / DSH 0.6.0; host integration is required for task binding and opt-in cross-turn reuse.

Changes · Upgrade

简体中文 | English

Let an MCP-compatible AI agent use natural-language requests to query and operate your store, SaaS, CRM, ERP, or other business system through BailingHub.

Depending on the capabilities explicitly exposed by the business system and the routes allowed for this connection, an agent can, for example:

• find products with fewer than 10 items in stock and prepare a restocking suggestion;
• update an employee or customer profile;
• submit a refund request and wait when the configured route requires human approval.

The agent does not receive administrator or business-system credentials. BailingHub keeps the route boundary, approval state, execution record, and audit trail, while the downstream business system still makes the final authorization decision.

Previously introduced in 0.5.0: shop and inventory in one conversation

A host can let a user ask: “Check tumbler stock; if available, change the corresponding shop product to 59 and list it.” This SDK adds original-target checks for different systems on one Hub, system descriptions before tool search, and business-supplied authorization names. Actions must be exposed by the business systems, product mappings confirmed, and original approvals respected.

Use Core 0.8.0 + SDK 0.6.0 and a compatible host for these extensions, within one Hub and one administrator audit domain. The host owns explicit selection and persistent scope; the standalone MCP server does not gain a multi-system selection UI.

Scenarios, changes and upgrade steps

Conversation archives introduced in 0.4.0

When an Agent Client host enables conversation archiving, a BailingHub administrator can follow the user's request, the assistant's visible replies and the resulting business actions together. For example, one conversation can compare two separately authorized stores while retaining the original execution record for each store. Use BailingHub Core 0.7.0 with a host that captures and synchronizes the conversation. The archive API minimum is Core 0.6.0.

Version 0.4.0 introduced that synchronization API. It does not capture conversations by itself. A native host such as the DSH plugin owns the account selection and conversation interface. The standalone MCP server keeps its existing tool surface.

Who should upgrade, and where to start

You do not need to change business API declarations for this SDK upgrade. Existing read/write, approval and invocation recovery behavior stays in place. Conversation upload retries use the same event IDs and never repeat business actions; only the deployment's authorized administrators can read the combined archive. Hidden reasoning is excluded.

Shortened. The full README is on GitHub.