Tools and integrations

Agents reach the outside world through four layers. To an agent they all look like the same "call a tool" action, and what differs is where they run and what setup they need.

#1. Built-in tools (54 tools)

These tools run inside Orbi itself and they need no setup at all.

Group	Tools
Task lifecycle	create_task update_task delete_task list_tasks read_task
Assignment and state	assign_task change_task_state move_task_to_project
Checklist and comments	add_checklist_item add_comment
Collections and schema	create_collection read_collection list_collections add_collection_field
Record operations	write_record read_record update_record delete_record search_records
Files and artifacts	read_file write_file update_file delete_file list_files save_file_from_url attach_file move_to_folder
Mind models	read_mind_model write_mind_model edit_mind_model
Flows	create_flow update_flow delete_flow list_flows
Calendar	create_calendar_event update_calendar_event delete_calendar_event list_calendar_events
Search and help	search_workspace read_help
Memory	save_memory recall_memory open_memory update_memory delete_memory
Channels	post_to_channel
Pulse	get_workspace_pulse, a "what happened since I last looked, what is stuck right now" report
Watching	watch_topic: when an admin tells Orbi "follow this", starts or stops a topic watched outside; list_watch_topics shows the list
Context	list_projects list_agents read_agent_config resolve_mention get_current_time

Here is what this list means. Inside Orbi an agent can do nearly everything you can do, so it opens tasks, assigns them, designs collections, writes records, produces files and puts events on the calendar.

Least privilege applies. The Orchestrator sees every tool. Directly assigned agents and sub-agents get a narrower set. A content writer agent has no access to deleting flows.

#Searching the workspace

An agent finds past work with search_workspace, and you run the same search from the box that opens when you press / (it does not work while a text field has the focus, where / is only a character). Both return the same results.

Here is where it looks.

Source	What is found
Tasks	Title and description
Deliverables	Everything the agent wrote into its "Outputs"
Comments	The discussion on a task
Files	File name, tags and the text extracted from inside them (PDF, Word, Excel)

Chats are not searched, because they count as private correspondence and are not indexed.

You do not have to type the whole word. Search works three ways at once.

• The beginning of a word is enough. Typing "mimar" brings up items containing "mimari", and "rapor" brings up items containing "raporları", because Turkish puts its suffixes at the end, so typing the stem is enough.
• Similarity in meaning works. A sentence like "which customers did we talk to last month" returns results too, and the words do not have to appear literally.
• Exact match works. It comes in when you are looking for a code, a name or a full phrase.

If a result row carries the "anlamca" label, that result was found by topic similarity rather than by a word match.

In the ranking a title match outweighs a body match, and at most two results come from the same task, so a single task cannot fill the list.

On the agent side the real benefit is this. Before starting a job it can check whether the job has been done before and what was decided. Without that, every task starts from zero.

On a new installation the search index is fed by content created after the feature was switched on. Older tasks may not come up in your first searches, and the list fills as every new comment, record and file enters the index. If you run your own installation there is a way to index past content in one pass, and the setup documentation explains it.

#The agent knows the product

The agent also holds this Help Center: the read_help tool reads the pages as an index, a page, a section or a search. On a question like "can Orbi do this", "where do I do that", and before saying "Orbi cannot", the agent looks here, answers from the page and quotes its address ("Settings › Sharing, see /docs/sharing"). A feature missing from the agent's tool list is not missing from the product; these pages are the source. Externally connected agents see the same tool through the Orbi MCP server.

#2. Zero-setup web access

This is connected to every workspace automatically, and no key and no setup are needed. There are two tools.

Tool	What it does
web_search	Runs a web search. It returns up to 8 results and has a day, week, month or year time filter.
fetch_web_page	Turns a page (including content built by JavaScript) into clean text.

The output of fetch_web_page is sliced, with 12,000 characters by default and 30,000 at most, so a long page does not fill up the context and the agent moves through as much of it as it needs.

#3. Connector catalog

The services teams use most often connect in one click, so you do not have to go looking for an MCP server. No connector is required.

The Settings → Integrations screen lists the accounts you have connected, one below the other. Each row is an account: the services it opens sit in the row as small labels, and how many tools it brings is written on its right. A Google account opens Gmail, Calendar and Meet together, so it stays in one row instead of three. Click the row and the account's panel opens; there you reconnect it, add a second account of the same service, remove the connection, and read what Orbi can do with that account, item by item.

