bailinghub-mcp-server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BAILINGHUB_ROUTE | Yes | The operator-configured route to use for job submission | |
| BAILINGHUB_BASE_URL | Yes | The base URL of the BailingHub deployment, e.g., https://hub.example.com | |
| BAILINGHUB_CLIENT_TOKEN | Yes | A BailingHub Client Token restricted to the configured route | |
| BAILINGHUB_ALLOW_INSECURE_HTTP | No | Set to 'true' to allow non-loopback HTTP connections (use only in private networks) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| submit_governed_jobA | 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. |
| get_governed_jobA | Read the current public state and result of a BailingHub job owned by this client. |
| wait_for_governed_jobA | Poll one BailingHub job for a bounded period. A timeout returns the latest state and never resubmits the business action. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each 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.