MCP servers
Connect any remote MCP server so Helios agents can call its tools, and expose Helios itself over MCP to your own agents.
MCP servers
The Model Context Protocol (MCP) is how agents discover and call tools that live outside the platform they run on. Helios speaks it in both directions.
Attaching an external MCP server
Register a remote MCP server and its tools become available to your agents, alongside their integrations and database access.
| Field | Notes |
|---|---|
| Name | Lowercase slug, e.g. internal-search. |
| URL | Must be HTTPS. Helios speaks Streamable HTTP. |
| Description | Shown to the agent so it knows when to reach for this server. |
| Authentication | none, bearer token, custom headers, or OAuth 2.0. |
| Tool filter | An allowlist of tool names. |
| Timeout | Per-call, 1–60 seconds. Defaults to 5 seconds. |
Only remote servers over HTTPS are supported — there is no stdio transport. URLs pointing at
localhost, link-local addresses, cloud metadata endpoints, or private network ranges are rejected.
Authentication
- Bearer — Helios sends
Authorization: Bearer <token>. - Headers — supply your own header names and values, up to 20 of them.
Authorizationis allowed; transport headers that Helios controls (host,content-length,connection,transfer-encoding,keep-alive,upgrade,te,trailer,content-type,accept) are rejected. Header names must be unique, and each value may be up to 8192 characters. - OAuth 2.0 — authorization code flow with PKCE. Helios stores the refresh token and refreshes access tokens as needed.
Credentials are envelope-encrypted and are never returned by the API or exposed to the agent.
The authentication type is fixed when you create the server. To change it, create a new server entry.
Tool filtering
The tool filter is an allowlist, enforced server-side on both discovery and invocation. A tool not on the list is hidden from the agent, and a call to it is rejected even if the agent somehow names it. Leave the filter empty to expose every tool the server offers.
Use it. Most MCP servers expose more than any one task needs, and a narrower surface makes the agent both safer and more accurate.
How agents use them
Each attached MCP server is handed to a dedicated subagent. Your agent delegates to it — "find the open incidents for service X" — and the subagent discovers the server's tool catalog, picks the right call, and returns the result. This keeps a large external tool catalog from crowding the main agent's context.
Scope
MCP servers are stored per organization and are visible to the user who created them. Agents running in a project pick up the servers available to that project.
Using Helios as an MCP server
Helios exposes itself over MCP, so your own agents — Claude Code, or anything else that speaks MCP — can drive Helios.
Connect to the Helios MCP endpoint over Streamable HTTP and authenticate with the same bearer token you would use against the Helios API. See API keys.
It exposes two tools:
| Tool | Purpose |
|---|---|
find_relevant_apis | Semantic search across the Helios API to find the right endpoint for a task. |
call_api | Call that endpoint, authenticated as you. |
This is the same full-API pattern Helios uses for its own integrations: rather than a fixed set of actions, an agent searches the API surface and calls what it needs. Through it, your agent can list projects, create and trigger workflows, read runs, manage integrations and database connections, and start chats.
Last updated on
Integration resources
Integration resources attach a specific object from a connected service — today, a GitHub repository — to a chat or workflow as scoped, authenticated context.
Projects and sharing
A project groups related workflows, chats, integrations, and variables, and is the unit of access control in Helios.