Gateways and Deployments are both built from the same three ingredients: the apps you want to use, the credentials that connect to them, and the specific tools you want exposed. See Deployments vs. Gateways for the full comparison.
This page walks through the creation flow for each.
Creating a Gateway
Creating a Gateway, Personal or Tenant, requires the Platform Admin or Security Admin role.
- Navigate to Gateway > MCP Gateway to open your Gateway List, then click New Gateway.
- Choose a name and a visibility level, Personal or Tenant. Gateway names must be unique across your whole organization, not just among your own gateways. See Tenant vs. Personal Level Gateway Configs if you’re unsure which visibility to pick.
- Select the apps you want in this Gateway from the grid of servers your organization has approved. You can search by name, filter by category, and apps your admin has marked as Featured are pinned near the top. There’s no limit on how many apps a single Gateway can include.
- Once you’ve picked at least one app, continue to configure each one: connect its credentials and choose which of its tools to expose. This step is covered in detail below, since it’s shared with Deployments.
- Save the Gateway. It’s added to your Gateway List immediately, ready to connect to.
Only servers an admin has approved show up in the selection grid. See Server Management if an app you need is missing. Creating a Deployment
Unlike a Gateway, a Deployment is always built around one app you’ve already chosen, so there’s no app-selection step.
- Navigate to Integrations > MCP Servers > Available, and click into the app you want to deploy.
- Click New Deployment.
- Fill in the Deployment’s name and an optional description, then choose which project it belongs to, or leave it available to every project.
- Connect credentials and choose tools, the same as a Gateway, covered below.
- Save the Deployment. It’s now available as a tool source wherever that project’s agents are configured.
Connecting Credentials
Whichever app you’re setting up, whether it’s the first one in a new Gateway or the single app behind a Deployment, credentials are handled the same way: right there in the flow, one app at a time, with no separate setup screen to hunt down.
What you’re asked for depends on how that app authenticates:
- No authentication: Nothing to do. These apps connect automatically.
- API key: Paste in a key, with the option to share it across your whole tenant so nobody else has to enter their own.
- OAuth: If your organization hasn’t connected this app before, an admin may need to register it first. After that, you sign in with your own account, and your personal sign-in stays yours even if the underlying app registration is shared.
- Pass-through or token exchange: Airia reuses your existing sign-in to Airia itself, so there’s often nothing extra to configure.
If you’ve already connected an app in a previous Gateway or Deployment, it shows up already configured here instead of asking you to sign in again. Each app’s status (Configured, Needs Authentication, or Not Configured) is visible at a glance as you work through your list of apps.
See Tenant vs. Personal Level App Credentials and Supported Credential Types for the full picture of how each method works.
Once an app is connected, Airia pulls its live list of available tools so you can pick exactly which ones to expose, rather than turning on everything the app offers. Use the search box to find specific tools, or Select All and Deselect All to act on whatever the current search or filter is showing. A running count keeps track of how many tools you’ve selected out of the total available. You need at least one tool selected per app before you can save.
Each tool is also checked for hidden prompt injection attempts as it’s loaded, with a status badge next to it. See Tool Scanning for what those badges mean and what to do about a flagged tool.
Why Not Just Include Everything?
Every tool you expose adds to the amount of context your AI has to read before it can do anything else, and a long list of similar-sounding options makes it easier for a model to pick the wrong one. Choosing tools deliberately keeps your AI faster and more accurate, and it also limits the blast radius if a connected app is ever misused, since only the specific actions you selected are reachable at all.
If a Gateway ends up exposing a large number of tools anyway, whether from one app or many, Airia will suggest turning on Radar once you cross around 50 tools. Radar lets your AI search for the right tool on demand instead of holding the full list in context all the time. You’re always free to dismiss the suggestion and keep the full list if that’s what you’d prefer.
Adding Instructions (Optional)
Both Gateways and Deployments can include a short block of written guidance that an agent reads before using your tools, useful for naming conventions, environment-specific details, or anything else a plain tool definition can’t convey on its own. See the Instructions Tool page for how to set it up.
After You Create It
A new Gateway appears in your Gateway List with a connection endpoint and a setup guide for common MCP clients like Cursor, Claude Code, and Claude, so you can start using it outside Airia right away. It’s also immediately selectable from the agent builder’s tool section if you’d rather use it inside Airia.
A new Deployment doesn’t have a connection endpoint of its own. Instead, it becomes available to attach as a tool source to any agent in the project you assigned it to.
Neither one is locked in once you save. Names, visibility, connected apps, credentials, and selected tools can all be revisited later. See Editing a Gateway for how to make changes after the fact. 