To add a new service, open the catalog panel with the "Add connector" button. You can search by service name or by the job you want done, so typing "calendar" brings up Google Calendar, because the search scans tool names too.

Connector	What the agent can do
Gmail	Search the inbox, read and send email
Google Calendar	List events and create new ones
Google Meet	List finished meetings and read a meeting's transcript
Outlook	Search the mailbox, read and send email, list and create calendar events
Microsoft Teams	List teams and channels, read channel messages and post to a channel
Slack	List channels, read messages and post as Orbi
Telegram	Send messages to the chats your bot belongs to and read a chat's details
Jira	Search issues with JQL, read them, create them and add comments
Confluence	Search pages, read them and create new ones
HubSpot	Search and add contacts, see deals, add a note to a contact or a deal
Zoom	See upcoming and past meetings, schedule a meeting, reach the recording of a finished one
GitHub	List pull requests, read one with its changed files, read its diff, list its reviews and inline comments. Read-only
Zapier	Send an event to a "Catch Hook" Zap you built (one-way, Orbi → Zapier)

Here is what you need to know.

• Connecting needs the Admin role, using it does not. Once a connector is connected, everyone can use it in tasks and in chat. If it is not connected, the catalog says "Ask an Admin to connect it."
• A connection belongs to an account. "Connect to Google" happens once, and Gmail, Calendar and Meet share the same connection. Microsoft works the same way, so a single connection opens Outlook and Teams together (both work/school accounts and personal Microsoft accounts can connect). Several accounts from the same service can be connected as well, and each one keeps its own row, named by its address or site name.
• Removing an account switches off every service it feeds. Remove the Google account and Gmail, Calendar and Meet all stop. Orbi tells you what will be affected before it removes anything.
• Slack messages go out as the "Orbi" app and the bot can only read and write in the channels it was invited to (/invite @Orbi).
• You pay for the service. The account you connect is your own, and Orbi does not step in and take a cut of the usage. This holds for the whole catalog.
• On Telegram the bot is yours. Unlike the other services there is no account authorization. In Telegram you message @BotFather, create your own bot with /newbot, and paste the token it gives you into the dialog in Orbi. Then you add the bot to the group or channel whose messages you want it to read. In groups a bot only sees the commands addressed to it by default; if you want it to see every message, turn off privacy mode for that bot in BotFather. Messages Orbi sends to Telegram are plain text, so bold text and list markers do not show up.
• Zapier has no account authorization. You build a Zap that starts with "Webhooks by Zapier → Catch Hook" and paste the webhook URL that step gives you into the dialog in Orbi. That URL is a secret (anyone who has it can trigger the Zap), so it is stored encrypted. The connection is one-way: the agent sends an event and, optionally, a few fields with zapier_send_event, and Zapier sends nothing back. The rich MCP recipe you set up with a personal Zapier key is separate and stays in the catalog — one is where Orbi triggers Zapier, the other is where the agent calls Zapier's actions.
• A Google Meet transcript exists only if it was turned on during the meeting. Transcription is a Google Workspace feature and has to be on while the meeting runs; if it was off, Orbi has nothing to read and says so plainly. The transcript is not ready the moment the meeting ends, but a few minutes later. The Meet card added a new permission to the Google connection: if you connected Google before this feature, you need to reconnect once.
• To find a Zoom recording, the meeting must have cloud recording turned on. If it is off, Orbi cannot find the recording and says so plainly. The links it gives open the playback page on Zoom and they are not direct download links.
• GitHub is an installation, not an account authorization. When you click "Connect to GitHub", GitHub's install page opens, you pick the repositories the Orbi app is installed on, and you come back. The app only reads: Orbi never pushes code, opens branches or opens pull requests. In the installed repositories, every pull request whose title or branch name mentions a card (@task.12 or orbi/task-12) is linked to that card and its status shows on the card; the PR description is not scanned. Details on the Tasks page. Pull request events can also start a flow; see Flows. The account's panel shows which repositories are listened to; "edit" lets you check the ones you want from the installation. If none is checked, every repository in the installation is listened to. If you connected the same GitHub organization in two separate workspaces, you need to pick repositories: the installation is one per organization, and without a selection the same pull request lands on both boards. Orbi warns about this in the same panel.
• Access tokens are stored encrypted and refresh themselves. If the authorization is revoked, the account's row drops to a "reconnect" warning with the button right there; while it lasts, agents stop seeing that connection instead of quietly behaving wrongly.
• Which agent may use which connector is managed from the same access list as MCP servers. The Orchestrator sees all of them automatically, and other agents get them explicitly.
• Run steps show the service's logo. When an agent touches Gmail or Jira, the mark of that service sits next to that step in the run timeline, so you see which system was touched without reading the line.
• Sent emails go out formatted. Agents write their text in Markdown and Orbi converts it to HTML before sending, so the recipient sees headings, lists and tables properly. The original text travels in the same email for clients that read plain text.

