Loading ToolBench
MCP server connecting Claude to Fathom AI meeting recordings, transcripts, and summaries
The Fathom MCP server demonstrates solid definition quality with consistent naming conventions, proper schema structures, and comprehensive descriptions. All 6 tools follow verb_noun patterns (list_*, search_*, get_*). Every tool has an explicit description and input schema with proper type definitions. Tool annotations (readOnlyHint) are correctly applied. However, there are meaningful gaps: output schemas are not documented in the definition layer, parameter descriptions vary in specificity (some lack actionable constraints), and error handling guidance is not evident in the tool definitions. The server implements valid patterns but falls short of A-grade polish.
Get the AI-generated summary for a meeting recording
Get the full transcript for a specific meeting recording
List Fathom meetings with optional filters: cursor (pagination; pass the next_cursor from the previous response to get the next page), created_after, created_before (ISO timestamps), calendar_invitees_domains (company domains), calendar_invitees_domains_type (all/only_internal/one_or_more_external), teams (team names), recorded_by (recorder emails), include_action_items (boolean), include_crm_matches (boolean). Response includes next_cursor: when non-null, call again with cursor set to that value to fetch more meetings.
List members of a Fathom team. Optional: team to filter by team name, cursor for pagination.
List all Fathom teams you have access to. Optional: cursor for pagination.
Output schemas are not documented. Tool definitions describe inputs but omit what callers should expect in responses, fields, types, structure. LLMs cannot plan downstream calls without knowing what they'll receive.
Timestamp parameters (created_after, created_before) lack explicit format constraints in schema. Descriptions mention 'ISO timestamps' but schema does not enforce format: 'date-time'. LLMs may pass malformed dates.
get_transcript and get_summary descriptions are minimal (60 chars each), below the 10 - 1024 optimal range. No guidance on use cases, output format, or distinguishing factors between the two tools. LLMs may pick the wrong one.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | B | 70 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 69 | - | v1 |
Search Fathom meetings by title, meeting title, host name, host email, or attendee name/email. Automatically scans up to 5 pages of results. Required: query (search term). Optional filters: cursor (pass next_cursor from a previous response to continue searching from that point), created_after, created_before (ISO timestamps), calendar_invitees_domains, calendar_invitees_domains_type, teams, recorded_by, include_action_items (boolean), include_crm_matches (boolean). Response includes next_cursor (non-null means more pages exist) and total_searched (meetings scanned).
No error handling guidance in tool definitions. If a recording_id or team name is not found, the definition does not document what callers should do next (retry with different ID, call list_meetings first, etc.). LLMs lack recovery paths.
Pagination cursors are used but next_cursor field structure is not documented in output schema. Descriptions mention 'pass next_cursor from previous response' but definition does not show response format (is it a string? object? what other fields?). Limits LLM ability to chain calls correctly.
list_team_members accepts 'team' parameter but does not clarify if it expects team name or team ID. No guidance on what happens if the name does not match exactly or if it is not found. Forces LLM to guess or try multiple calls.