Which integrations are available for this server?

Provides tools to interact with Fathom meetings and transcripts, allowing listing recent meetings, retrieving the latest meeting, and fetching raw transcripts.

How do I use fathom-mcp-adapter?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fathom-mcp-adapter list my recent meetings" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

fathom-mcp-adapter

by enrique-pastrana

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

fathom-mcp-adapter

Read-only MCP server that exposes Fathom meetings + transcripts as tools, for use by /updateP1 (and other skills) in the TICKETS workspace.

This is a private, standalone adapter: its own git repo, its own .env. It is not part of ia-tooling and does not depend on its stack — it only makes HTTPS calls out to the Fathom REST API (https://api.fathom.ai/external/v1). It was scaffolded by cloning the structure of ia-tooling/services/zendesk-mcp-adapter.

Architecture

The adapter is the MCP server. Internally it calls the Fathom REST API directly (just as the Zendesk adapter calls Zendesk's REST API). MCP servers are not chained to one another.

Auth: per-user API key sent as the X-Api-Key header. The key is scoped to one user (their own meetings + meetings shared to their Team), which provides data isolation between teammates. Rate limit: 60 req/min.
The adapter returns the raw transcript. The who/what/when summary is produced by the /updateP1 skill, never by a tool here.
There is no title/keyword search in the Fathom API. To find a specific meeting, list recent meetings (optionally narrowing by created_after / recorded_by) and let the skill filter by title/date/invitee.

Related MCP server: Fathom AI MCP

Tools

Tool	Purpose
`fathom_health`	Config/connectivity check (makes one authenticated call).
`fathom_list_recent_meetings`	List recent meetings, newest first. Filters: `created_after`, `created_before`, `recorded_by`, `invitee_domains`, `meeting_type`.
`fathom_get_latest_meeting`	The single most recent meeting (the 90% case for `/updateP1`).
`fathom_get_transcript`	Raw transcript for a `recording_id`.

Each meeting record includes title, recording_id, created_at, url (private, login-gated) and share_url (team-shareable). For the internal timeline reference use share_url, never url.

Setup

npm install
cp .env.example .env   # then fill in FATHOM_API_KEY
npm test
npm start              # speaks MCP over stdio

FATHOM_API_KEY must come from .env (which is git-ignored) — never hardcode it.

Wiring into the TICKETS MCP session

Build the image and add a fathom entry to the TICKETS .mcp.json, alongside zendesk / vectordb / github. It does not need the ia-tooling_default network (HTTPS egress only).

docker build -t fathom-mcp-adapter .

// .mcp.json (TICKETS)
{
  "mcpServers": {
    "fathom": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "--env-file", "/ABSOLUTE/PATH/TO/.env", "fathom-mcp-adapter"]
    }
  }
}

Fallback

If the Fathom MCP server is down, /updateP1 falls back to the manual "paste-me-the-transcript" mode rather than blocking (same pattern as zendesk/vectordb).

Available Tools

4 tools

fathom_get_latest_meetingA

Read-only fetch of the single most recent Fathom meeting (the 90% case for /updateP1). Returns the same summarized fields as fathom_list_recent_meetings, for exactly one meeting.

ParametersJSON Schema

Name	Required	Description	Default
`recorded_by`	No	Email of the recorder; narrows to meetings this user recorded.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and it explicitly states 'Read-only fetch', disclosing non-mutating behavior. It also references the output shape ('same summarized fields as fathom_list_recent_meetings'), which is useful transparency. It does not cover edge cases like no meetings existing, but the core safety profile is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that front-loads the action and scope, then adds relevant context. Every phrase earns its place, with no unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter, the description covers purpose, output shape by reference, and the limited scope. It lacks explicit mention of empty-result behavior, but this is a minor gap given the low complexity and full schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'recorded_by' already described in the schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read-only fetch of the single most recent Fathom meeting', identifying a specific verb ('fetch') and resource (most recent meeting). It also differentiates from siblings by referencing 'fathom_list_recent_meetings' and specifying 'exactly one meeting'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the primary use case ('the 90% case for /updateP1') and contrasts with the list tool ('same summarized fields ... for exactly one meeting'), implying when to use this versus the list alternative. It lacks explicit exclusions, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fathom_get_transcriptA

Read-only fetch of the RAW transcript for a Fathom recording by recording_id. Returns the raw transcript text/segments — the who/what/when summary is produced by the skill, not by this tool. Get the recording_id from fathom_list_recent_meetings or fathom_get_latest_meeting.

ParametersJSON Schema

Name	Required	Description	Default
`recording_id`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states that the fetch is 'read-only', it returns 'raw transcript text/segments', and it explicitly excludes summary generation. However, it does not mention error handling, rate limits, or authentication requirements, which would be useful but are not critical for a simple read-only fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the key action and output type, and every word serves a purpose. It is concise without losing necessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool, the description covers the purpose, input source, and output nature. It also references sibling tools for context. Minor gaps include lack of detail on the exact structure of the returned segments and error behavior, but these are not essential for a tool of this simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero description for recording_id, but the description adds meaning by identifying it as the ID for the recording and instructing the user to obtain it from sibling tools. This goes beyond the bare type information in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read-only fetch'), the resource ('RAW transcript'), and the scope ('by recording_id'). It also distinguishes itself from sibling tools by noting that the who/what/when summary is produced by the skill, not by this tool, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the user how to obtain the required recording_id from fathom_list_recent_meetings or fathom_get_latest_meeting, and clarifies that this tool does not produce summaries, implying it should be used when raw transcript is needed. This provides clear context on when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fathom_healthB

