# Connections

Connections give your agents hands. Link an app once and its tools show up in every session — read a GitHub issue, query Postgres, deploy to Vercel, post to Slack. Foxora keeps three kinds of connection cleanly apart so a model key never gets confused with a tool server.

## Three kinds of connection

Foxora deliberately separates three things that look similar but behave differently. Mixing them up — the classic mistake — means a model key gets treated as a tool server, or a chat platform as a model. Each lives in its own place in Settings.

- Connectors — MCP tool servers. Connecting one (GitHub, Postgres, Linear, Sentry…) hands your agents that app’s tools. This is the Connections section.
- Model providers — bring-your-own API keys (OpenAI, Anthropic, Mistral…). A key makes those models routable through the gateway on your account — it is not a tool. Lives under Model providers.
- Channels — messaging platforms (Slack, Discord, Telegram, email…) where a crew can operate. These run on Foxora’s hosted side and route inbound messages to an agent.

## How a connection becomes a tool

A connector is a curated entry in Foxora’s catalog. The catalog owns the command that launches each app’s MCP server — you only ever supply config (a token, a connection string). That split is the security boundary: a stored value can fill an env var, but it can never choose which binary runs.

When a session starts, every active connection resolves into a running MCP server over stdio, and its tools are merged into the agent’s toolbelt — namespaced per app, so a Notion tool can’t be mistaken for a Postgres one. A half-configured connection is simply skipped, never launched broken.

> Encrypted server-sideWhen you save a connection, the config (tokens, keys, connection strings) is sent to the gateway and encrypted there. The desktop app holds the form values only long enough to submit them.