Provides tools for interacting with Fathom.video API to manage meeting recordings, retrieve AI-generated summaries and transcripts, search meeting content, manage teams and webhooks, and access meeting analytics and participant insights.
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 MCP Server search my meetings for 'project roadmap' from last week"
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 enables LLMs to interact with the Fathom.video API for meeting recording management, transcripts, summaries, and analytics.
List and filter meetings - Access your Fathom meeting recordings with powerful filtering
Get transcripts and summaries - Retrieve AI-generated summaries and full transcripts
Team management - List teams and team members in your organization
Webhook management - Create and delete webhooks for real-time notifications
Search meetings - Full-text search across meeting content
Analytics - Get meeting statistics and participant insights
Related MCP server: Fathom MCP Server
# Clone or download the repository
git clone <repository-url>
cd fathom-mcp
# Install dependencies
npm install
# Build the project
npm run buildLog in to Fathom
Go to Settings > API
Generate or copy your API key
Add the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"fathom": {
"command": "node",
"args": ["/absolute/path/to/fathom-mcp/dist/index.js"],
"env": {
"FATHOM_API_KEY": "your-api-key-here"
}
}
}
}Alternatively, set the environment variable:
export FATHOM_API_KEY=your-api-key-hereTool | Description |
| List meetings with filtering by date, team, domain, recorder |
| Get AI-generated summary for a recording |
| Get full transcript with speaker identification |
| List all teams in your organization |
| List members of a specific team |
| Create a webhook for meeting notifications |
| Delete an existing webhook |
Tool | Description |
| Search across meeting titles, transcripts, and summaries |
| Get analytics: duration stats, team breakdown, meeting types |
| Get participant frequency and domain analysis |
"Show me my recent meetings""Get the summary for recording 123456789""Search my meetings for discussions about 'quarterly budget'""List all Sales team meetings from last month""Show me meeting statistics for this quarter""Create a webhook to https://my-app.com/webhook for my recordings"All tools support two response formats:
markdown (default): Human-readable formatted output
json: Structured data for programmatic processing
Specify the format using the response_format parameter.
The Fathom API has a rate limit of 60 requests per minute. The server handles rate limiting gracefully and will return an error message if the limit is exceeded.
# Install dependencies
npm install
# Development with auto-reload
npm run dev
# Build
npm run build
# Type checking
npm run typecheck
# Run the server
npm startfathom-mcp/
├── src/
│ ├── index.ts # Main entry point
│ ├── types.ts # TypeScript interfaces
│ ├── constants.ts # Configuration constants
│ ├── schemas/ # Zod validation schemas
│ ├── services/ # API client
│ └── tools/ # Tool implementations
├── dist/ # Compiled output
├── package.json
├── tsconfig.json
├── PRD.md # Project requirements
├── CHANGELOG.md # Version history
└── README.mdThe server provides clear, actionable error messages:
401: Authentication failed - check your API key
404: Resource not found - verify the recording ID
429: Rate limit exceeded - wait before retrying
Network errors: Connection issues with Fathom API
MIT
Create a webhook to receive real-time notifications when meetings are processed in Fathom.
This tool creates a webhook subscription that will POST meeting data to your specified URL whenever new meeting content becomes available.
Args:
destination_url (string, required): The URL to receive webhook notifications
triggered_for (string[], required): At least one trigger type:
'my_recordings': Your private recordings and those shared with individuals
'shared_external_recordings': Recordings shared with you by external users
'my_shared_with_team_recordings': Your recordings shared with teams
'shared_team_recordings': Team recordings accessible to you
include_action_items (boolean): Include action items in payload (default: false)
include_crm_matches (boolean): Include CRM matches in payload (default: false)
include_summary (boolean): Include meeting summary in payload (default: false)
include_transcript (boolean): Include transcript in payload (default: false)
Returns: The created webhook details including:
id: Webhook ID (use this for deletion)
url: Destination URL
secret: Webhook secret for signature verification
created_at: Creation timestamp
Examples:
Basic webhook: { destination_url: 'https://your-app.com/webhook', triggered_for: ['my_recordings'] }
With all content: { destination_url: 'https://your-app.com/webhook', triggered_for: ['my_recordings', 'shared_team_recordings'], include_transcript: true, include_summary: true, include_action_items: true }
Notes:
Webhooks use HMAC-SHA256 signatures for verification
The secret is only shown once upon creation - save it securely
Webhooks must return 2xx status to acknowledge receipt
| Name | Required | Description | Default |
|---|---|---|---|
| destination_url | Yes | The URL to receive webhook notifications | |
| triggered_for | Yes | Types of recordings that trigger the webhook: 'my_recordings', 'shared_external_recordings', 'my_shared_with_team_recordings', 'shared_team_recordings' | |
| include_action_items | No | Include action items in webhook payload | |
| include_crm_matches | No | Include CRM matches in webhook payload | |
| include_summary | No | Include meeting summary in webhook payload | |
| include_transcript | No | Include transcript in webhook payload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. While annotations indicate this is a non-destructive, non-idempotent write operation, the description adds crucial details: webhooks use HMAC-SHA256 signatures, the secret is only shown once upon creation, webhooks must return 2xx status to acknowledge receipt, and the tool returns specific webhook details. This provides valuable operational context not captured in annotations.
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 well-structured and efficiently organized. It starts with the core purpose, then provides parameter details, return values, examples, and important notes. Each section serves a clear purpose with no redundant information. The formatting with clear sections (Args, Returns, Examples, Notes) makes it easy to parse.
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?
For a creation tool with no output schema, the description provides excellent completeness. It explains what the tool does, all parameters, return values with their purpose, practical examples, and important operational notes about security and acknowledgment requirements. This gives the agent everything needed to correctly invoke and understand the tool's behavior.
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 baseline would be 3, but the description adds meaningful context beyond the schema. It explains what 'triggered_for' values represent in practical terms (types of recordings), provides examples of parameter usage, and clarifies that 'include_*' parameters control what content appears in the payload. This enhances understanding beyond the schema's technical definitions.
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 with specific verb ('create') and resource ('webhook'), and distinguishes it from siblings by specifying it's for receiving real-time notifications when meetings are processed. The first sentence explicitly states what the tool does: 'Create a webhook to receive real-time notifications when meetings are processed in Fathom.'
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 provides clear context for when to use this tool (to receive real-time notifications when meetings are processed) and mentions the sibling tool 'fathom_delete_webhook' indirectly through the return value note about using the ID for deletion. However, it doesn't explicitly state when NOT to use this tool or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing webhook from Fathom.
This tool removes a webhook subscription, stopping all future notifications to that endpoint.
Args:
id (string, required): The ID of the webhook to delete
Returns: Confirmation of successful deletion.
Examples:
Delete webhook: { id: 'ikEoQ4bVoq4JYUmc' }
Notes:
This action cannot be undone
The webhook will immediately stop receiving notifications
Any pending notifications may still be delivered
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the webhook to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it notes that the action 'cannot be undone', specifies immediate effects ('will immediately stop receiving notifications'), and mentions potential side effects ('Any pending notifications may still be delivered'). This complements annotations like destructiveHint=true and idempotentHint=true, providing practical insights without contradiction.
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 well-structured and front-loaded with the core action, followed by organized sections (Args, Returns, Examples, Notes). Each sentence adds value, such as clarifying irreversible consequences and notification behavior, with no wasted words or redundancy.
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's complexity (destructive action with one parameter), the description is complete: it covers purpose, usage, behavioral details, and examples. Although there is no output schema, the Returns section provides adequate information. The annotations and description together offer a comprehensive view without gaps.
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 input schema already fully documents the 'id' parameter. The description repeats this information in the Args section but adds no additional meaning or context beyond what the schema provides, meeting the baseline for high schema coverage.
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 specific action ('Delete') and resource ('an existing webhook from Fathom'), distinguishing it from sibling tools like fathom_create_webhook. It explicitly mentions what happens ('removes a webhook subscription, stopping all future notifications'), making the purpose unambiguous and distinct.
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 provides clear context for when to use this tool ('Delete an existing webhook'), but does not explicitly mention when not to use it or name alternatives. It implies usage by stating the action, though lacks explicit guidance on prerequisites or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the AI-generated summary for a specific Fathom recording.
This tool retrieves the summary that Fathom automatically generates for each meeting. The summary includes key discussion points, decisions made, and important topics covered.
Args:
recording_id (number, required): The ID of the recording to get the summary for
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: The meeting summary with template name and formatted content.
Examples:
Get summary: { recording_id: 123456789 }
Get as JSON: { recording_id: 123456789, response_format: 'json' }
Notes:
The recording_id can be found in the meeting list response
Summaries are always in English regardless of the meeting's original language
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | Yes | The recording ID to get the summary for | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies that summaries are 'always in English regardless of the meeting's original language' and describes what the summary includes ('key discussion points, decisions made, and important topics covered'), which helps the agent understand the tool's output characteristics.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by details on what the summary includes, parameter explanations, return information, examples, and notes. Every section adds value without redundancy, and the length is appropriate for the tool's complexity.
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's low complexity (2 parameters, 100% schema coverage), rich annotations (covering read-only, non-destructive, idempotent behavior), and no output schema, the description is complete. It explains what the tool does, what the summary contains, parameter usage with examples, and important behavioral notes (like English-only output), leaving no significant gaps for the agent.
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%, with both parameters well-documented in the schema. The description's Args section repeats this information but adds minimal extra meaning (e.g., 'The recording_id can be found in the meeting list response' provides sourcing context). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, with slight credit for the sourcing note.
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 specific action ('retrieves'), resource ('AI-generated summary for a specific Fathom recording'), and scope ('for each meeting'). It distinguishes from siblings like fathom_get_transcript (which gets raw transcripts) and fathom_list_meetings (which lists meetings rather than retrieving summaries).
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 provides clear context for when to use this tool ('to get the AI-generated summary for a meeting'), and the notes section offers practical guidance ('recording_id can be found in the meeting list response'). However, it doesn't explicitly state when NOT to use it or name alternatives (like using fathom_get_transcript for raw content instead of summaries).
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 Fathom recording.
This tool retrieves the complete timestamped transcript of a meeting, including speaker identification and timestamps for each segment.
Args:
recording_id (number, required): The ID of the recording to get the transcript for
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: Array of transcript entries, each containing:
speaker: Speaker name and optionally matched email
text: What was said
timestamp: When it was said (HH:MM:SS format)
Examples:
Get transcript: { recording_id: 123456789 }
Get as JSON: { recording_id: 123456789, response_format: 'json' }
Notes:
Transcripts can be large for long meetings
Speaker names are matched to calendar invitees when possible
Timestamps are relative to the recording start time
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | Yes | The recording ID to get the transcript for | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it notes transcripts can be large for long meetings, speaker names are matched to calendar invitees when possible, and timestamps are relative to recording start. Annotations already declare readOnlyHint=true, destructiveHint=false, etc., so the bar is lower, but the description provides useful operational details about data characteristics and matching behavior.
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 well-structured with clear sections (Args, Returns, Examples, Notes), front-loaded with the core purpose, and every sentence adds value. No wasted words or redundant information, making it efficient for an agent to parse and understand.
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's moderate complexity, rich annotations (readOnlyHint, openWorldHint, etc.), and 100% schema coverage, the description is complete. It explains what the tool returns (array structure with speaker, text, timestamp), provides examples, and adds operational notes about data size and matching behavior. No output schema exists, so the return value documentation is particularly valuable.
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 schema already fully documents both parameters. The description adds minimal value beyond the schema: it mentions the recording_id is required and response_format has a default, but these are already clear in the schema. The examples provide usage context but don't add semantic meaning beyond what's in the structured fields.
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 specific action ('Get the full transcript'), resource ('Fathom recording'), and scope ('complete timestamped transcript including speaker identification and timestamps'). It distinguishes from sibling tools like fathom_get_summary (which provides summaries) and fathom_list_meetings (which lists meetings rather than providing transcripts).
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 implies usage context by specifying it retrieves transcripts for recordings, but doesn't explicitly state when to use this versus alternatives like fathom_get_summary for summaries or fathom_search_meetings for finding meetings. It provides clear examples but lacks explicit 'when-not-to-use' guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List meetings from Fathom with optional filtering and pagination.
This tool retrieves meeting recordings from your Fathom account. You can filter by:
Company domains of calendar invitees
Internal vs external meetings
Date range (created_after/created_before)
Recorder email addresses
Team names
You can optionally include:
AI-generated summaries
Full transcripts
Action items
CRM matches (contacts, companies, deals)
Args:
calendar_invitees_domains (string[]): Filter by company domains
calendar_invitees_domains_type ('all'|'only_internal'|'one_or_more_external'): Filter by meeting type
created_after (string): ISO 8601 timestamp to filter meetings after
created_before (string): ISO 8601 timestamp to filter meetings before
cursor (string): Pagination cursor from previous response
include_action_items (boolean): Include action items (default: false)
include_crm_matches (boolean): Include CRM matches (default: false)
include_summary (boolean): Include summaries (default: false)
include_transcript (boolean): Include transcripts (default: false)
recorded_by (string[]): Filter by recorder emails
teams (string[]): Filter by team names
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: Paginated list of meetings with requested details.
Examples:
List recent meetings: {}
External meetings only: { calendar_invitees_domains_type: 'one_or_more_external' }
With summaries: { include_summary: true }
Filter by team: { teams: ['Sales'] }
| Name | Required | Description | Default |
|---|---|---|---|
| calendar_invitees_domains | No | Filter by company domains (e.g., ['acme.com', 'client.com']) | |
| calendar_invitees_domains_type | No | Filter by whether meeting includes external participants: 'all', 'only_internal', or 'one_or_more_external' | all |
| created_after | No | Filter meetings created after this ISO 8601 timestamp (e.g., '2024-01-01T00:00:00Z') | |
| created_before | No | Filter meetings created before this ISO 8601 timestamp | |
| cursor | No | Pagination cursor from previous response | |
| include_action_items | No | Include action items for each meeting | |
| include_crm_matches | No | Include CRM matches (contacts, companies, deals) for each meeting | |
| include_summary | No | Include AI-generated summary for each meeting | |
| include_transcript | No | Include full transcript for each meeting | |
| recorded_by | No | Filter by recorder email addresses | |
| teams | No | Filter by team names | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond this: it specifies this retrieves 'meeting recordings' (not just metadata), mentions pagination behavior, describes what optional content can be included (summaries, transcripts, etc.), and provides examples of common use cases. This goes well beyond what annotations provide.
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 well-structured and front-loaded: the first sentence states the core purpose, followed by logical groupings of functionality, then parameter explanations, return information, and practical examples. Every section earns its place by adding distinct value. The information density is high without being verbose.
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?
For a list/retrieve tool with comprehensive annotations (readOnly, openWorld, idempotent, non-destructive) and 100% schema coverage, this description provides excellent context. It explains what kind of data is retrieved, filtering capabilities, optional inclusions, pagination behavior, output format options, and includes practical examples. The lack of output schema is compensated by the clear 'Returns' statement and format parameter explanation.
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 baseline is 3. The description adds significant value by grouping parameters into logical categories ('You can filter by:' and 'You can optionally include:'), providing context about what each filter type does, and giving concrete examples in the Examples section. This helps the agent understand parameter relationships and typical usage patterns beyond the schema's individual parameter descriptions.
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 verb 'retrieves' and resource 'meeting recordings from your Fathom account', distinguishing it from siblings like fathom_search_meetings (which likely has different search capabilities) and fathom_get_summary/fathom_get_transcript (which focus on specific meeting details rather than listing). The opening sentence establishes the core functionality with optional filtering and pagination.
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 provides clear context about when to use this tool - for listing meetings with various filtering options. It doesn't explicitly state when NOT to use it or name specific alternatives, but the examples and parameter descriptions help guide usage. The distinction from siblings like fathom_search_meetings is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List members of a specific team or all teams in Fathom.
This tool retrieves team member information including names, emails, and when they joined.
Args:
team (string): Filter by team name (optional - shows all members if not specified)
cursor (string): Pagination cursor from previous response
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: Paginated list of team members with:
name: Member's display name
email: Member's email address
created_at: When the member was added
Examples:
List all members: {}
Filter by team: { team: 'Sales' }
Get as JSON: { response_format: 'json' }
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | Filter by team name | |
| cursor | No | Pagination cursor from previous response | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations by specifying the pagination behavior ('Paginated list'), describing the return data structure, and providing concrete examples. It doesn't contradict annotations and enhances understanding of the tool's behavior.
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 well-structured with clear sections (purpose, args, returns, examples). Every sentence earns its place by providing necessary information. It's appropriately sized for a tool with 3 parameters and no output schema, with no redundant or unnecessary content.
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?
For a read-only list tool with comprehensive annotations and 100% schema coverage, the description provides excellent completeness. It covers purpose, parameters, return format, pagination behavior, and includes practical examples. The lack of an output schema is compensated by the detailed return description in the text.
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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it restates the team parameter's purpose and provides examples, but doesn't add significant semantic context. The baseline of 3 is appropriate when the schema does most of the parameter documentation work.
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 verb ('List') and resource ('team members') with specific scope ('of a specific team or all teams in Fathom'). It distinguishes from sibling tools like fathom_list_teams (which lists teams, not team members) and fathom_list_meetings (which lists meetings). The description provides concrete details about what information is retrieved.
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 provides clear context about filtering options ('specific team or all teams') and includes examples showing different usage scenarios. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings (like when to use fathom_list_teams instead). The guidance is helpful but not exhaustive about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all teams accessible to the authenticated user in Fathom.
This tool retrieves the list of teams in your Fathom workspace. Teams are used to organize recordings and control access to meeting content.
Args:
cursor (string): Pagination cursor from previous response
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: Paginated list of teams with:
name: Team name
created_at: When the team was created
Examples:
List all teams: {}
Get as JSON: { response_format: 'json' }
Next page: { cursor: 'eyJwYWdlX251bSI6Mn0=' }
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor from previous response | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that results are paginated, shows the return structure with name and created_at fields, and provides concrete examples of usage patterns. No contradiction with annotations exists.
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 well-structured with clear sections (purpose, args, returns, examples) and front-loaded with the core functionality. However, the repetition of parameter details that are already in the schema adds minor redundancy, preventing a perfect score. Most sentences earn their place by providing examples or clarifying returns.
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's low complexity (2 optional parameters), rich annotations covering safety and behavior, and the description's inclusion of return structure and examples, this is complete enough for effective use. The lack of an output schema is compensated by the description detailing what the paginated list returns. No significant gaps remain for a list operation.
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%, with both parameters fully documented in the schema. The description repeats the same information about cursor and response_format without adding additional semantic meaning or usage nuances beyond what's in the schema. This meets the baseline of 3 when schema coverage is complete.
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 specific action ('List all teams'), resource ('teams accessible to the authenticated user in Fathom'), and scope ('in your Fathom workspace'). It distinguishes from siblings like fathom_list_team_members by focusing on teams rather than members, and from fathom_list_meetings by targeting teams instead of 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 provides clear context about when to use this tool ('to organize recordings and control access to meeting content'), but doesn't explicitly state when not to use it or name specific alternatives among siblings. The examples imply usage for pagination and format selection, but lack explicit comparison to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics and statistics about your Fathom meetings.
This tool calculates aggregate statistics about your meetings including duration metrics, team breakdowns, and internal vs external meeting ratios.
Args:
created_after (string): Filter to meetings after this ISO 8601 timestamp
created_before (string): Filter to meetings before this ISO 8601 timestamp
teams (string[]): Filter by team names
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns:
total_meetings: Number of meetings analyzed
duration_stats: Average, min, max, and total meeting duration in minutes
meetings_by_team: Count of meetings per team
internal_vs_external: Breakdown of internal vs external meetings
Examples:
All time stats: {}
This month: { created_after: '2024-11-01T00:00:00Z' }
Sales team: { teams: ['Sales'] }
Notes:
Duration is calculated from recording start to end time
Team breakdown based on recorder's team
External = one or more external participants
| Name | Required | Description | Default |
|---|---|---|---|
| created_after | No | Filter meetings created after this ISO 8601 timestamp | |
| created_before | No | Filter meetings created before this ISO 8601 timestamp | |
| teams | No | Filter by team names | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and behavior. The description adds valuable context beyond this: it explains how duration is calculated ('from recording start to end time'), team breakdown logic ('based on recorder's team'), and defines 'external' meetings ('one or more external participants'). This enhances understanding without contradicting annotations.
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 well-structured with clear sections (Args, Returns, Examples, Notes) and front-loaded purpose. It's appropriately sized for a tool with 4 parameters and no output schema, though some redundancy exists (e.g., parameter descriptions in both schema and description). Most sentences earn their place by providing examples or clarifying notes.
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's complexity (analytics with filtering), rich annotations (4 hints), and 100% schema coverage, the description is mostly complete. It explains key behavioral aspects (e.g., calculation methods) and provides examples. However, without an output schema, it could benefit from more detail on return value formats or limitations, but the Returns section partially compensates.
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%, with each parameter well-documented in the schema (e.g., 'Filter meetings created after this ISO 8601 timestamp'). The description repeats parameter names and adds minimal extra semantics (e.g., examples for 'created_after' and 'teams'), but doesn't significantly enhance meaning beyond what the schema provides. With high schema coverage, the baseline 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 analytics and statistics about your Fathom meetings' and specifies what it calculates ('aggregate statistics about your meetings including duration metrics, team breakdowns, and internal vs external meeting ratios'). It distinguishes from siblings like 'fathom_list_meetings' by focusing on analytics rather than listing. However, it doesn't explicitly differentiate from 'fathom_participant_stats' which might also provide statistical insights.
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 provides implied usage through examples (e.g., 'All time stats', 'This month', 'Sales team'), suggesting when to use this tool for aggregated analytics. However, it lacks explicit guidance on when to choose this over alternatives like 'fathom_list_meetings' for raw data or 'fathom_participant_stats' for participant-focused stats. No when-not-to-use scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics about meeting participants and recorders in Fathom.
This tool analyzes who attends your meetings most frequently and which domains are most common.
Args:
created_after (string): Filter to meetings after this ISO 8601 timestamp
created_before (string): Filter to meetings before this ISO 8601 timestamp
limit (number): Max top participants/recorders to return (1-100, default: 10)
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns:
top_participants: Most frequent meeting attendees
domain_breakdown: Meeting count by email domain
top_recorders: Users who record the most meetings
Examples:
All time stats: {}
Top 20: { limit: 20 }
This quarter: { created_after: '2024-10-01T00:00:00Z' }
| Name | Required | Description | Default |
|---|---|---|---|
| created_after | No | Filter meetings created after this ISO 8601 timestamp | |
| created_before | No | Filter meetings created before this ISO 8601 timestamp | |
| limit | No | Maximum number of top participants/recorders to return | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the analytics scope (participants and recorders), mentions filtering by time range, and describes the return structure (top_participants, domain_breakdown, top_recorders), which is helpful since there's no output schema. No contradiction with annotations.
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 well-structured with clear sections (purpose, Args, Returns, Examples) and efficiently conveys information. However, the Args section slightly repeats schema details without adding new insights, and the purpose statement could be more front-loaded. Overall, it's concise but has minor redundancy.
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's moderate complexity (analytics with filtering), rich annotations, and 100% schema coverage, the description is largely complete. It explains the return values (since no output schema exists) and provides usage examples. However, it lacks explicit guidance on sibling tool differentiation, which slightly reduces completeness for an agent.
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%, so the schema fully documents all parameters. The description adds minimal value beyond the schema: it repeats parameter names and basic purposes in the Args section but doesn't provide additional syntax, constraints, or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.
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 analytics about meeting participants and recorders in Fathom' and elaborates with 'analyzes who attends your meetings most frequently and which domains are most common.' It distinguishes from siblings like fathom_get_summary or fathom_meeting_stats by focusing specifically on participant statistics rather than meeting content or general metrics.
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 provides implied usage through examples (e.g., 'All time stats', 'This quarter'), but lacks explicit guidance on when to use this tool versus alternatives like fathom_meeting_stats or fathom_list_meetings. No clear exclusions or prerequisites are stated, leaving the agent to infer context from the analytics focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across Fathom meeting titles, transcripts, and summaries.
This tool performs a text search across your meeting content to find relevant discussions, mentions, or topics.
Args:
query (string, required): Search string (2-200 characters)
created_after (string): Filter to meetings after this ISO 8601 timestamp
created_before (string): Filter to meetings before this ISO 8601 timestamp
teams (string[]): Filter by team names
limit (number): Max results to return (1-50, default: 10)
response_format ('markdown'|'json'): Output format (default: 'markdown')
Returns: Matching meetings with:
Meeting details
Where matches were found (title, transcript, summary)
Context snippets showing the matched text
Examples:
Search for topic: { query: 'quarterly budget' }
With date filter: { query: 'product launch', created_after: '2024-01-01T00:00:00Z' }
Limit results: { query: 'feature request', limit: 5 }
Notes:
Search is case-insensitive
Searches across transcripts and summaries (fetched automatically)
Limited to most recent meetings for performance
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search string to find in meeting titles, transcripts, and summaries | |
| created_after | No | Filter meetings created after this ISO 8601 timestamp | |
| created_before | No | Filter meetings created before this ISO 8601 timestamp | |
| teams | No | Filter by team names | |
| limit | No | Maximum number of results to return (1-50) | |
| response_format | No | Output format: 'markdown' or 'json' | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it notes the search is case-insensitive, searches across transcripts and summaries (fetched automatically), and is limited to most recent meetings for performance. Annotations already declare readOnlyHint=true and idempotentHint=true, so the description appropriately supplements rather than contradicts them.
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 well-structured with clear sections (purpose, args, returns, examples, notes) and front-loads the core functionality. Some redundancy exists between the Args section and schema, but overall it's appropriately sized and organized for a search tool with multiple parameters.
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?
For a search tool with rich annotations (readOnlyHint, openWorldHint, idempotentHint) and comprehensive schema coverage, the description provides adequate context. It explains what gets searched, behavioral constraints, and includes helpful examples. The lack of output schema is partially compensated by the Returns section describing the response format.
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 schema already documents all parameters thoroughly. The description's 'Args' section mostly repeats schema information, though it adds minor clarification about default values. The examples provide helpful usage patterns but don't add significant semantic value beyond the schema.
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: 'Search across Fathom meeting titles, transcripts, and summaries' with the specific verb 'search' and resource 'meetings'. It distinguishes from siblings like 'fathom_list_meetings' by emphasizing text search functionality rather than simple listing.
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 provides clear context about when to use this tool ('to find relevant discussions, mentions, or topics') and mentions it searches across transcripts and summaries. However, it doesn't explicitly contrast with alternatives like 'fathom_list_meetings' or specify when NOT to use it.
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 distinct purpose with clear boundaries: webhook management (create/delete), meeting data retrieval (list, get summary/transcript, search), team management (list teams/members), and analytics (meeting/participant stats). There is no overlap or ambiguity between tools, making it easy for an agent to select the correct one.
All tool names follow a consistent 'fathom_' prefix with snake_case and a clear verb_noun pattern (e.g., fathom_create_webhook, fathom_list_meetings, fathom_get_summary). This uniformity enhances readability and predictability across the toolset.
With 10 tools, the server is well-scoped for managing Fathom meeting data, covering key operations like CRUD for webhooks, retrieval of meeting details, team management, analytics, and search. Each tool serves a unique and necessary function without bloat or gaps.
The toolset provides comprehensive coverage for the Fathom meeting domain, including full lifecycle management (create/delete webhooks), data access (list, get, search), team organization, and analytics. There are no obvious gaps; agents can perform all essential workflows without dead ends.
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
Give your AI assistant real meeting context via Fathom so every output grounded in your work
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lukas-bekr/fathom-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
