Provides access to Fathom meeting recordings, AI-generated summaries, and transcripts. Enables listing meetings with filtering by date, recorder, or team, and retrieving full transcripts with speaker attribution and timestamps.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fathom Video MCP Server list my meetings from yesterday"
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.
An MCP (Model Context Protocol) server that provides access to your Fathom meeting recordings, AI-generated summaries, and transcripts.
List Meetings - Browse your Fathom meetings with filtering by date, recorder, or team
Get Summaries - Retrieve AI-generated meeting summaries in markdown format
Get Transcripts - Access full transcripts with speaker attribution and timestamps
Related MCP server: Fathom MCP Server
git clone https://github.com/trevorwelch/fathom-video-mcp.git
cd fathom-video-mcp
uv syncLogin to your Fathom account, go to fathom.video/api_settings/new
Select Generate Api Key
Copy your new API key and save it somewhere secure
Choose one of the following based on which Claude app you use.
Edit ~/.claude/settings.json:
{
"mcpServers": {
"fathom": {
"command": "uv",
"args": ["run", "--directory", "/path/to/fathom-video-mcp", "fathom-video-mcp"],
"env": {
"FATHOM_API_KEY": "your-api-key-here"
}
}
}
}Replace /path/to/fathom-video-mcp with the actual path where you cloned the repo.
Edit your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"fathom": {
"command": "uv",
"args": ["run", "--directory", "/path/to/fathom-video-mcp", "fathom-video-mcp"],
"env": {
"FATHOM_API_KEY": "your-api-key-here"
}
}
}
}Replace /path/to/fathom-video-mcp with the actual path where you cloned the repo.
Restart Claude Code or Claude Desktop to load the new MCP server. You should now be able to ask Claude about your Fathom meetings.
List your Fathom meetings with optional filters.
Parameters:
limit (int, optional): Maximum number of meetings to return (1-50)
search (string, optional): Smart search - matches titles, attendee names, and email domains
cursor (string, optional): Pagination cursor from previous response
created_after (string, optional): ISO timestamp to filter meetings after
created_before (string, optional): ISO timestamp to filter meetings before
include_summary (bool, optional): Include AI summary in response
include_transcript (bool, optional): Include transcript in response
include_action_items (bool, optional): Include action items in response
recorded_by (list[string], optional): Filter by recorder email addresses
teams (list[string], optional): Filter by team names
calendar_invitees_domains_type (string, optional): Filter by invitee type ('all', 'only_internal', 'one_or_more_external')
invitee_domains (list[string], optional): Filter by invitee email domains (e.g., ['acme.com'])
Example:
List my meetings from the last weekGet the AI-generated summary for a specific meeting.
Parameters:
recording_id (int, required): The recording ID from list_meetings
Example:
Get the summary for meeting 123456789Get the full transcript with speaker attribution.
Parameters:
recording_id (int, required): The recording ID from list_meetings
Example:
Get the transcript for meeting 123456789cd fathom-video-mcp
uv sync
export FATHOM_API_KEY="your-api-key"
uv run python -m fathom_video_mcp.serverGet the AI-generated summary for a specific meeting recording.
Returns a markdown-formatted summary of the meeting including key points and discussion topics.
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | Yes | The recording ID of the meeting (from list_meetings) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool returns a markdown summary, but does not disclose potential latency, idempotency, or prerequisites like the meeting must be processed. The behavior is partially transparent but lacks details about side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states the core function, second sentence explains the output. No unnecessary words. Front-loaded with the essential verb+resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, output schema exists), the description is largely sufficient. It covers purpose, output format, and parameter source. However, it omits error handling or prerequisites for generating the summary, which could help completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter described as 'The recording ID of the meeting (from list_meetings)'). The tool description adds no extra parameter details beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the AI-generated summary for a specific meeting recording.' It specifies the resource (summary) and indicates the output format (markdown) and content (key points, discussion topics). This distinguishes it from siblings like get_transcript and list_meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies that the recording_id should come from list_meetings (from the parameter description), but there is no guidance on when not to use it or what conditions must be met (e.g., meeting must have summary generated).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full transcript for a specific meeting recording.
Returns timestamped transcript segments with speaker attribution. Each segment includes the speaker name, what they said, and when.
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | Yes | The recording ID of the meeting (from list_meetings) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses that this is a read operation returning transcript segments with timing and speaker info. It does not mention any side effects, which is fine for a retrieval tool. Could add more about error conditions or authorization needs, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core purpose, second describes the return format. No wasted words, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description sufficiently covers the return format. It lacks a note about prerequisites (e.g., need a valid recording_id from list_meetings), but the param description hints at that. Overall, adequate for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a clear description for recording_id. The tool description does not add extra semantic detail about the parameter; it only restates the purpose. Since schema already covers it, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the full transcript for a specific meeting recording, with specifics like timestamped segments and speaker attribution. This verb-resource combination distinguishes it from siblings: list_meetings lists meetings, get_summary gets a summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_summary or list_meetings. The description does not provide context for appropriate usage scenarios or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Fathom meetings with optional filtering.
Returns a paginated list of meetings. Use the recording_id from the results to fetch summaries or transcripts with get_summary or get_transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of meetings to return (1-50) | |
| search | No | Smart search: matches titles, attendee names, and email domains (e.g., 'Acme' finds acme.com) | |
| cursor | No | Pagination cursor from previous response | |
| created_after | No | Filter meetings created after this ISO timestamp (e.g., 2025-01-01T00:00:00Z) | |
| created_before | No | Filter meetings created before this ISO timestamp (e.g., 2025-12-31T23:59:59Z) | |
| include_summary | No | Include AI-generated summary in the response | |
| include_transcript | No | Include full transcript in the response | |
| include_action_items | No | Include action items in the response | |
| recorded_by | No | Filter by email addresses of users who recorded the meetings | |
| teams | No | Filter by team names | |
| calendar_invitees_domains_type | No | Filter by invitee type: 'all', 'only_internal', or 'one_or_more_external' | |
| invitee_domains | No | Filter by invitee email domains (e.g., ['acme.com', 'example.com']) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions pagination ('Returns a paginated list') and optional filtering, which discloses key behavior. It does not contradict any implicit safety assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then providing actionable guidance. Every sentence serves a clear function with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters all documented in the schema and an output schema exists, the description covers the essential behavior (pagination, filtering, follow-up actions) without needing to duplicate schema details. It is complete for a listing endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter descriptions in the schema are already detailed. The tool description adds no new semantic meaning beyond stating 'optional filtering' and mentioning pagination, which is already implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Fathom meetings with optional filtering,' which is a specific verb and resource. It also distinguishes from sibling tools by mentioning how to use recording_id with get_summary or get_transcript.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use get_summary or get_transcript after listing meetings, providing clear context. It does not include exclusions or alternative use cases, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: listing meetings, retrieving summaries, and fetching transcripts. No overlap or ambiguity exists.
All tool names follow a consistent verb_noun pattern using snake_case (list_meetings, get_summary, get_transcript), making them predictable and easy to understand.
With 3 tools, the server is well-scoped for its purpose of accessing meeting recordings. Each tool is necessary and there are no superfluous tools.
The tool set covers the core workflow: listing meetings, then retrieving either the summary or transcript. No obvious gaps exist for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Search meetings, export summaries and transcripts, and manage recordings from any AI tool.
Search recordings, summarize meetings, create clips, and automate workflows from your AI assistant.
Give your AI assistant real meeting context via Fathom so every output grounded in your work
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/trevorwelch/fathom-video-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
