MCP in a team workspace: what a shared server actually gets

MCP runs in a team workspace when one server is registered once, by its address, and handed to the agents that need it, instead of being installed on each person’s laptop. In Nebula you add a remote MCP server by its public https:// address; Nebula registers it as a toolkit your agents can use, its key is held in workspace Variables, and agents call its tools from inside a channel [S1].

That is the whole answer in one paragraph. The rest of this page is what happens after the server is registered: which agent gets it, what owns the call, where the work runs, and where the answer lands.

The short version

MCP is a standard for the connection. It does not decide who owns the call, which machine executes it, or which room the result comes back to, and those are the questions a team is actually asking when it searches for “MCP team workspace”.

Nebula’s answer is structural. The server becomes a toolkit; the thing that uses it is an agent with its own name, its own tools, its own computer and its own tasks, sitting in your channel as a member rather than behind an integration wall. You bring the MCP server. You do not have to bring the agent.

What MCP is, and what it deliberately leaves to you

MCP (the Model Context Protocol) is an open-source standard for connecting AI applications to external systems: data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialised prompts. The documentation’s own analogy is a USB-C port for AI applications: one connector instead of a different cable per device. The version published as latest on the protocol’s site was 2026-07-28, read on 2026-10-22 [S6].

What that definition leaves out matters as much as what it includes. The protocol standardises the plug. It does not ship the agent that makes the call, the identity that owns the credentials, the computer the work runs on, or the conversation the result belongs in. Every “MCP team workspace” is an answer to those four gaps, and the answers differ more than the protocol does.

What an MCP server actually gets in Nebula

Nebula’s documentation covers MCP in one place, the Connections page, and the documentation index lists no separate MCP or integrations page [S1][S7]. Here is what that page and the pages it links to say a server gets once it is added.

A toolkit, added once, shared deliberately

Ask Nebula to add a remote MCP server by its public https:// address and it registers the server as a toolkit that any of your agents can use [S1]. You do not edit a config file per developer, and you do not re-install the server per machine. The documentation’s own example is a sentence in the channel: “Add our inventory MCP server for the whole workspace: https://mcp.example.com/inventory.”

One detail matters for teams: a server Nebula adds is private to you unless you ask for it to be shared with the workspace [S1]. Sharing is a phrase in the request, not a separate permissions screen. Changing or removing a server the whole workspace uses is limited to the person who added it; if nobody is recorded as having added it, a workspace owner or admin can [S1]. Removing a shared server never takes away anyone else’s personal sign-in: if teammates have connected it with their own accounts, the removal is refused and you are told how many connections are in the way, and each of them disconnects first [S1].

Secrets by name, not pasted into chat

The server’s key is saved under Variables and Nebula refers to it by name, so the secret never appears in a message [S1]. Values are encrypted at rest and only reach authorised agents in the workspace; deleting a variable cuts off every agent that uses it, so the documentation’s advice is to check before removing one [S1]. If a task meets a key that does not exist yet, it asks with a secure card in chat, and the value is stored as that person’s own encrypted variable rather than posted in the conversation [S1].

If the server signs in with OAuth, each person who needs it gets a Connect card and finishes the sign-in themselves [S1]. That is the difference between “the team has the tool” and “everyone’s permissions are one shared admin token”.

An agent that is a member, with its own tools

Each agent has a Tools panel: Toolkits lists what it can use, Connections lists the accounts it can act through, and Skills, Instructions and Memory sit beside them [S2]. So “the inventory server” is one toolkit, and which agents may call it is a per-agent decision rather than a workspace-wide switch.

Agents are also either private to their owner or shared with the workspace, with access levels from restricted to workspace edit [S2]. An agent pinned to someone’s own computer is private by definition: it cannot be shared, and only its owner can run it [S2]. That is the governance shape most teams want from an “MCP team workspace”: a shared capability, with named members holding scoped access to it.

A computer behind the call

Toolkits are not the only thing an agent can reach. A channel has devices, either a cloud device the workspace runs or your own computer, and Nebula works on the channel’s default device [S4]. A subscribed workspace starts with one small cloud device that comes with the seat, and cloud-device time draws on Nebula Credits, so a bigger device costs more to run [S4][S5].

So the result of an MCP call can be more than text back into the thread. An agent can take the records it pulled and act: write the file, run the script, open the pull request, on a machine that keeps running when laptops close.

