RunningHub MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUNNINGHUB_API_KEY | Yes | RunningHub API 密钥 | |
| RUNNINGHUB_API_HOST | No | API 主机地址 | www.runninghub.cn |
| RUNNINGHUB_TASK_STORE_PATH | No | 任务持久化文件路径 | ~/.runninghub/tasks.json |
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 |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_node_infoA | Get the configurable node list of an AI application. Returns all modifiable node info (nodeId, fieldName, fieldType, fieldValue). |
| upload_fileA | Upload a local file to RunningHub platform. Supports IMAGE, AUDIO, VIDEO types. Returns the uploaded fileName for use in node fieldValue. |
| submit_taskA | Submit an AI application task. Requires webapp_id and node_info_list. Returns taskId for subsequent status queries. The task is automatically saved to local persistent storage. |
| query_task_outputsA | Query the execution status and output of a task. Status codes: 0=completed, 804=running, 813=queued, 805=failed. Returns output file URLs when completed. |
| run_task_and_waitA | Submit an AI application task and wait for completion (auto-polling). Combines submit_task + query_task_outputs into a full workflow. Default max wait is 10 minutes with 5-second polling interval. Task status is automatically synced to persistent storage. |
| list_tasksA | List tasks from local persistent storage. Supports filtering by status (pending/queued/running/completed/failed). Results are sorted by last update time in descending order. |
| get_task_detailB | Get detailed information of a specific task from local persistent storage. |
| sync_task_statusA | Sync task status from RunningHub API to local persistent storage. Useful for refreshing status of previously timed-out tasks. |
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 8 tools
There is overlap between submit_task and run_task_and_wait (both submit tasks), and between query_task_outputs and run_task_and_wait (both check status/output). However, descriptions clarify the combination pattern in run_task_and_wait, so ambiguity is limited but still present.
Most tools follow a consistent snake_case verb_noun pattern (e.g., get_node_info, submit_task). The exception is run_task_and_wait, which deviates with 'and_wait', and 'list_tasks' vs 'query_task_outputs' use different verbs for similar operations.
8 tools is well-scoped for an AI task runner, covering submission, synchronization, file upload, and status queries without being excessive or minimal.
Core workflow (submit/run, query output, sync status, upload files) is covered. Missing tools for listing available applications or canceling tasks, but these are not critical for the primary use case.