MCP Server
The MCP Server is the bridge that lets an AI assistant talk to Automation Hub.
It does not replace Automation Hub. It does not create random actions on its own. It gives the AI assistant a controlled set of approved actions, such as searching for automations, running one, checking progress, and reading results.
The Basic Idea
What the MCP Server Does
| It helps the AI... | Plain-English meaning |
|---|---|
| Discover automations | Find what jobs are available |
| Understand automations | Read what a job does and what inputs it needs |
| Start automations | Run the selected job with the right information |
| Monitor executions | Check whether the job is running, completed, failed, or paused |
| Manage executions | Pause, resume, or stop a run when appropriate |
| Return results | Give the final outcome back to the AI assistant |
Why It Exists
AI assistants need boundaries when they interact with business systems. The MCP Server provides those boundaries.
| Without the MCP Server | With the MCP Server |
|---|---|
| AI may need custom integration for every action | AI uses one clear set of approved tools |
| Actions may be inconsistent | Every action follows Automation Hub rules |
| Results may be hard to track | Runs are recorded in Automation Hub history |
| Permissions may be difficult to manage | Access can follow platform governance |
What Happens When a User Makes a Request
What Administrators Care About
| Area | What to confirm |
|---|---|
| Availability | The MCP Server is running and reachable by approved AI clients |
| Permissions | Users can only run automations they are allowed to use |
| Environment | The server points to the correct Automation Hub services |
| Monitoring | Health checks and logs are available |
| Security | Secrets and credentials are managed safely |
What Users Care About
Users usually do not need to know how the MCP Server is configured. They only need to know that it lets the AI assistant:
- Find the right automation
- Ask for missing information
- Start the job
- Report progress
- Explain the final result
Server Health
Administrators can check whether the MCP Server is available through its health check. A healthy server means the AI bridge is running and ready to receive approved tool requests.
| Status | Meaning |
|---|---|
| Healthy | The AI bridge is available |
| Unavailable | AI assistants may not be able to run or monitor automations |
| Misconfigured | The bridge may be running but unable to reach Automation Hub services |
Good Setup Practices
Use clear environments
- Keep development, QA, and production settings separate
Protect credentials
- Store passwords, API keys, and service URLs securely
Monitor the bridge
- Check health and logs so AI requests do not fail silently
Start with a small set of automations
- Enable AI access for well-understood automations first
Review run history
- Every AI-started automation should be traceable in Automation Hub
MCP Servers in AI Hub
The concepts above describe the MCP bridge in general. In practice, an agent reaches an external MCP server through an entry you register in the AI Hub part of Global Configurator. Each registered server is a stored document, and the AI Agent node references it by id through toolsConfig.mcpServers[].
Stored Server Fields
| Field | Type | Default | Description |
|---|---|---|---|
name | string | -- | Unique server name; a duplicate returns 409 |
url | string | -- | The MCP server endpoint |
description | string | -- | What the server provides |
authType | string | NONE | How the server authenticates: NONE, BEARER, API_KEY, BASIC, or CUSTOM |
authConfig | map | {} | Credentials for the chosen auth type; sensitive values are Vault-encrypted |
status | string | UNKNOWN | ONLINE, OFFLINE, or UNKNOWN |
toolCount | int | 0 | Number of tools found at the last discovery |
discoveredTools | object[] | [] | Each tool as { name, description, inputSchema } |
tags | string[] | [] | Free-form labels for search |
lastCheckedAt | timestamp | -- | When discovery last ran |
Authentication Types
authType | What authConfig holds |
|---|---|
NONE | No credentials |
BEARER | A bearer token |
API_KEY | A named apiKey and its placement |
BASIC | A username and password |
CUSTOM | Custom headers or fields the server requires |
Credential Encryption
Sensitive authConfig values are protected with Vault Transit encryption before they are stored:
- Sensitive keys —
token,apiKey,apikey,password,secret,clientSecret,privateKey— and nested header values are encrypted. - Values already prefixed with
vault:are treated as pre-encrypted and skipped. - A normal read of the server never returns decrypted credentials. Decryption happens only for the internal, service-to-service call that actually contacts the server.
Tool Discovery
Registering a server does not automatically list its tools. Discovery is an explicit action:
The discover action delegates to connectivity-validator, which performs the MCP JSON-RPC initialize call followed by tools/list. Discovery is considered successful only when the validator reports status == "success" and no step is marked FAILED. The result updates discoveredTools, toolCount, status, and lastCheckedAt.
The discover action replaces the old /{id}/test endpoint, which was a stub that always returned SUCCESS. That stub has been removed — use discover to get real tool data and a real reachability check.
For the fields of each discovered tool and how tools become callable, see MCP Tools Reference.
Related Pages
- AI Integration Overview - how AI works with Automation Hub
- AI Hub Configuration - all four AI Hub entities, including MCP servers
- MCP Tools Reference - what actions the AI can use
- Building AI Agents - how an AI assistant should behave