Work that keeps going after the question

An MCP tool call is more useful when it is part of a task than when it is a one-off prompt. In Nebula a task can run now, on a schedule, or when something happens, and you follow it and answer its approvals without leaving the channel [S3]. Scheduled runs and monitors carry on without anyone watching: a task nobody is watching makes its best judgement rather than waiting for an answer, with one exception, permission to run commands on someone’s own computer, which is still asked and can only be approved by that computer’s owner [S3].

That is the piece a chat integration usually lacks. “Check the inventory server every Monday and post anything below reorder point” is a scheduled task, not a chat message.

Once several agents hold the same toolkit and hand work to each other, the question moves from the plug to the coordination, which is what our guide to multi-agent orchestration patterns covers.

One workflow, end to end

A team, a fictional inventory server, and the six steps that make it a teammate:

1. Someone adds the server. “Add our inventory MCP server for the whole workspace: https://mcp.example.com/inventory.” Nebula registers it as a toolkit [S1].
2. The key is saved once, by name. Under Variables, as INVENTORY_MCP_KEY; the agent refers to the name, never the value [S1].
3. People connect if the server asks. An OAuth server issues a Connect card per person, who finishes the sign-in themselves [S1].
4. An agent gets the toolkit. Open the agent’s Tools panel and it appears alongside its other toolkits [S2].
5. The team asks in the channel. Someone tags the agent in a thread, “which SKUs are below their reorder point?”, and it calls the server’s tool.
6. The answer lands where the question was, and can be scheduled. The reply posts in the thread; the same work as a weekly scheduled task posts its result on its own [S3].

Two neighbouring shapes work identically: triaging a ticket queue against an issue-tracker server, and drafting a weekly revenue note from a database server.

Two ways an MCP server can appear in Nebula

These are different things, and the documentation is explicit that they are not the same [S1].

• As a toolkit (the usual choice). A remote server added by its https:// address becomes a toolkit your other agents can use [S1].
• As an external agent. Under Settings → Account → External agents, a stdio MCP server launched on a device you pick becomes an agent that answers your messages: each message goes to one of its tools, and that tool’s result is the reply [S1].

An external agent brings its own tools and instructions, so Nebula toolkits and skills do not apply to it, and the device decides where it can answer: on your own computer it is yours alone, while a cloud device lets everyone in the channel run it [S1]. If you want the server to be shared, add it as a toolkit; if you want it to be an agent you talk to, add it as an external agent.

Where a pure MCP layer, or a chat app, is the better fit

This page is not the right answer for everyone, and saying so is more useful than a feature table.

• If the tools only need to reach one person in one client, you do not need a workspace. A remote MCP server configured in the IDE or assistant you already use is cheaper and faster. That is a solved problem and this page does not improve on it.
• If you need a gateway in front of a database with per-team permissioning and nothing else, a dedicated MCP gateway is a narrower, more auditable tool than a workspace.
• If your requirement is enterprise compliance, retention and eDiscovery, or the breadth of an app ecosystem built over a decade, Slack or Microsoft Teams is ahead, and no amount of agent-native framing changes that. We make the same point at length in our own comparisons rather than burying it: Nebula vs Slack, Nebula vs Microsoft Teams and Nebula vs Microsoft Copilot.
• If what you want is an agent inside the chat app you already live in, that is a different product category, and the honest pages for that question are Nebula vs Claude Tag and, for community chat, Nebula vs Discord.
• If what you need is a room for agents you already pay for, self-hosted or waitlisted, the closest shapes we have written up are Nebula vs Ando and Nebula vs Buzz.
• If the team is not ready to have agents posting in channels under their own names and holding their own credentials, a workspace adds governance work you have not signed up for. Start inside the tools people already use.
• Cost is real. Nebula is $25 per seat per month with a 7-day free trial [S5]; a client you already own plus a free local MCP server is $0.

Where Nebula is the better fit is narrower and specific: you want the MCP server reachable by several agents, with named identities, scoped per-agent access, a machine to act on, and work that runs on a schedule.

Limits worth knowing

There is no published count of MCP servers Nebula supports, no adoption figure and no benchmark, so none appears here. Nebula’s documentation also has no MCP-specific page; the canonical source is the Connections page, linked below [S1][S7]. Anything this page states about a third party is either a link to our own comparison page or a limit we are naming about ourselves, and the protocol, the pricing and the docs are dated reads, not permanent facts. If you have no MCP server yet, this page is about the workspace side of the connection, not the server side.

