Loading ToolBench
MCP server for querying a local Fathom knowledge base of meetings, participants, and companies with full-text and semantic search capabilities
Strong foundation with 10 well-named, verb-prefixed tools and comprehensive parameter schemas using Zod. All tools have descriptions (avg 150 chars) and input schemas with types. Key strengths: clear filtering semantics (AND/OR composition), enumerated valid values for relationships/call_types/company_relationships, and thoughtful parameter descriptions. Weaknesses: output schemas are not formally documented (only visible in code via JSON.stringify), no error recovery guidance in descriptions, missing tool annotations (readOnlyHint, idempotentHint), and no pagination guidance despite list_meetings returning up to 200 results. Composition is clean, each tool has one responsibility. Parameter naming is consistent (person, company, date_from/date_to). Descriptions are actionable but could be more explicit about when to use semantic_search vs keyword_search.
Find companies (by email domain) with meeting and contact counts.
Find people who've participated in meetings by name or email substring. Returns meeting counts and date range.
Get a chronological timeline of meetings for a person or company, with summaries and tags.
Get full details for a specific meeting: participants, companies, duration, and summary.
Get the status of a project or initiative by querying meetings tagged with a specific call_type or involving specific people/companies.
Get raw transcript chunks for a specific meeting, optionally filtered by speaker or timestamp range.
Full-text SQLite FTS5 search over meeting titles and summaries. Use for precise terms, company names, acronyms. For conceptual queries prefer semantic_search.
Output schemas not formally documented. Tool descriptions state what is returned (JSON) but do not specify field types, required fields, or structure. LLMs cannot reliably plan downstream calls or extract nested data without explicit schema documentation.
No tool annotations (readOnlyHint, idempotentHint). All 10 tools are read-only and idempotent, but this is not declared in the tool registration. Agents cannot infer safety properties and may apply unnecessary caution or retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List meetings from the local Fathom knowledge base with optional filters. Returns the most recent first. Filters compose as AND across params; within the relationships or call_types arrays the semantics are OR.
Vector search across transcript chunks and summaries. Best for conceptual questions ('objections about pricing', 'how we talk about onboarding'). Optional filters scope results to a person, company, date range, or taxonomy tags.
Verify a claim or statement against meeting transcripts and summaries. Returns relevant meeting excerpts and context.
Ambiguous tool selection guidance. semantic_search and keyword_search both accept a 'query' parameter and return meetings. Descriptions hint at the distinction ('FTS5 query' vs 'natural language') but do not explicitly state when to prefer one over the other. LLMs may waste reasoning cycles or pick the wrong tool.
No error recovery guidance. Tool descriptions do not explain what to do if a meeting is not found, a query returns no results, or a timestamp format is invalid. Error responses in code return isError=true with plain text, but descriptions do not prepare the LLM for these cases.
Pagination not addressed in descriptions. list_meetings accepts limit up to 200 and returns all matching results. No mention of pagination, next_cursor, or total_count. If a query matches 500 meetings, the LLM receives all 500, bloating context and risking token exhaustion.