Connecting MCP Tools

Knowledge lets an agent know things; tools let it do things. AETHER connects agents to external systems using the Model Context Protocol (MCP) — an open standard for exposing tools, data and actions to AI models.

What is MCP?

An MCP server publishes a set of tools — typed functions the agent can call mid-conversation to fetch live data or take an action. Examples: look up an order, query a database, create a ticket, call an internal API, run a calculation.

When an agent has MCP tools available, the model decides when to call them based on the conversation and your system instructions, passes the right arguments, and weaves the result into its reply. Every tool call is recorded for auditing.

Connecting a server

You attach MCP servers to an agent from the builder. For each server you provide:

• its endpoint (the MCP server URL/transport), and
• any credentials it needs (for example an API key or OAuth connection).

Once connected, the agent's MCP Servers count in the Agent Status panel reflects the active connections, and the server's tools become available to the model.

Security: Tool credentials are stored encrypted. Grant an agent only the servers and tools it needs for its job — the same least-privilege thinking you'd apply to any integration.

Connecting to private / enterprise MCP servers

Have an MCP server that only runs inside your company network — behind a firewall or VPN, on localhost, or on a private subnet with no public address? You can still connect it to an AETHER agent. This section explains why it needs a little extra setup, then walks through three ways to do it — all configured entirely on your side, with nothing to enable on AETHER.

Why a private server isn't reachable by default

AETHER agents run in the cloud. When an agent uses a tool it makes an outbound call to the server's endpoint URL — the agent is the client, your MCP server is the server. That's fine for public servers, but a server that only listens on a private network has no address the agent can dial, and corporate firewalls block unsolicited inbound traffic by design:

Fails:   AETHER agent  ──✗──▶   🔒 firewall   ──✗──▶   your MCP server (private)
                                 (no inbound route in)

The fix: let your server dial out

Firewalls that block inbound almost always allow outbound HTTPS — the same traffic your laptop uses to browse the web. So instead of opening a hole in your firewall, you run a small tunnel (or proxy) next to your MCP server that dials out and publishes a stable public HTTPS endpoint. Your server is never exposed to inbound traffic; only the tunnel is. You then paste that public URL into AETHER like any other MCP server:

Works:   your MCP server ──▶ tunnel client  ══ outbound HTTPS ══▶  tunnel edge  ◀── AETHER agent
                             (runs on your network)                (public URL)    (connects here)

Rule of thumb: if you can open https://your-public-endpoint/mcp from a browser on the public internet, an AETHER agent can reach it too. Your only job is to create that endpoint securely.

Which approach should I use?

Option 1 — Cloudflare Tunnel (recommended)

cloudflared opens an outbound-only tunnel from your network to Cloudflare and maps it to a hostname you control.

1. Install cloudflared on any host that can reach your MCP server.
2. Authenticate, create a named tunnel, and route a hostname to your server's local address:

   cloudflared tunnel login
   cloudflared tunnel create aether-mcp
   cloudflared tunnel route dns aether-mcp mcp.yourcompany.com
   cloudflared tunnel run --url http://localhost:3000 aether-mcp
   

3. Confirm it's live by opening https://mcp.yourcompany.com/mcp in a browser.
4. Add it to your agent (see Add it to your agent below) using the endpoint https://mcp.yourcompany.com/mcp.

No inbound ports are opened. For production, install the tunnel as a service so it survives reboots — see Keep the tunnel running.

Option 2 — ngrok (fastest to try)

Great for a quick proof of concept:

ngrok config add-authtoken <your-token>
ngrok http 3000

ngrok prints a public https://<random>.ngrok.app URL that forwards to your local server; use it (plus your server's MCP path) as the endpoint. For anything beyond testing, add a reserved domain so the URL stays stable across restarts, and apply a traffic policy (OAuth, IP restrictions) so the endpoint isn't open to the world.

Option 3 — Self-hosted reverse proxy in a DMZ

If you'd rather not use a third-party tunnel, put a reverse proxy (nginx, Caddy, Envoy, …) in a DMZ that already has controlled inbound access and forward only the MCP path to the private server:

# nginx: expose only /mcp publicly, proxy through to the private MCP server
location /mcp/ {
    proxy_pass         http://10.0.0.5:3000/mcp/;   # private address, never public
    proxy_http_version 1.1;                          # keep-alive for streaming transports
    proxy_set_header   Host       $host;
    proxy_set_header   Connection "";
}

Terminate TLS at the proxy and expose only the MCP path (never the whole host). To protect the internal leg you can add mTLS or an IP allow-list between the proxy and your backend. The public URL then becomes https://proxy.yourcompany.com/mcp.

Add it to your agent

Once you have a public HTTPS URL, connecting it is identical to any other server (see Connecting a server above):

1. In the agent builder, open MCP Servers and choose Add MCP Server.
2. Paste the public endpoint, e.g. https://mcp.yourcompany.com/mcp.
3. Leave Transport on Auto-detect unless your server needs a specific mode (Streamable HTTP or SSE).
4. Set Auth to match your server — a Static token (sent as Authorization: Bearer …) or an OAuth connection.
5. Save. The MCP Servers count in the Agent Status panel updates and the server's tools become available to the model.

Verify the connection

• The MCP Servers count in the Agent Status panel should increase by one.
• Open the Test Console and ask the agent something that needs the tool; the invocation log records each tool call and its result.
• If the count doesn't move or tool calls fail, check Troubleshooting below.

Keep the tunnel running

The tunnel is the only path to your server, so it has to stay up:

• Run it as a service, not in a terminal window — cloudflared service install, a systemd unit, a Windows service, or a container with restart: always.
• Host it somewhere always on that can always reach the MCP server (not a laptop).
• Avoid random URLs for anything permanent: an ngrok free-tier URL changes on restart and will break the agent's saved endpoint. Use a reserved domain or a named tunnel instead.

Security checklist

The tunnel provides reachability; you still need real authorization on top of it. Because a tunnel exposes your server to the internet, treat the public URL as sensitive:

• Authenticate every request at the server. AETHER sends the Static token (Bearer) or OAuth credentials you configure on every call — require them on your MCP server so the tunnel is just an encrypted pipe, not an open door.
• Expose only the MCP endpoint, never the whole host or other internal services.
• Grant least privilege — attach only the tools the agent actually needs for its job.
• Rotate credentials as you would for any internet-facing integration; AETHER stores them encrypted.

Troubleshooting

Using tools in workflows

You can also invoke a specific tool at a defined point in a guided conversation using an MCP Call step in the Workflow Designer — handy when you want a deterministic sequence rather than letting the model decide.

Next steps

• Workflow Designer — orchestrate tools and knowledge visually.
• Multi-Agent — let specialist agents (each with their own tools) collaborate.