Tools and integrations
Connect Slack, Discord, Gmail, GitHub, and 4,000+ tools and integrations to your Nebula workspace so your agents can act on real systems.
Each workspace can connect to 4,000+ services so its agents can act in the real world — post in Slack, read GitHub issues, send email, fetch from Stripe. Connections are scoped to the workspace they're added to.
You don't need to set things up in advance. When you ask Nebula to do something that needs an app, it prompts you to connect right in the conversation.
Connections belong to the person who sets them up — in workspace integrations you only see your own. Learn how this plays out with shared agents in Agent scoping & access.
I need to connect to Gmail to do that. Click below to authorize.
Click Connect, sign in to the service in the popup, and grant permissions. Nebula finishes the action immediately. Future requests to the same app skip the authorization step.
If your browser blocks the sign-in window you'll get a message saying so, with a Try again button — clicking that reopens it properly. Backing out of the sign-in window on purpose is fine; Nebula treats it as a cancel and says nothing.
Two flavors of connection
| Workspace bots | Everything else | |
|---|---|---|
| What | Slack, Discord, Telegram, Linear, GitHub | Gmail, Notion, Twitter (X), 4,000+ more |
| How | One install for the whole workspace, using a shared bot | Each person connects their own account by OAuth or API key |
| Who can use it | Everyone, with no personal sign-in | You, and any agent you attach the account to |
| Result | Your agents gain that platform's tools | Tools attached to the relevant agent |
Connecting an app never creates a new agent. There's no "Slack Agent" or "GitHub Agent" — your existing agents simply gain the tools, and you decide which agents get them from the agent's Tools tab.
Connections are per-workspace. The same person can have one Slack workspace connected to their personal workspace and a different one to a team workspace. The exception is the shared Slack bot itself — a Slack team's install can serve several Nebula workspaces, and everyone on it can use it from any Nebula workspace they belong to.
Popular platforms
Connect Slack and your agents can send messages, read channels, upload and fetch files, schedule posts, and search the Slack workspace — all through the shared bot, so nobody has to sign in individually.
Post a message to #general saying the deploy is complete.
Posting to #general.
Done — posted: "Deploy complete."
The Slack bot token is at the Slack workspace level. Anyone in the channel can interact with it. Make sure the Nebula bot has been added to the Slack channels you want it to read.
Connect Discord and your agents can post in channels, create and join threads, and read a server's pinned messages.
Discord is deliberately read-and-post only. Moderation and administration — kicking, banning, pinning, managing roles, channels or webhooks — are held back on purpose, as is listing server members, so an agent can't take a destructive action in a server you share with other people.
Post an announcement in #updates about the new feature.
Posting to #updates.
Announcement posted.
The Discord bot is connected per-server. One server per workspace today; switch workspaces to talk to a different server.
Connect Telegram and your agents can DM you, post in groups, send photos and documents, run polls, and create invite links for groups the bot has been added to. It can read a group's details, members and admins, but it can't kick or ban anyone.
Send me a Telegram message when the build finishes.
Got it — I'll DM you on Telegram as soon as the build wraps.
Twitter (X) is not a workspace bot — you connect your own X account by OAuth, and it stays yours. Pick it for an agent in that agent's Tools tab and it can post and reply on your behalf.
Tweet about our new feature launch.
Posting tweet.
Tweet is live on your timeline.
To post on a schedule, ask Nebula for a job — the scheduling is Nebula's, not X's.
Supported integrations
Beyond the four messaging platforms, Nebula connects to Gmail, GitHub, Notion, Linear, Stripe, Shopify, Google Calendar, Salesforce, HubSpot — and so on. Search the full catalog. If your app supports OAuth, chances are it works.
How OAuth connections work
When you connect an external service, Nebula securely manages the OAuth token exchange, credential storage, and API communication. Credentials are encrypted; Nebula only accesses what you authorize. Revoke any connection at any time from Settings → Accounts.
If a service doesn't support OAuth, you can connect it with an API key or token. Generate the key in the service with the minimum scopes you need, then paste it into the variable form in the agent's details panel — never into a chat message.
Multiple accounts
If you have multiple accounts for the same service (two Slack workspaces, two Gmails), Nebula asks which one to use before taking action. You can connect as many as you need.
Custom MCP servers
Beyond the built-in catalog, you can connect any remote MCP server by URL and hand its tools to your agents. There's no form to fill in — you register one by asking Nebula in chat, and it lands in Settings → Accounts like any other row.
Add the Linear MCP server at https://mcp.linear.app/sse so the team can use it.
Registering Linear as an MCP toolkit.
Registered it as mcp:linear. It uses OAuth — sign in below and I'll attach it to your agents.
Give it the URL and Nebula works the rest out, asking only where it genuinely can't guess:
Signing in to an OAuth server
A server set to OAuth gets a Connect button and a status of its own in the list. Every app in the catalog reports its health the same way — Connected, Needs setup, Needs attention, or Not connected — so an MCP server reads exactly like a Slack bot does. Click Connect and a sign-in window opens; approve there and you're done.
Nebula keeps the connection alive on its own, so Needs attention only appears when it genuinely can't renew and needs you to sign in again. Two different removals sit on the detail view: Disconnect my account drops your own sign-in and leaves the server in place, while Remove followed by the server's name takes it out of the workspace for everyone — it warns you first that agents using it will lose those tools.
The server registration is workspace-scoped, but an OAuth connection is yours. Each member signs in with their own account, so a teammate using the same server acts as themselves rather than as you.
If an agent needs a server nobody has connected yet, it can drop a Connect card straight into the conversation — sign in from there and it picks the work back up. Anyone else in the thread just sees that it's waiting on you.
Registered servers are workspace-scoped. To let an agent use one, attach its mcp:<slug> toolkit from the agent's Tools tab with Connect a tool, the same way you'd add any other tool.
Coding harnesses
Connect a coding harness — Claude Code or OpenAI Codex — so your agents can delegate whole-repository coding work to it. Harnesses sit at the top of Settings → Accounts under Coding Accounts, and each person connects their own: a harness connection is private to you, not shared across the workspace.
| Claude Code | Codex | |
|---|---|---|
| Plan sign-in | Authorize your Claude plan at claude.ai and paste the code back | Enter the code Nebula shows at a verification URL, then approve your ChatGPT plan |
| API key | Connect an Anthropic API key | Connect an OpenAI API key |
| This machine | Use the Claude Code CLI signed in on a device | Use the Codex CLI signed in on a device |
| Models | Pick a tier — fastest through most capable | Pick from your plan's current lineup |
The This machine option runs the CLI already signed in on a device — available only when the agent runs on that machine, and Nebula stores no credential.
Each harness has a Model picker that keeps itself current: when a new model or tier turns up on your plan, it appears in the list on its own. Codex reads the lineup from your own ChatGPT plan, so two people in the same workspace can genuinely see different options. Usage sits beside the picker as Session (5h) and Weekly bars.
Managing your connections
Two pages under Workspace brain split the job between them, and it's worth knowing which is which: Tools is what your agents can do, Accounts is what they're signed in to.
What you've already connected, in one list: your app accounts like Gmail and Notion, the platforms that run as a workspace bot — Slack, Discord, GitHub, Linear, Telegram — your MCP servers, your custom toolkits, and your coding harnesses. At rest the page lists what you've connected and nothing else, so it stays short. Start typing in its search box and it widens to the whole catalog, so you can find something you haven't connected yet without leaving the page — or use Add Account to browse the catalog outright. This is where connecting, reconnecting and disconnecting happen.
The built-in tools your agents can use straight away, with no account to connect — search, code execution, image generation and the rest. Each has a per-member availability setting — Off, On demand (used only when an agent explicitly needs it), or Always on — and that choice is yours: it controls what your agents reach and doesn't change anyone else's setup. You can also turn the whole store off.
On demand isn't a one-way door: an agent turns the capability back on itself the moment it needs it. Off is the deliberate stop — an agent can't reach past it, and it'll tell you the capability is unavailable rather than pretending it tried.
Some tools aren't yours to change: where a tool ships on by default, the setting is greyed out and the panel tells you Every agent has this by default instead of offering a choice that wouldn't stick.
Kinds aren't split across separate tabs — a Slack bot and a Gmail account are rows in the same Accounts list, each badged for what it is.
Reading an app's status
Every row carries a coloured dot and a word, and they mean the same thing whatever kind of app it is.
| Status | What it means |
|---|---|
| Connected | Working. Nothing to do. |
| Needs setup | The workspace side is done but something is still missing — usually your own account isn't linked yet. |
| Needs attention | A credential exists but has stopped working. Reconnect to fix it. |
| Not connected | Nothing set up yet. |
Click any row to open its detail view: what it can do (its Actions, Webhooks, and Endpoints), which agents are using it, and every action available to you. Actions you can't take stay visible with the reason attached rather than disappearing.
Who owns a connection
Connecting an app is a personal act, not a workspace one. Whoever clicks Connect owns that connection, and that ownership — not an admin role — decides who can take it away.
| The person who connected it | A workspace admin | |
|---|---|---|
| Connect an app | Yes | Yes |
| Remove their own connection | Yes | Yes |
| Remove someone else's | — | — |
| Set where incoming work lands | — | Yes |
Try to remove a connection you didn't make and Nebula says so plainly: "Only the person who connected this can disconnect it. Connecting is personal now, so a workspace admin cannot remove someone else's connection." If the person who connected it has left and the connection has broken, connecting again replaces it with your own.
Admin standing still governs routing — where a bot's incoming work lands. That lives on its own page, because reading an installation's channel map reveals which workspaces a team's channels point at.
Using Slack from more than one workspace
A Slack team can be connected to several Nebula workspaces, and you can use it from any Nebula workspace you belong to. If the bot is connected but Nebula doesn't recognise your Slack account yet, the app's detail view offers Link my Slack account under Your account — a personal identity link, not an installation, so you don't need to be an admin.
When a connection is live somewhere else, Nebula says so on the row. It names the workspace when you're a member of it — "Connected in Acme — connect it here to use it in this workspace" — and stays vague when you aren't: "Your Slack account is connected in another workspace, not this one."
Either way the fix is the same, and it runs forwards rather than backwards: connect Slack from the workspace that wants it. There's no control for lending an existing installation to a second workspace from the workspace that already has it.
Having trouble connecting? Ask Nebula for help, or email support@nebula.gg.
Related
Using Miniapps
Every miniapp lives in its channel and shows up on the Miniapps page — open one alongside the chat or in fullscreen from the sidebar.
Webhooks
Create webhook triggers for your AI agent with Nebula. Let Zapier, Stripe, GitHub, and other tools send data and trigger automations in real time.