#Zoom: adding, using and removing the app

This part is the guide for the Orbi app on the Zoom App Marketplace.

Adding it. An Admin opens Settings → Integrations, clicks "Add connector" and picks Zoom. Zoom's permission page opens; sign in with your Zoom account and allow the app. You then return to Orbi and the Zoom row shows your Zoom email address. Orbi asks for four permissions only: reading your own profile (to name the row), listing your meetings, creating a meeting for you and reading the recordings of your meetings. It does not act on anyone else's account.

Using it. Agents reach Zoom from tasks and chat. The Orchestrator sees the connection automatically; give other agents access from the same access list as MCP servers. Then you can ask for things like "list my meetings this week", "schedule a 30-minute call tomorrow at 10:00" or "send me the recording of yesterday's review". The meeting list includes each meeting's join link. Meetings are created in UTC with the time zone stated, so they do not shift. A recording is found only if cloud recording was on during the meeting, and the link opens the playback page on Zoom.

What Orbi keeps. The access tokens, stored encrypted, and the email address that names the row. Meeting lists and recordings are not copied into Orbi. What an agent read stays only as part of that task's history, like any other step.

Removing it. There are two ways, and either one is enough.

• In Orbi, open the Zoom row in Settings → Integrations and remove the connection. The tokens are deleted, and so is the Zoom access given to agents; to switch Zoom accounts, use Reconnect instead, which keeps that access.
• In Zoom, open the App Marketplace, go to Manage → Added Apps and remove Orbi. Zoom notifies Orbi, and Orbi deletes that Zoom user's tokens and account details from every connection they authorized. The row stays with a "reconnect" warning so that flows and agent access that use it do not break; remove it from Orbi too if you no longer need it.

#4. Your own MCP servers

MCP (Model Context Protocol) is the standard agents use to connect to outside services. You can connect Notion, a CRM, your own internal API, or an image or video generation service.

#Ready-made recipes

The Add MCP button opens a list first, and the address and the connection method of commonly used services are ready there. The list is a grid of cards, each showing the service's logo and a one-line description; the most widely used services come first. GitHub, Notion, Linear, Stripe, Zapier, GitLab, Cloudflare, Supabase, PayPal, Airtable, monday.com, ClickUp, Todoist, Calendly, Mailchimp, Sentry, Netlify, Webflow, Wix, Miro, Lucid, Postman, Datadog, Grafana Cloud, Neon, Prisma Postgres, PostHog, Mixpanel, Amplitude, Klaviyo, Algolia, Sanity, Cloudinary, Upstash, Railway, Replicate, Higgsfield, OpenRouter, Hugging Face, Tavily, Exa, Context7, DeepWiki, Resend, WorkOS, Honeycomb, incident.io, Attio, Close, Pipedrive, Apollo.io, Clay, Vibe Prospecting, Paddle, Brex, Mercury, Razorpay, Buildkite, Fireflies, Granola, Otter.ai, Superhuman, Readwise, Ramp, Vanta, Mercado Pago, ThoughtSpot, Hex, Morningstar, CoinDesk, Similarweb, Apify, SearchAPI, Stytch, InstantDB, Dodo Payments, Jam, Globalping, Egnyte, Workable, Bitly, Jotform, Mintlify, Turkish Airlines, AWS Knowledge, Microsoft Learn, MDN Web Docs, Twilio Docs, Cloudflare Docs, Astro Docs, Mermaid Chart, Wolfram, CoinGecko and Short.io are on that list. Type the service you are looking for and pick it, and the name, address and connection method fill in by themselves, so all that is left for you is connecting your account. Some services accept connections only from applications they have approved themselves. Such a service is not on the list, and even if you enter its address by hand, it turns you away at the authorization step.

