Tools & MCP¶
Every agent is assembled from a catalog of built-in tool categories you switch on or off in the agent's Tools settings. Each category unlocks a capability the agent can use during a conversation. Beyond the built-in catalog, you can connect MCP servers to give the agent tools and data sources that aren't built into the platform.
Built-in tools¶
| Tool | What it lets the agent do |
|---|---|
| Vector Search | Search the knowledge collections linked to the agent. On by default. |
| Document Reader | Read full documents from linked collections, not just search snippets. |
| Web Search | Search the public web for up-to-date information. |
| Web Browser | Fetch and read web pages. |
| Browser Control | Interactive browser automation (see Computer use & browser). |
| Python | Run Python code in an isolated environment. |
| Sub-Agents | Spawn helper agents to work on parts of a task (see Agent teams). |
| Send Email | Send email from the platform's shared inbox. To send from — or read — a real mailbox, give the agent a mailbox instead; its tools need no toggle. |
| Image Generation | Generate images (see Media generation). |
| Video Generation | Generate short videos (see Media generation). |
| Database | Read and write the agent's own structured data under policy (see Agent database). |
| Workflows | Run multi-step workflow pipelines (see Workflows). |
| Computer use | Control the apps you granted it on a paired device (see Computer use & browser). |
Vector Search, Python, and Document Reader are on by default for every agent.
Some tools have prerequisites before they do anything useful — for example, Web Search and Web Browser need web access configured, Send Email needs the platform inbox to be set up by your administrator, and Computer use needs a paired device. Turning the toggle on makes the capability available; wiring up its dependency (an integration, a knowledge collection, a media provider, and so on) is a separate step.
Python libraries¶
The Python tool comes with these libraries already installed: requests, beautifulsoup4, lxml, numpy, pandas, openpyxl, httpx, Pillow, pypdf, pdfplumber, pypdfium2, pdf2image, pytesseract, defusedxml, python-pptx, python-docx, reportlab, markitdown, weasyprint, matplotlib, vtracer, duckdb, pytz, ruff, cairosvg, pymupdf, opencv-python-headless, scipy.
The agent can ask for any other package when it runs code. Installing a package adds time to that call. There is no C/C++ compiler, so packages published only as source code can't be installed.
Connecting external tools via MCP¶
MCP (Model Context Protocol) is an open standard for connecting an agent to external tools and data sources. You manage connections under the agent's MCP servers settings, and each connected server contributes its own set of tools that the agent can call.
There are two ways to add a server:
- Install package — install a published MCP server straight from the npm or PyPI registry. You give a package ID (for example, a filesystem or git server) and the platform downloads and configures it automatically.
- Manual config — point the agent at a server yourself, choosing a transport:
- Standard I/O — a server that runs as a local process (most common).
- HTTP — a remote server reachable at a URL.
On the agent's MCP servers panel, Add server → With the assistant opens the account assistant, which can find and connect a server for you instead, including signing in via OAuth where a server needs it.
In the Android app the same panel is MCP servers in the builder's menu. Each server has an Enabled switch and, on v2 agents, a Shared / Per person switch that sets who connects — see Shared vs per-user connections; on a published agent the app asks you to confirm first, because people see the change only after you republish. A server shows which of your connections supplies its credentials. Test connection checks that the server starts and lists its tools, Sign in completes OAuth where a server needs it, and Delete removes it. Add MCP server offers From my connections (a server already in your Connections library), New server (a URL or a command, with environment variables and headers) or With the assistant.
For each server you can set a display name, a per-call timeout, and any environment variables or API keys the server needs — these are encrypted at rest. On a workflow's Action step, a call that runs past its timeout is retried automatically, the same as a dropped connection; for a tool that makes a change, the retry can make that change twice. Servers can be toggled on and off individually, and Test connection verifies that the server starts and lists its tools.
What a server can do¶
When you add, save, enable, or connect an MCP server, the platform reaches out to ask which tools it offers and stores the answer. This happens in the background, so a newly added server's tools appear a moment later rather than the instant you save — and if the server is slow to start the first time (a freshly installed package often is), the platform retries a few times on its own instead of giving up after one attempt (a server that stays down longer keeps its tools unconfirmed until it recovers). Test connection does the same check on the spot: it's no longer a step you have to remember, just a diagnostic you can run any time to see the current list right now. Changing a server's address, command, or credentials marks the stored list as unverified — the tools stay visible, but the platform re-checks the server against its new settings before a workflow is allowed to rely on them.
A workflow step can only use a tool that's on a server's stored list. A step that names one that isn't there fails validation, and the Builder is told which tools the server actually offers, so it can fix the step before the workflow is ready to run. For a server whose list hasn't been filled yet, the platform tries once more to reach it before validating: if that succeeds, the step is checked against the fresh list; if the server still doesn't answer, validation fails and points you at the server's settings instead of the step. If the server needs OAuth and its authorization has lapsed, validation says so and points you at Connect rather than at the settings.
This check is only as current as the last time the platform heard from the server. When a tool quietly disappears on the server's own side, the next save usually picks it up: the platform re-reads the list and stores the shorter one. A server that stops offering any tools is the exception — an empty answer is treated as a blip rather than the truth, so the last known list is kept. Test connection replaces it with whatever the server says now. Changing the server's address, command, or credentials marks the list unverified instead of erasing it: the tools stay on screen, but the platform re-checks the server before the next publish rather than trusting a list that was gathered from the old settings. If that re-check fails, publishing is refused and points you at the server's settings rather than at the step — the same way it does for a server that has never been filled. Until a re-check happens, validation still sees the old tool, and the run is what catches it, the next time the step tries to use it.
Shared vs per-user connections¶
Each MCP server (and each Google integration) has a connection mode:
- Shared (my connection) — the agent uses the owner's own connection for every user it talks to, and in every workflow run.
- Each user connects their own — every end user connects their own account before they can use the server's tools, and the agent acts on that person's data — in chat, and in the workflow runs that act as that person, whose steps call the server on their connection. Their connection is saved to their Connections library, so it can be reused across agents that need the same connection.
An environment variable on an MCP server can also be marked "Filled by each user" instead of set once by the owner — each end user supplies their own value the first time they need it.
Personal connections and per-user environment variables require a v2 agent; v1 agents only support the shared-connection mode.
Shared connections on a shared agent
On a shared or published agent, a server set to Shared (my connection) shows a warning badge in the owner's Connections library — Everyone using <agent> uses your credentials — because every person who talks to the agent acts through the owner's own connection, in chat and in their workflow runs. Switch to Each user connects their own if that's not what you want.
OAuth connections to MCP servers¶
Some hosted MCP servers require you to sign in to an external account rather than paste an API key. The platform detects this automatically: when a server needs it, it is marked "This server requires OAuth authorization" with an Authorize button.
Clicking it opens the provider's sign-in screen in a popup. Once you approve access, the server shows OAuth authorized and the agent can use it. If access later lapses, the server shows OAuth authorization expired — reconnect, and you re-authorize the same way. Tokens are refreshed automatically in the background and stay within the platform.