Start here

Read what an agent-native workspace is if the distinction above is new, or see how Nebula compares with the tools your team is weighing. Pricing and the free trial are on the pricing page.

Frequently asked questions

How do I add an MCP server to Nebula?

Ask Nebula to add a remote MCP server by its public https:// address. Nebula registers it as a toolkit your agents can use; save its key under Variables first so the secret is referred to by name, and finish the Connect card if the server uses OAuth [S1].

Can several agents use the same MCP server?

Yes. A server added to the workspace becomes a toolkit any of your agents can use, and each agent’s Tools panel decides which toolkits it actually has [S1][S2]. A server is private to the person who added it unless they ask for it to be shared with the workspace [S1].

Do agents see my API key?

They use it without seeing it. Keys live in workspace Variables, encrypted at rest, referred to by name, and reach only authorised agents; a key requested mid-task arrives through a secure card and is stored as an encrypted variable rather than posted in the conversation [S1].

What happens when nobody is watching a task?

Scheduled runs and monitors carry on and make their best judgement instead of waiting for an answer. The exception is permission to run commands on someone’s own computer, which is still asked and can only be answered by that computer’s owner [S3].

What is the difference between adding an MCP server as a toolkit and as an external agent?

A toolkit makes a remote server’s tools available to your other agents. An external agent makes a stdio server an agent that answers your messages directly, with its own tools and instructions, so Nebula toolkits and skills do not apply to it [S1].

Does Nebula host MCP servers for me?

Nebula’s documentation describes adding a server you run, remote by address or stdio on a device, and does not describe Nebula hosting an MCP server for you [S1][S7]. If you have no server yet, this page is about the workspace side, not the server side.

Sources

All URLs read on 2026-10-22. Prices and capability descriptions are dated and will move.

• [S1] Nebula docs, Connections: apps, API keys and external agents - https://docs.nebula.gg/docs/workspace/connections (read 2026-10-22): remote MCP servers added by public https:// address become a toolkit any agent can use; a server is private unless asked to be shared with the workspace; shared server changes are limited to whoever added it, else an owner or admin; removal is refused while teammates hold personal connections; Variables are encrypted at rest and referred to by name; OAuth servers issue a per-person Connect card; stdio MCP servers and API endpoints are set up as external agents under Settings → Account → External agents, and an external agent brings its own tools so Nebula toolkits and skills do not apply.
• [S2] Nebula docs, Agents and your channel’s team - https://docs.nebula.gg/docs/channels/agents (read 2026-10-22): the Tools panel lists Toolkits, Connections, Skills, Instructions and Memory; an agent is private to its owner or shared with the workspace with restricted / view / edit access levels; an agent that runs on your own computer stays private and cannot be shared.
• [S3] Nebula docs, Tasks, scheduled tasks and monitors - https://docs.nebula.gg/docs/channels/tasks (read 2026-10-22): tasks can be run now, scheduled, or set as a monitor; “a task nobody is watching never asks a question: a scheduled run or a monitor makes its best judgment and carries on”; the exception is permission to run on someone’s own computer, which only that computer’s owner can approve.
• [S4] Nebula docs, Devices: the computers your agents work on - https://docs.nebula.gg/docs/channels/devices (read 2026-10-22): devices are a cloud device the workspace runs or your own computer; each channel has its own devices and Nebula works on the channel’s default device; a subscribed workspace starts with one small cloud device that comes with the seat; cloud-device time draws on Nebula Credits and a bigger size draws more.
• [S5] Nebula pricing - https://www.nebula.gg/pricing (read 2026-10-22): $25 per seat / mo, 7-day free trial, unlimited messaging, calls and research, cloud computer, bring your own Claude or ChatGPT subscription at no extra charge, Nebula’s own agents draw on Nebula Credits.
• [S6] Model Context Protocol, What is the Model Context Protocol (MCP)? - https://modelcontextprotocol.io/docs/getting-started/intro (read 2026-10-22; the site shows “Version 2026-07-28 (latest)”): MCP is an open-source standard for connecting AI applications to external systems, covering data sources, tools and workflows, described as a USB-C port for AI applications.
• [S7] Nebula docs index - https://docs.nebula.gg/llms.txt (read 2026-10-22): the index lists no MCP-specific or integrations page; MCP is covered on the Connections page.