This server lets MCP hosts submit governed business-system actions to a BailingHub control plane and inspect their state, while keeping credentials, routes, and approval decisions out of model control.
Submit untrusted task text through submit_governed_job with a stable request_id for idempotent retries.
Read the current public state and result of a job with get_governed_job.
Poll a job for a bounded wait (default 20s, max 60s) with wait_for_governed_job; a timeout does not resubmit the action.
Distinguish non-terminal states (queued, running, dispatched) from terminal states (done, error, rejected).
Operate in Agent Session mode (browser login, PKCE, secure credential storage, token refresh) or compatible Client Token mode.
Keep the route, BailingHub URL, and credential as local process configuration, never as tool arguments.
Support host-neutral Agent Client SDK integration for browser-based login and governed agent-session workflows.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bailinghub-mcp-server Submit a governed job to approve refund for order 456"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
简体中文 | 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.
0.3.0: adds host-controlled multi-connection lifecycle APIs and CurrentUser DPAPI storage for Windows Agent Sessions. The existing Agent Client and
0.1.xClient Token behavior remains compatible and is not replaced.
This package is a thin integration adapter. It does not embed BailingHub, grant business permissions, or replace the downstream business system's final authorization. It supports both the existing operator-provisioned Client Token mode and an Agent Session mode in which a human approves one local Agent through the system browser.
Tool | Purpose |
| Submit untrusted task text to one operator-configured BailingHub route |
| Read the current public state of a credential-owned job |
| Poll one job for at most 60 seconds without resubmitting it |
The Agent Client 0.3 path starts with five small meta-tools for turn bootstrap, capability search, governed invocation/recovery, and visible run completion. BailingHub then returns at most 12 active business tools for the current turn; each replacement removes the previous active set instead of growing the model context indefinitely.
Host implementers should use the host-neutral Agent Client SDK guide.
The route, BailingHub URL, and credential are local process configuration. They are never MCP tool arguments and therefore cannot be selected or replaced by model output.
Related MCP server: nano-vm-mcp
Agent Session: run bailinghub-mcp-server login once. The CLI uses a random loopback
callback plus PKCE, opens the system browser, and stores the approved session in the
platform-specific secure credential store. The MCP tools then use /agent-api/v1/* and
refresh rotated tokens locally.
Client Token (compatible): when BAILINGHUB_CLIENT_TOKEN is present, the adapter keeps
using POST /run and GET /jobs/{job_id} exactly as before.
Neither mode lets the model supply a credential, route, acting subject, or approval result. The Agent Session records the identity approved by the Hub/business authorization boundary; the downstream business system still makes the final authorization decision.
The MCP Registry server.json describes only the compatible standalone stdio/Client Token
installation, so that entry still marks BAILINGHUB_CLIENT_TOKEN as required. The native DSH
plugin does not consume that Registry configuration: it imports this package's /sdk subpath as
an ordinary library dependency and establishes an Agent Session through the browser. Do not add a
Client Token field to a DSH plugin based on the Registry form.
MCP host / model
|
| request_id + untrusted input
v
BailingHub MCP Server
|
| fixed route + Client Token or approved Agent Session
v
BailingHub
|
| governed dispatch
v
Business system
|
+-- resolves trusted subject and performs final authorizationThe adapter intentionally does not accept:
an acting subject or identity claim;
a Client Token, administrator token, or business-system credential as tool input;
an approval decision or approval evidence;
an executor identity;
arbitrary metadata or callback URLs;
an arbitrary route.
In compatible Client Token mode, use a dedicated token restricted to the one route configured for this server process. Run separate server instances when different MCP clients need different route boundaries.
Prerequisites:
Node.js 20.15 or newer;
a reachable BailingHub deployment;
either one route-scoped BailingHub Client Token or a registered public Agent client that can be approved for the required route.
For the legacy static-job mode, configure an MCP host to spawn:
{
"mcpServers": {
"bailinghub": {
"command": "npx",
"args": ["-y", "bailinghub-mcp-server"],
"env": {
"BAILINGHUB_BASE_URL": "https://hub.example.com",
"BAILINGHUB_CLIENT_TOKEN": "replace-with-a-route-scoped-client-token",
"BAILINGHUB_ROUTE": "order_assistant"
}
}
}
}Authorize one registered public Agent client and one fixed route before starting the MCP host without a Client Token:
bailinghub-mcp-server login \
--base-url https://hub.example.com \
--client-app-id merchant-agent \
--route order-assistant
bailinghub-mcp-server status
bailinghub-mcp-server logoutThe login callback binds only to a random 127.0.0.1 port and uses state plus PKCE S256.
Access and refresh tokens never appear in CLI output. macOS uses Keychain. Linux and other
POSIX platforms require an explicit BAILINGHUB_ALLOW_FILE_CREDENTIAL_STORE=true opt-in;
that fallback rejects files that are not owned by the current user with mode 0600.
Windows uses a CurrentUser DPAPI-protected file under the user's LocalAppData directory. If
Windows PowerShell or DPAPI is unavailable, Agent Session fails closed and never falls back to
plaintext. Compatible Client Token mode remains available on every supported platform.
For a local BailingHub process, loopback HTTP is accepted:
BAILINGHUB_BASE_URL=http://127.0.0.1:3000Non-loopback HTTP is rejected by default. BAILINGHUB_ALLOW_INSECURE_HTTP=true exists only
for an operator-controlled private network where TLS terminates elsewhere. Do not use it
across an untrusted network.
Create a stable request_id for one business request.
Call submit_governed_job with that ID and the task text.
Preserve the returned job_id.
Call wait_for_governed_job for a short bounded wait, or call get_governed_job later.
If submission must be retried, reuse the exact same request_id and task meaning.
queued, running, and dispatched are non-terminal. done, error, and rejected are
terminal. A wait timeout is not a failed task and must not cause a replacement submission.
Use the MCP integration path as the
canonical start page. The first integration is successful when an MCP host submits through
the operator-fixed route, the same job_id reaches a terminal state, BailingHub retains
its approval and audit state, and the MCP host never receives administrator or
business-system credentials.
Report a PASS, partial result, or failure through the BailingHub independent validation form and select the MCP track. Never include tokens, model keys, personal information, or production business data.
The dependency direction is one-way:
bailinghub-mcp-server -> BailingHub public Client API / Agent API
BailingHub may consume ACC declarations
ACC has no dependency on either implementationSee:
npm install
npm run verify
npm pack --dry-runClient Token mode uses the stable bailing.client-api.v1 surface:
POST /run
GET /jobs/{job_id}
Agent Session mode uses the additive Agent Auth v1 and Agent API v1 surfaces:
POST /agent-auth/v1/authorizations
POST /agent-auth/v1/token
GET /agent-auth/v1/session
POST /agent-auth/v1/revoke
GET /agent-api/v1/workspaces
GET /agent-api/v1/workspaces/{route}/bootstrap
POST /agent-api/v1/workspaces/{route}/turns
POST /agent-api/v1/workspaces/{route}/capabilities/search
POST /agent-api/v1/tool-invocations
POST /agent-api/v1/tool-invocations/{invocation_id}/resume
POST /agent-api/v1/runs/{run_id}/complete
The bailinghub-mcp-server/sdk subpath additionally exposes a host-neutral Agent Client factory.
It owns browser login, named local selectors, isolated credentials, token refresh, and Core DTO
mapping. On the same Hub/client/workspace binding it replaces an older local connection only when
Core reports the same trusted on_behalf_of; different business identities remain independently
selectable. Core resolves the business authorization entry, so host adapters such as DSH never ask
for a business URL and do not own credentials or BailingHub HTTP endpoint details.
No administrator, executor, approval-decision, tool-proxy, configuration, or direct business API is called by this adapter.
Read the current public state and result of a BailingHub job owned by this client.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Exact job_id returned by submit_governed_job. Never invent it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive flags. The description adds meaningful context: 'public state' indicates visibility, 'owned by this client' hints at access control, and 'current' implies no waiting. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that is front-loaded with the verb and resource. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with strong annotations and a clear parameter schema, the description covers the essentials: what is read, ownership, and currency. Without an output schema, it does not specify the exact response structure, but this is not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description itself does not mention parameters. However, the schema description for job_id is 100% covered and includes critical guidance ('Never invent it'), so the baseline of 3 applies since the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current public state and result of a specific job, using a specific verb ('Read') and resource ('BailingHub job'). It naturally distinguishes from siblings by contrasting read (get) with create (submit) and likely wait/block operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the verb 'read' and 'current' (non-blocking), but there is no explicit guidance like 'Use this to poll status' or 'Do not use to create jobs'. Sibling names help, but the description itself doesn't clarify when to choose this over wait_for_governed_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a business-system action through an operator-configured BailingHub route. BailingHub applies its configured reach, risk, approval-intent, rate-limit, and audit controls. The downstream business system still performs final authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Untrusted business task text. Never include tokens, acting-subject credentials, or secrets. | |
| request_id | Yes | Stable client-scoped idempotency key. Reuse it unchanged when retrying the same request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that BailingHub applies configured reach, risk, approval-intent, rate-limit, and audit controls, and that the downstream system still performs final authorization. This adds meaningful behavioral context without contradicting the destructive/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core action, then explain governance behavior. Every sentence contributes new information with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the governance pipeline and final-authorization caveat, and sibling tools suggest follow-up retrieval. It does not describe return values or error/rejection behavior, but the provided annotations and schema are rich enough for a submit action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions already explain request_id as an idempotency key and input as untrusted task text. The tool description adds no parameter-specific semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Submit a business-system action') and resource/route ('operator-configured BailingHub route'), clearly distinguishing from the sibling get/wait tools. It communicates the submission nature and governance context in one sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for submitting a governed business action but does not explicitly contrast with alternatives like get_governed_job or wait_for_governed_job, nor mention when not to use it. Context is clear but exclusions/alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll one BailingHub job for a bounded period. A timeout returns the latest state and never resubmits the business action.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Exact job_id returned by submit_governed_job. Never invent it. | |
| max_wait_seconds | No | Maximum bounded wait from 1 to 60 seconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds that a timeout returns the latest state and never resubmits the business action, clarifying timeout semantics and reinforcing idempotency beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences that state the primary action and timeout behavior with no redundant words. It is appropriately concise for a simple wait tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema. The description covers the wait behavior, timeout result, and non-resubmission guarantee, but does not explicitly describe successful return values; however, the mention of 'latest state' partially addresses the return concept.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have complete schema descriptions, including job_id's origin and max_wait_seconds bounds. The description itself adds no new parameter-level detail beyond mentioning a bounded period, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls a BailingHub job for a bounded period, using the specific verb 'poll' and resource 'BailingHub job'. It distinguishes itself from sibling tools (submit_governed_job and get_governed_job) by emphasizing bounded waiting and non-resubmission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after submitting a job to wait for its completion, contrasting with get_governed_job by highlighting bounded polling and no resubmission. It does not explicitly name alternatives, but sibling context makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1get_governed_jobsubmit_governed_jobwait_for_governed_jobEach tool has a clearly distinct purpose: submitting a job, reading its current state, and polling until completion. Even though get and wait both read state, wait explicitly adds bounded polling behavior, so an agent can easily choose the right one.
All tool names follow a consistent verb_governed_job pattern: submit_, get_, wait_for_. This makes the set predictable and easy to learn.
Three tools is well-scoped for a narrow domain of submitting and monitoring a governed job. There is no bloat or redundancy.
The tool surface covers the full lifecycle for a client: submit the action, retrieve its state, and wait for a result. No obvious operations are missing for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governance runtime for compliance: verified, human-approved writes to a tamper-evident record.
Discover, preview, estimate, run, and retrieve reusable AI workflows.
Connect, monitor, and control AI agents — tasks, approvals, schedules, and governance.
Programmatic control of the Hiro security platform: scans, tasks, plans, and approvals.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bailinghub/bailinghub-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
