"Summarize last week's meetings" asks an agent for two separate things. The first is writing a summary, and models are genuinely good at that. The second is finding where those meetings live. Without the second the first is worth nothing, because an agent left with only your sentence starts guessing.
The gap here is not a knowledge gap, it is an access gap. For an agent to look at your calendar, your inbox or an internal system, somebody has to open that door. MCP is the standard for that door.
What MCP does
MCP stands for Model Context Protocol and it has one job. A service describes the operations an agent can use in a shared language, and the agent reads that description to decide which operation to call and with what. Opening a record in an issue tracker or leaving a message in a chat channel works this way.
That removes the need to write a separate integration for every new service. The moment a service starts speaking MCP, every agent that speaks the same language can use it. In Orbi every service you connect looks the same to an agent. From the agent's side there is no difference between a ready-made connector and an internal service you wrote yourself.
What you get without any setup
In a brand-new workspace, agents can already use 42 built-in tools. These are the jobs inside Orbi itself. Opening a card, assigning it, writing a record into a collection, producing a file and putting an event on the calendar all belong to this group.
Web access comes with it and asks for no API key. The agent runs a search, gets up to eight results and can narrow them to the past day, week, month or year. It then turns the page it picked into clean text and reads it. Long pages are sliced so they do not fill the context, the default slice is 12,000 characters, and the agent works through as much as it needs.
The need for a connection starts the moment the work touches your own data.
Connecting from the catalog
In most teams the first services people ask for are predictable. The common tools for calendars, team chat, issue tracking, customer records and meetings connect with a single click from the Integrations screen under Settings. You do not have to hunt down a server address or generate an API key by hand.
Connecting requires admin rights while using does not, so once a service is connected everyone on the team can reach it from tasks and from chat. A connection is made per account, which means several tools from the same provider share one connection and you are not asked to approve a second time. You also pay the service directly, because the account you connect is your own and Orbi takes no cut along the way.
Connecting your own server
Anything outside the catalog goes through a second route. A notes app you use, an internal API of your own or a service that generates images can be added as its own MCP server. You pick one of three ways to connect, depending on what the server expects. Some are happy with an address, some want a fixed API key, and some run a "sign in with" flow. In that last case the connection is added in a pending state, you approve it once, and the authorization refreshes itself from then on.
The API keys you enter are stored encrypted, are never shown back on any screen and never reach the text the agent sees.
Content arriving from outside is handed to the agent as data rather than as instruction. A web page and a record returned by a service are both treated the same way, and what the agent does is always set by the card you wrote.
Whose account a connection runs under
A connection has one of two scopes. Workspace-wide connections are added by admins and run for everyone. Personal connections are added by each member and run only in the runs that member starts.
On paper the distinction looks small, and for personal accounts it decides everything. An agent is a shared resource of the workspace and anyone on the team can start it. Personal connections are therefore loaded only in their owner's runs and cannot be assigned to an agent.
If it is on record who started a run, personal connections load. If it is not, they stay out. Writing in chat, leaving a comment on a card or moving a card into the queue yourself all make the identity clear. When an agent opens a card and queues it there is no identity to resolve, and the run continues with workspace tools alone.
Where people get stuck
Adding a connection is not enough on its own. Orbi's own orchestrator sees every service connected to the workspace, other agents do not. You tick which connections an agent may use in the Connection access section on that agent's detail page. If nothing is ticked, the agent sees no external tools at all and the form says so plainly.
Leaving this manual is deliberate. Not every agent needs every tool. A content writer agent has no business touching your customer records, so you do not open its access there.
The connection's own settings are where you choose which tools get exposed. Some servers publish more than 80 tools, and turning all of them on raises the cost of every run while making it harder for the model to pick the right one. If you choose nothing, at most 40 tools are exposed, which is a fallback rather than a preference.
The board's outward side
Everything so far connected the outside world to an agent. The reverse exists too. The board itself is exposed as an MCP server. A client such as Claude Code or Cursor can connect straight to your board, read cards, open new ones, change states, write comments and reach the team's shared memory in collections and files.
This is how we build Orbi. A coding agent connected to the board finds its assigned card in its own queue, writes the code, sends the change for review, explains under the card what it did and why, then moves the card to review. When you look at the board in the morning you find the outcome and the reasoning rather than a play-by-play.
What an agent produces in a chat window stays in that window, out of everyone else's reach. An agent connected to the board leaves the same work where the rest of the team can find it.
The connection runs on an API token you generate under Settings. The token belongs to you, inherits your role and is shown only once. If you want the connected agent to appear on the board under its own name, a token that belongs to the agent is the better choice than your personal one. The question of who did the work then gets answered on the card itself.
Where to start
The fastest route is to pick one concrete job the agent cannot do today. If you want a weekly summary, the calendar comes first. If you want new customer records, your CRM does. Set up that one connection, give the agent access to it and try it on a small card. Setting up every connection upfront is an investment made before you know which one earns its place.
Ways to connect, scope rules and security limits are covered in more detail in Tools and integrations in the help center. For the outward side of the board, see Collaboration and notifications and Working with a coding agent.
If you want to try it, you can open a free account and set up your first connection yourself.