.png)
Your agent needs meeting context from Fathom: what a customer objected to, which action items came out of Tuesday's QBR, what a prospect said across five calls. Fathom ships two first-party paths to that data. One is a hosted MCP server. The other is the REST API with webhooks.
They don't expose the same capabilities. They put you on different auth models. They fail differently at scale.
For a multi-tenant B2B agent, this choice shapes your credential model more than your prompt does. Here's how to pick.
Both paths are maintained by Fathom and share one permission model. An agent only sees meetings the connecting user can already view in Fathom.
Fathom added its official MCP server in April 2026, per its developer changelog. It's a hosted remote server, so there is nothing to deploy. Claude and ChatGPT users connect through Fathom's official connector and app. Claude Code connects through the mcp-remote bridge, which requires Node.js.
Each user authenticates through a browser sign-in and consent flow. Fathom's help center is explicit that MCP adds no new categories of data; it makes existing meeting context easier for an assistant to retrieve.
Fathom's developer portal covers setup but doesn't publish a tool reference. Scalekit's Fathom MCP connector exposes nine tools from the server.
The REST API, SDKs, and webhooks launched in October 2025. June and July 2026 added meeting types, highlights, recording downloads, and a users-and-permissions endpoint. The surface covers meetings, per-recording summaries and transcripts, teams, team members, users, webhooks, and downloads.
Auth takes one of two forms. You can send a per-user API key in the X-Api-Key header. Or you can use OAuth 2.0 through a registered marketplace app, which is Fathom's path for products that other Fathom users install.
The API has no LLM affordances. Pagination, rate limits, and schema shaping are yours. The full reference lives in Fathom's official API documentation.
Four dimensions decide the path: capability coverage, auth model, operational ownership, and fit to the agent pattern.
The MCP server is built for questions. The API is built for pipelines. The tables draw on Scalekit's Fathom MCP connector and Fathom's API reference, starting with retrieval.
The second table covers the pipeline and admin surface. Here the MCP server has almost nothing to offer.
The MCP server wins on the retrieval problems agents hit first. Fathom's FAQ confirms the API can't query by attendee and can't resolve a call link to a recording_id. The MCP server does both.
Rebuilding search_meetings on the API means paging through /meetings 10 records at a time and filtering client side. That burns your rate limit on every question.
The API wins wherever the agent needs to react or manage. Every MCP tool is a read. You can't subscribe to new-meeting events, pull media, or read org permissions through MCP. An agent that should act the moment a call finalizes needs the API's webhooks.
The two paths differ on credential type, consent flow, and what happens when a person leaves. The next four sections take each in turn.
Fathom API keys are per user, and there are no org-level keys. A key sees what its owner can view: their own recordings plus meetings shared with them or their team.
For org-wide reads, Fathom's guidance is to grant an admin view access to all shared calls and use that admin's key. Private calls stay visible only to their host, whatever key you use.
OAuth apps need HTTPS redirect URIs. Refresh tokens are one-time use and rotate on every refresh. If two workers refresh the same connection at once, one gets an HTTP 400. OAuth apps also can't use include_summary or include_transcript on /meetings.
The MCP server triggers a browser authorization the first time each user connects. The client reuses that grant afterward.
In Claude team and enterprise workspaces, an owner must enable the Fathom connector before members can see it. There's no API-key option on this path. A headless agent can't bootstrap MCP access until a human completes consent once.
Fathom's OAuth documents exactly one scope, public_api. An API key has no scopes at all.
Whatever the user can view, the credential can read. If your agent only needs summaries, Fathom gives you no way to issue a summaries-only credential.
Least privilege has to be enforced in the tool layer that sits in front of the credential. That's an architectural requirement, not a nice-to-have. For a deeper look at why static credentials break in production AI systems, the tradeoffs map closely to what you'll face with Fathom.
Fathom's FAQ is blunt. Admins can't revoke another user's API key. A key stops working only when that user is deactivated or removed.
A key whose owner leaves a team keeps working, just with narrower permissions. Suppose a user pastes their key into your agent and later changes roles without being deactivated. Your agent still holds a working credential.
Revocation has to exist on your side of the boundary. Fathom won't do it for you. This is the same problem covered in depth for revoking employee AI agent access when someone leaves.
Operational ownership splits sharply between the two paths. The four sections that follow cover the MCP path, the API path, rate limits, and webhooks.
Fathom owns the server, the tool schemas, and the tool descriptions, which are written for LLMs. The list_teams description tells the model not to guess team names. The transcript tool says to fetch at most three transcripts per query because they're large.
You own per-user token storage, refresh, and revocation.
Fathom doesn't publish a versioned MCP tool reference, so the tool surface can change when Fathom updates the server. Test against tool behavior, not a static list.
You own everything. That includes cursor pagination with a fixed page size of 10, 429 handling, retries, and schema shaping for the LLM. It also includes the full credential lifecycle.
Fathom's official SDKs retry rate-limited calls using the Retry-After header. Raw HTTP clients must implement that themselves.
Fathom caps each API key or OAuth token at 60 calls per minute. Heavy requests are capped at 30 per minute, and Fathom can drop that to 5 during elevated activity. Heavy means summary and transcript endpoints, or /meetings with include_summary or include_transcript set. Recording downloads carry their own 30-per-minute limit.
A nightly agent that pulls 200 transcripts for one user needs about seven minutes at the normal ceiling. At the degraded ceiling it needs 40 minutes.
Design for the low number. Fathom doesn't document MCP-specific limits.
Webhooks fire once when a recording finalizes and never re-fire on edits or visibility changes. Retries reuse the webhook-id header, so deduplicate on it.
The payload doesn't say which user's key the webhook belongs to. Fathom recommends a separate destination URL per user.
The webhook's own id is returned only at creation. Lose it and you can only delete the webhook from Fathom's UI.
Pick by agent pattern, not preference. MCP fits agents that answer questions about meetings.
The API fits agents that act on meetings without a human watching.
Both paths hand you one credential per user. Neither hands you a vault, a refresh coordinator, or a revocation switch.
In a multi-tenant B2B agent, every rep, CSM, and founder connects their own Fathom account.
On the API path, that's N long-lived keys that never expire and that admins can't revoke. On the MCP or OAuth path, it's N token pairs with one-time-use refresh tokens, where a race between two workers breaks the connection.
The token type differs. The infrastructure you need doesn't. Understanding how to handle token refresh for AI agents is foundational before you build at N-user scale.
The shortcut is one admin key with view access to all shared calls. It works in a demo.
In production, every user's agent reads the same org-wide corpus. Private calls stay invisible to everyone but the host. The audit trail shows one admin behind every action.
Shared credentials are a single-user solution. They do not survive a second user.
Recommended Reading: Single-tenant vs multi-tenant tool calling and agent auth
Scalekit's Fathom connectors store each user's credential in a token vault. On every execute_tool call, Scalekit resolves the right credential for that user, so credentials never touch the agent runtime.
The same model covers both paths. The Fathom connector holds per-user API keys and exposes 11 tools. The Fathom MCP connector runs OAuth 2.1 with Dynamic Client Registration (DCR), handles token refresh, and exposes 9 tools.
The MCP vs API decision stops being an auth-infrastructure decision.
Recommended Reading: How to Handle Token Refresh for AI Agents
The examples use Python, because today the Python SDK can mint Virtual MCP session tokens and the Node.js SDK can't. There are two agents. The first calls the Fathom API connector directly through the Claude SDK. The second uses LangChain over a Virtual MCP server that combines Fathom MCP, Fathom API, and Slack tools.
In the Scalekit dashboard, go to AgentKit > Connections and create a Fathom connection and a Fathom MCP connection. The API-key connection has no redirect URI or OAuth app to configure.
Connection names in code must match the dashboard exactly; a mismatch is the most common integration error. The examples assume fathom, fathommcp, and slack.
The two connectors onboard users differently. For the API-key connector, the user pastes their key into your settings page and your backend stores it as a connected account. For the MCP connector, the user completes Fathom's OAuth consent through a Scalekit authorization link.
In the Python SDK, API-key credentials go under authorization_details with a static_auth block.
Before the agent runs, it loads its tool surface. It doesn't load a flat Fathom catalog. list_scoped_tools returns only the tools the current user's connected account is authorized to call, filtered further to the three this agent needs.
Each scoped tool also carries a connected_account_id. The loop uses it to run every call as the right user.
The loop runs until Claude stops requesting tools. Each tool call goes through execute_tool with the user's connected_account_id, so Fathom sees that user's key and nobody else's.
Errors go back to the model as is_error results instead of crashing the run. That matters for Fathom's 429 responses on heavy summary calls.
The full pattern is in the Anthropic example in Scalekit's docs.
A call-recap agent needs Fathom MCP's retrieval tools, one Fathom API tool, and Slack. Wiring three raw connectors exposes 9 Fathom MCP tools, 11 Fathom API tools, and 96 Slack tools. At roughly 200 tokens per tool, that's over 23,000 tokens of context before the agent does any work.
A Virtual MCP server declares exactly which tools the agent sees. One server definition serves every user, and each run gets a short-lived session token bound to one user's connected accounts. The endpoint is static; the identity is per user.
Recommended Reading: Virtual MCP Servers: scoped, per-user tool access for agents
Create this configuration once, not once per user. Save the returned config_id and mcp_server_url as environment variables for your agent service.
Before each run, confirm the user's connections are active, then mint a token. OAuth grants on the Fathom MCP and Slack connections can expire or be revoked at any time. The Fathom API connection only needs the key saved during onboarding.
LangChain connects through langchain-mcp-adapters, using the server URL and the user's session token as bearer auth. The agent sees exactly six tools, which is the whole surface this role needs.
Scalekit's LangChain example and Virtual MCP setup guide cover the same pattern for other connectors. For a practical look at how LangChain tool calling works and where it stops, that walkthrough maps directly to the patterns above.
Webhooks are where the API path earns its place. Because Fathom's payload carries no user identity, create one webhook per connected account, with an opaque user ID in the destination path.
Persist the returned webhook id, because Fathom never returns it again.
Fathom won't let an admin revoke a departing user's key, so revocation happens on your side. Deleting the webhook and both connected accounts removes the agent's access immediately.
The key itself stays valid at Fathom until that user is deactivated. Your agent just no longer holds it.
When a Fathom agent misbehaves, you need to know which user's credential made which call, and what Fathom returned. In the dashboard, AgentKit > Connected Accounts shows each account's status, refresh history, and tool execution logs.
Rate-limit errors are labeled by source. RATE_LIMITED means Scalekit's own limit. TOOL_ERROR means Fathom returned the 429, and the tool call logs carry Fathom's message. With a 5-per-minute degraded ceiling on heavy calls, that distinction saves hours.
Recommended Reading: Agent tool observability
If your agent answers questions about meetings, build on Fathom MCP. Search, speaker lookup, and call-link resolution are things the API can't do, and Fathom maintains the tool descriptions for you.
If your agent acts when meetings end, build on the API: webhook-driven CRM updates, follow-up drafts, backfills, or anything that needs downloads or org permissions. Design around the heavy-request ceiling from day one.
Most production Fathom agents want both. Retrieval comes through MCP and triggers come through the API, combined in one Virtual MCP server.
Either way, the credential problem is identical. That's the part that needs production-grade infrastructure. For a broader look at credential ownership across agent tool-calling patterns, the same architectural questions apply regardless of which Fathom path you choose.
Start from the connector docs: Fathom connector and Fathom MCP connector. Or browse the product pages for the Scalekit Fathom connector and the Scalekit Fathom MCP connector.
For a head start, adapt the meeting prep agent template, the sales call prep agent template, or the CRM AI agent template by swapping in Fathom as the meeting source. Compare with Granola MCP vs Granola API and Zoom MCP vs Zoom API for AI agents.
