Loading ToolBench
MCP server for accessing Fathom AI meeting recordings, transcripts, summaries, teams, and team members.
The server provides 6 well-named tools with clear action verbs (search, list, get). All tools have descriptions present and reasonable length (120 - 250 chars). However, schema quality is mixed: while input parameters are declared with types, many lack detailed constraints, format specifications, or enum declarations. Output schemas are not explicitly documented in the visible code. Parameter descriptions are generic ('Filter by X', 'Pagination cursor') without actionable constraints. Error handling is not visible in the provided code sample. The server uses tool annotations (readOnlyHint) correctly, which is a positive signal. Overall, this is solid mid-tier work, functional and usable, but lacking the polish expected for A-grade production tools.
Retrieve comprehensive meeting details including summary and metadata (without transcript).
Retrieve meeting transcript with essential metadata (id, title, participants, dates).
Retrieve paginated meetings with filtering and optional content inclusion (action items, CRM matches).
Retrieve paginated team members with optional team filtering.
Retrieve paginated list of teams with organizational structure.
Search meetings by keyword across metadata fields and optionally transcripts. This tool searches meeting metadata (titles, attendees, teams, topics, summaries) and optionally full transcript content. Uses fuzzy matching to handle partial matches, plurals, and case-insensitive search. By default, transcripts are NOT searched or included to optimize performance. Set include_transcript=True to search within and return transcript data. Fetches all meetings (with pagination) and returns those matching the search query.
Output schemas not documented. No visible return type specifications for any tool. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Parameter descriptions are generic and lack actionable constraints. E.g., 'Filter by invitee emails' does not specify format (single email vs comma-separated vs array), how partial matches are handled, or case sensitivity. 'Number of results per page (default: 50)' lacks min/max bounds.
Pagination is supported but not fully documented. 'cursor' parameter exists but no guidance on initial value, whether 'null' means no more pages, or how to detect end-of-results. Code shows default per_page=50 but no min/max or validation shown.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
No visible error handling or recovery guidance in the tool definitions. If search_meetings fails (no results, invalid query, quota exceeded), the tool description does not guide what the LLM should do next.
list_meetings has 10 optional parameters with weak descriptions. Mutually exclusive or dependent parameters (e.g., calendar_invitees vs recorded_by, created_after vs created_before) lack dependency documentation.
search_meetings does not document result ordering, scoring, or how many results are returned by default. LLMs need to know if top-k results are returned or if pagination is required.