Read-only Fathom health/config check.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses 'read-only', which is a useful safety signal given the absence of annotations. However, it does not explain what the health/config check actually returns, how failures are surfaced, or any side effects (though read-only minimizes risk). Minimal context is added beyond the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence: 'Read-only Fathom health/config check.' Every word is informative, and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description is almost sufficient but leaves out return value expectations. The agent does not know whether the tool returns a simple status, metrics, or throws on unhealthy conditions. A sentence about output would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is empty. The description does not need to document parameters, and there is no coverage gap to compensate for. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'health/config check' for Fathom, using specific nouns that distinguish it from sibling tools focused on meetings. It lacks a strong verb like 'verify' or 'inspect', but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the meeting-related siblings. The context implies it is for system health verification, but no explicit when-to-use, prerequisites, or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fathom_list_recent_meetingsA

Read-only list of recent Fathom meetings (newest first). Returns title, recording_id, created_at, url, share_url, and calendar_invitees for each. The Fathom API has NO title/keyword search — to find a specific meeting (e.g. 'yesterday's call with McDonald's'), list recent meetings (optionally narrowing by created_after / recorded_by) and filter the returned list by title/date/invitee yourself.

ParametersJSON Schema

Name	Required	Description
`limit`	No
`recorded_by`	No	Email of the recorder; narrows to meetings this user recorded.
`meeting_type`	No
`created_after`	No	ISO date/datetime; only meetings created after this.
`created_before`	No	ISO date/datetime; only meetings created before this.
`invitee_domains`	No	Filter by calendar invitee email domains.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses read-only behavior, result ordering, returned fields, and a major limitation (no title/keyword search). It does not mention authentication or rate limits, but the core safety and behavioral traits are clearly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: a concise functional overview with return fields, and a practical usage note with a limitation and example. No wasted words; every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description provides the key return fields and ordering, which is useful. It also covers the main usage scenario and limitations. Gaps remain: meeting_type is ambiguous, pagination (limit max=50) is not discussed, and no response envelope details are given. Overall, it is sufficiently complete for a straightforward list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description adds context for two parameters (created_after, recorded_by) by explaining their role in narrowing. However, limit, meeting_type, created_before, and invitee_domains are not explained in the description beyond schema notes. The description compensates partially but not fully for the missing parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('list recent Fathom meetings') with a specific resource and ordering ('newest first'). It distinguishes from siblings by listing returned fields and noting the lack of search, setting it apart from get_latest_meeting and get_transcript.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: to find a specific meeting when no search exists, narrow by filters, and manually filter. It also provides a concrete example ('yesterday's call with McDonald's') and implies alternatives by noting the API has no search, directing the agent to use this tool instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 6, 2026
- First observedfathom_get_latest_meeting
- First observedfathom_get_transcript
- First observedfathom_health
- First observedfathom_list_recent_meetings

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-08-06 19:00 across 4 tools

Disambiguation4/5

The tools are mostly distinct: health, list, get_latest, and transcript each serve a clear purpose. Slight overlap exists between list_recent_meetings and get_latest_meeting, but the distinction (multiple vs. single) is clear from descriptions.

Naming Consistency4/5

All tools share the 'fathom_' prefix and most follow a verb_noun pattern (list_, get_). However, 'fathom_health' lacks an explicit verb, deviating slightly from the otherwise consistent convention.

Tool Count5/5

With 4 tools, the server is well-scoped for a focused read-only meeting adapter. Each tool covers a necessary operation without redundancy or bloat.

Completeness4/5

The surface covers health, listing, latest meeting, and transcript retrieval, which are the core read operations. A minor gap is the lack of a direct 'get meeting by recording_id' endpoint, though it can be worked around via list filtering.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

RiverScript A
com.riverscript
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
Audio Processing AI & Machine Learning
11
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2

Related MCP Servers

Fathom-Simple-MCP
Calendar Management Search Workplace & Productivity
druellan
A
license
A
quality
A
maintenance
A Model Context Protocol (MCP) server for accessing Fathom AI API endpoints (meetings, recordings, transcripts, summaries, teams, team members) via GET operations.
Updated a month ago (2026-07-28 15:09 UTC)
6
2
MIT
Fathom AI MCP
Communication Text Summarization
jerichosequitin
A
license
A
quality
C
maintenance
An MCP server for the Fathom AI meeting intelligence API
Updated 6 months ago (2026-03-21 10:18 UTC)
5
58
MIT
fathom-mcp-server
Communication Search Workplace & Productivity
luminarylane
A
license
A
quality
A
maintenance
Enables Claude Desktop and MCP clients to access Fathom meeting intelligence, including listing meetings, retrieving summaries and transcripts, and searching by title.
Updated 2 days ago (2026-09-07 17:35 UTC)
4
39
MIT
Fathom MCP Enhanced
Workplace & Productivity Communication
mamba-mental
A
license
Not graded
quality
D
maintenance
Provides comprehensive MCP tools for Fathom.video meetings, including transcripts, summaries, action items, team management, webhooks, and analytics.
Updated 8 months ago (2026-01-24 15:02 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/enrique-pastrana/fathom-mcp-adapter'

If you have feedback or need assistance with the MCP directory API, please join our Discord server