Each row also says how the service connects. It either connects with your account (you give permission once), needs a key (you create a key in the service's own panel and paste it in) or asks for no sign-in. For services that need a key, the link to the page where the key is created is inside the form as well.

Some services need a setting turned on at their own end before you connect. When a recipe has such a prerequisite, it is written under the recipe on the add screen. GitLab is the example: unless GitLab Duo, beta features and MCP server access are on for your account, authorization goes through but the tool list fails with "the server does not serve MCP at this address". That error is fixed in the service's settings, not in Orbi.

You can always add a server that is not on the list by hand. The "Not on the list — I will enter the address myself" option under the list opens the older flow. The list is a shortcut, not the full set of services you can connect to.

#How it connects

There are three options depending on what the server wants, and you choose one on the add screen.

Method	When	How
No credentials	The server wants no secret	The address alone
Header	The server wants a fixed key	Header name (Authorization) + value (Bearer …)
OAuth	The server wants a "Sign in with…" flow (Notion, Linear…)	Tick "Connect with OAuth", then authorize once

With OAuth the connection is first added as "awaiting authorization". The Authorize button sends you to the provider, you give permission and come back. Tokens then refresh themselves and you do not have to sign in again. If the authorization is revoked or expires, the connection drops back to "awaiting authorization" and agents stop seeing those tools.

The keys you enter are stored encrypted, are never shown back on any screen, and never enter the text the agent sees.

#Scope: workspace or personal?

Scope	Who adds it	Whose runs it works in
Workspace-wide	Admin	Everyone's runs in the workspace
Personal	Each member for themselves	Only in runs that member started

Personal scope means someone who connects their own Gmail, or a service they pay for, does not open their account to the team. The guarantee is real. A personal connection cannot be assigned to an agent (the system refuses it) and Orbi's "sees every workspace connection" exception does not apply to personal scope. When another member runs the same agent, your connection is not loaded, not even when Orbi is the one running.

#Which spaces use it?

A workspace connection is used in Genel and every open space by default. If you pick Only the chosen spaces under the connection's Spaces it can be used in, only the runs, channels and flow triggers of the spaces you tick use it. For a connector this section is in the account's panel, for your own MCP server in the connection's edit dialog, and Save spaces saves it on its own.

A closed space uses the connection in either mode only when it is ticked, and only that space's manager can tick it. The space's manager can also make the same choice under Space settings → Connections. Closed spaces you are not a member of do not show in the list, and their choice stays as it is when you save. Opening a closed space to a connection is written to the Audit tab.

#Where a personal connection works and where it does not

The rule is one sentence. It works when there is a record of who started the run, and not otherwise.

Who started the run	Personal connection
You wrote in chat	✅ works
You wrote an @agent comment on a task	✅ works
You moved the task to Queued	✅ works
Another member queued the same task	❌ their connections apply, yours do not
An agent opened the task and queued it	❌ no identity
A scheduled task (cron)	⚠️ only if both conditions below are met

Sub-agent calls inherit the identity rather than widening it, so when one agent calls another, permissions do not grow.

Scheduled tasks need both of these.

1. "Allow in scheduled jobs too" must be ticked when you add the connection (it is off by default, because you see what happens in chat and you do not see what happens at 3 a.m.).
2. The person who last edited the schedule must be the one who created it. If another member changed the prompt, personal connections drop out and the run continues with workspace tools only. This stops "an instruction someone else wrote running with your account".

"Run now" is different. You are the one pressing the button at that moment, so it counts as attended and your personal connections work.

#Adding the connection is not enough: you must give the agent access

This is the most common place people get stuck.

• Orbi (the Orchestrator) automatically uses every MCP server connected to the workspace.
• Other agents work on least privilege, so an agent only sees the connections explicitly given to it.

You tick access in the "Connection access" section of the agent's detail on the Agents page. If nothing is ticked, that agent cannot see any external MCP tool, and the form says so plainly.

When you add a workspace connection, Orbi asks right away "Which agents should use it?". No agent is ticked in advance. The agents you tick get access; if you choose "Not now", you give access later from the agent page.

Removing a connection also deletes every agent's access to it, and adding the same service again does not bring that access back; the question comes again for the new connection. If you only want to switch accounts or renew an expired authorization, use Reconnect on a connector, or Renew authorization or Connection settings on your own MCP server, instead of removing it. Those keep the agents' access.

If you ask an agent without access for work that needs the service, the agent says the service is connected in the workspace but not open to it, and points to the Work tab of its agent page, where access is opened.

As for why it is not automatic, a tool that can write to a CRM or send email works more precisely in the hands of the one agent that does that job. You decide which agent may touch what.

#You choose which tools get opened

Some servers publish more than 80 tools. Opening all of them creates two problems. Every run costs more, and the model has a harder time picking the right tool. On top of that a server may publish tools that have nothing to do with the agent's job, and narrowing the list keeps the agent on its own work.

Connected servers are listed one below the other on the Settings → Integrations screen; the row carries the server's name, its address and how many of its tools are selected. Click the row and the server's panel opens: the tools it exposes are listed there one by one (click a name and its description unfolds), and authorization, settings and deletion live in the same place. From Connection settings → Tools to enable in that panel you tick which ones agents will see. If none are selected, all of them are open; however many tools a server publishes, none drops off the list.

A connection with many tools does not enter the agent's list from the start. The agent sees the connection's name and every tool it may use with a short description, picks the tools the job needs by name and loads them in one go, and they stay open for the rest of that run. One load brings at most 40 tools; if it needs more, the agent loads again. When the agent cannot load a tool it says why: the tool was not granted to it, it is turned off on the connection, or the server has no such tool. Small connections (a calendar or mail connection with a few tools) and Orbi's own web tools are always open directly. You do not pay for connections that are not used.

#Mentioning a connection and its tools

In a chat, a card, a comment, a flow step or an agent prompt you can name a connection. Type "@tool." and the suggestions list the connections first, with their logo and tool count; pick one and a marker such as @tool.design is added. The agent takes it that the job uses this connection and picks the tools it needs itself. Type "@tool.design." and only that connection's tools are listed; pick one and @tool.design.post_create is added, and the tool is in the agent's list from the start of the run.

Mentioning is optional. When you do not mention one, the agent finds the right connection and tool itself. In a chat, if two connections could do the job, it asks you which one to use; in card and flow runs it does not ask, and if no suitable tool is available it writes the real reason.

Connector tools and your own servers' tools appear in the same list as the built-in tools. If you made a tool selection, only the ones you picked are suggested. The list is short and gives every source a share. Each row carries the product's or the connection's name next to the tool name, and the search looks at both — typing "google" finds the Google Calendar tools even though their names start with gcal_. The tools of a server that was just added and never used may not appear in the list, and opening the connection's tool list once is enough. If you know the name you can type it by hand and the reference still works.

#Long-running jobs (image and video generation)

Services that generate images and video usually queue the job. The tool returns a job id straight away and the content is ready seconds or minutes later. The agent knows this, so when it receives a job id it asks the matching status tool for the result and saves it as a file once it is ready.

If the service reports no progress and the job is a long one (a video can take 1-3 minutes), raise the Settings → Tool call timeout value. The default is 60 seconds and the maximum is 600 seconds.

A one-time trust note is shown while you set up a connection. An MCP server gives tools to an agent, and what those tools do is the server's responsibility. Connect only servers you trust.

#Producing files and media over MCP

An MCP tool can return a file, such as a generated image, a video or a document. That content automatically becomes an artifact and appears in the File Manager.

Here is the important part. The returned content does not enter the agent's context raw. It is written straight to storage and the agent is told that the file was created. Otherwise a single video would consume a whole context.

As a result, agents do not have to understand the video, and producing it and putting it in the right place is enough.

For long generation jobs (video generation can take minutes) the tool call is waited on as long as it reports progress, and the timeout is refreshed along with the progress.

#Security protections

All four layers sit under the same protections.

• Internal network protection (SSRF). Web tools cannot be redirected to the internal network, to localhost or to cloud metadata addresses. The check runs after the address is resolved, which is why an address that looks innocent from outside but points inward is blocked too. The same protection covers save_file_from_url.
• External content is kept separate. Every piece of content that comes from outside, whether a web page, a file that was read or the body of an inbound trigger, is labelled and presented to the agent as data. So the agent's behaviour is always set by the task definition you wrote.
• The limit of autonomy. No approval is asked during execution, but every task has a budget cap and the agent's tool access is narrowed from the start. Details: Orchestrator.

#A note on autonomy

Task and flow execution has no runtime approval mechanism, much like a human colleague who does not ask for approval at every step. The balance comes from three things.

1. The agent's tool access being restricted from the start (least privilege)
2. Trust information and a deliberate choice when connecting an external MCP server
3. Human review at the Review stage