Your Pod agents are only as capable as the tools they can reach. Out of the box, Pod's agents know how to read your CRM and work with the core context Pod ingests for every deal. To let an agent actually do things — draft an email in Gmail, update a page in Notion, change a ticket in Jira, build a slide in Google Slides — Pod connects to those tools through MCP servers.
This article explains how your workspace gets new tools for its agents, how to connect a new MCP server, how to decide which of its tools your agents are actually allowed to use, and how to troubleshoot a server that is not working.
If you want the full picture of what happens when an agent uses one of those tools — the approval card, the status badges, the failure reasons — read Manage agent actions alongside this one.
Three ways to give your agents new tools
There are three complementary paths to make a tool available:
Pre-built MCPs (ready to connect). Pod ships a set of MCP servers that are already added to your workspace. You don't set a URL, paste a token, or configure OAuth — you just connect the underlying product from Settings → Integrations and the MCP is ready for your agents to use. For example, connecting HubSpot automatically enables HubSpot MCP for every user in the workspace.
The MCP registry. For anything outside the pre-built set, Pod can search the official MCP registry from inside the Add server drawer and prefill the server metadata. This is the fastest way to connect a well-known public MCP without pasting a URL.
Bring your own (manual entry). If the MCP you want isn't in the registry — for example, an internal MCP your platform team is hosting, or a preview-release MCP from a vendor — you can paste the remote URL directly and configure auth by hand.
You can mix all three. A workspace can run a pre-built MCP, a registry-sourced MCP for a public tool, and a private internal MCP all at the same time.
Where to find MCP Servers in Pod
Open Pod.
Go to Settings.
Select MCP Servers.
The page has two tabs:
Personal — servers only you can use.
Org-wide — shared servers available to the whole workspace. Non-admins can view this tab in read-only mode; only workspace admins can add, edit, validate, toggle, or delete org-wide servers.
MCP Servers lives in the Pod web app. The Chrome Extension does not have its own MCP settings — connect and manage your servers from the web app, and the Extension will pick up the same tools automatically.
Using the pre-built MCPs
Pre-built MCPs look and behave like any other server card on the page, with a few differences that keep them safe to use as a managed integration:
They show up automatically once you connect the underlying product under Settings → Integrations. You never have to add them by hand.
Their URL, auth, and OAuth client are managed by Pod, so you won't see an Edit option in the card's overflow menu — those fields are not yours to change.
If the underlying product disconnects in Pod (for example, if the HubSpot integration is disconnected), the card will show a short message telling you to reconnect the integration. Fixing the integration under Settings → Integrations brings the MCP back online — there's nothing to re-do on the MCP page itself.
You still control which of the pre-built MCP's tools your agents can actually call. The server-level switch and the per-tool switches on the card work the same way they do for any other MCP — see the next two sections.
Connect a new MCP server
For any tool outside the pre-built set:
Open Settings → MCP Servers.
Choose the Personal or Org-wide tab, depending on who should have access.
Click Add Personal Server or Add Org-wide Server.
Choose a setup method:
Directory — search the official MCP registry by server name, description, or URL. When you pick a result, Pod prefills the display name, URL, and likely auth mode.
Manual Entry — paste the remote server URL yourself and set a display name. Any valid https:// endpoint works.
Pick an authentication mode:
None — the server does not require authentication.
Bearer token — paste the token Pod should store securely.
Custom header — enter the header name (for example, X-API-Key) and the header value.
OAuth — Pod saves the server first, then opens the provider authorization flow so you can finish OAuth. Some providers require both a client ID and a client secret.
Click Save server.
After saving, Pod validates the connection and discovers the tools the server exposes. The card appears in the list with a health indicator and a tool count.
Choose which tools your agents can use
Every MCP server exposes a list of tools, and every tool has a classification and a per-tool switch. This is where you decide what the agent is actually allowed to touch.
Expand a server card to see the Discovered tools table. Each row has:
Tool name — the name reported by the MCP server.
Access — a badge that classifies the tool:
read — the tool only reads data.
write — the tool makes changes in the connected system. Every write use flows through Pod's approval workflow, so nothing is written until the user who ran the agent approves the action.
ambiguous — Pod could not classify the tool confidently. Treat it like a write tool until you verify.
Enabled — a per-tool switch controlling whether agents can call the tool at runtime.
On top of that, the server card itself has a top-level switch that turns the entire server on or off without changing the per-tool settings.
A typical pattern:
Leave read tools enabled by default.
Review write tools case by case and only enable the ones you want your agents to use.
Treat ambiguous tools as write tools — enable them only after you've confirmed what they do.
When the MCP server updates its tool list upstream, or after you refresh credentials, use the Refresh server option in the card's overflow menu to pull the latest inventory.
Personal vs org-wide servers
Personal servers are tied to your Pod user. Only you can use them. Your agents can call their tools; teammates cannot. This is the right choice for experiments, your own tokens, or anything tied to your personal accounts.
Org-wide servers are shared. Every user in the workspace can use their tools, subject to the server's own permissions. Only admins can add, edit, refresh, or delete them.
Sharing OAuth connections across the workspace
Org-wide OAuth servers have a second decision: how the workspace actually authenticates against the provider. In the Add Org-wide Server drawer, an admin picks a Sharing model:
Shared workspace install — the default. Every user in the workspace authenticates individually against the provider. Revoking one user's access does not break the server for others.
Share my admin-owned user grant — the admin's own OAuth grant backs the whole workspace. Pod requires the admin to explicitly acknowledge a warning before saving this option, because if that admin's grant is revoked, expires, or loses provider access, the shared server can stop working for everyone.
Use Share my admin-owned user grant only when the provider does not support per-user installs and you've accepted the risk.
Health statuses and troubleshooting
Every server card has a small colored dot next to its name. The status reflects the most recent health check:
Healthy — Pod can reach the server and use its tools.
Pending — Pod has not yet validated this server after the most recent change.
Auth required — The server requires OAuth and the connection hasn't been finished. Use the Connect button on the card to complete it.
Refresh failed — Pod tried to refresh the provider's token and the refresh failed. Re-run OAuth or update the saved credentials.
Unhealthy — The server returned an error during validation. The most recent error appears under Latest health detail on the card.
When an agent action fails because of one of these conditions, the failure reason on the action card in Manage agent actions points back to this page:
Tool disabled — the per-tool switch is off. Flip it on in the Discovered tools table and retry.
Server disconnected — the server is offline or was removed. Reconnect or recreate it here.
Auth expired — the saved credentials expired. Reconnect OAuth or update the saved token or header value, then refresh the server.
Security model
Saved bearer tokens, custom header values, and OAuth client secrets are write-only in the UI. Once saved, Pod never reads them back into the form — so when you edit a server, those fields appear blank. Leave them blank to keep the existing credential, or enter a new value to replace it.
Deleting a server removes the saved connection, the OAuth state, and the tool inventory. Any agent that was relying on that server loses access immediately.
Write tools never run silently. Every write call surfaces as an approval card the user must act on — see Manage agent actions for details.
MCP server settings vs API keys
Settings → MCP Servers and Settings → API both mention "MCP" but solve opposite problems:
MCP Servers is about Pod connecting outward to external tools so your agents can use them inside Pod.
API keys is about external systems connecting inward to Pod through VoiceMCP — for example, letting an external MCP client read Pod data through our API.
If you're extending what your agents can do inside Pod, you want MCP Servers. If you're giving an external system programmatic access to Pod, you want API.
💡 Need help? Send us a message via the in-app chat or email us at [email protected].
🤝 Want to talk to someone? Book a session with one of our specialists.