Loading ToolBench
This server demonstrates good foundation with clear tool names, comprehensive schemas using Zod validation, and consistent error handling patterns. All 5 tools follow verb_noun naming conventions (list_, get_) and include structured input schemas. However, descriptions are generic and lack LLM-optimized guidance on WHEN and WHY to call each tool. Output schemas are not documented, responses return raw API JSON wrapped in structuredContent without defining the field structure. Parameter descriptions exist but are minimal. Error handling returns API-level errors but lacks recovery guidance (e.g., 'try searching with a different filter'). The server uses HTTP transport with proper authentication via authInfo token injection, which is production-sound. No deprecated patterns detected.
Get meeting summary by recording ID
Get meeting transcript by recording ID with speaker information and timestamps
List meetings with optional filters including calendar invitees, date ranges, and content options
List team members for a specific team
List all teams in the organization
Output schemas not documented. Tools return structuredContent with raw API response JSON, but no description of response fields, types, or structure is provided to the LLM. This forces the LLM to guess at the shape of returned data, making downstream tool composition fragile.
Descriptions are too generic and lack LLM-optimized guidance. 'List meetings with optional filters...' and 'Get meeting summary by recording ID' are functional but don't explain WHEN to use them instead of similar tools, or what an LLM should expect in the response. Baseline descriptions are 194 chars; these are 60-100 chars with minimal context.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Error handling does not guide recovery. When a FathomApiError is caught, the response is '{"type": "text", "text": "Fathom API Error (status): message"}'. The LLM receives no guidance on what to do next: is this retryable? Should the user adjust filters? The error message alone provides no actionable path forward.
Parameter descriptions for fathom_list_meetings filters lack guidance on mutual exclusivity and field mapping. For example, 'calendar_invitees_domains_type' depends on 'calendar_invitees_domains' being set, but this dependency is not documented. Similarly, include_transcript/include_summary flags don't explain the performance or cost implications of requesting them.
No pagination guidance in list tool descriptions. fathom_list_meetings and fathom_list_teams accept 'cursor' parameters but the description doesn't explain the pagination protocol: does the response include next_cursor? Is there a total count? When should the LLM stop paginating? This forces the LLM to infer the API behavior.