Loading ToolBench
MCP server for Granola.ai meetings API with OAuth proxy. Provides structured access to Granola meeting data via Model Context Protocol, with OAuth 2.0 authentication and PostgreSQL-backed session management.
The server exposes 4 tools with basic schemas and descriptions, but falls short of production quality standards. Tool naming is descriptive and follows verb patterns (get_*, search_), which is good. However, descriptions are generic and lack actionable context about when to use each tool vs. alternatives. Parameter descriptions exist but are minimal (5-15 chars). Output schemas are not documented, critical for agents to plan downstream operations. No error handling guidance is visible. The tools are READ_ONLY, which is safe, but the definitions themselves do not follow LLM-optimized patterns from the 54 Agentic Tool Patterns. Schemas are present and use correct JSON Schema structure, but descriptions do not explain WHEN to call each tool or WHAT data they return, only a bare 1-sentence statement of what the API does.
Get summary for a single meeting document
Get recent meetings from the last N days with summaries
Get all meetings from today with summaries
Search meetings by keyword with summaries
Output schemas not documented. LLMs cannot infer what fields are returned by each tool, forcing them to guess at response structure and blocking chaining between tools. E.g., get_todays_meetings returns meetings but what fields do they have? Is there a meeting_id for use with get_document_summary?
Parameter descriptions lack actionable context. E.g., 'days' parameter in get_recent_meetings has description 'Number of days to look back (default 7)' but does not explain what it returns differently from get_todays_meetings. LLMs cannot distinguish when to use get_recent_meetings vs get_todays_meetings.
Tool descriptions are under 50 characters and lack WHEN/WHY context. 'Get all meetings from today with summaries' states WHAT but not WHEN to call it (vs search_meetings). Descriptions should answer: What does it do? When should the LLM use it instead of a similar tool? What data structure is returned?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
No pagination documented for list-returning tools. get_recent_meetings and search_meetings could return many results. Are results limited? Is there a next_cursor or offset? Without pagination guidance, large result sets may blow token budget.
No error handling or recovery guidance. If search_meetings returns no results, should the LLM try a broader query? If get_document_summary fails with an invalid document_id, how should the agent respond? Error descriptions must guide recovery.
Parameter 'limit' in get_recent_meetings and search_meetings lacks range constraints. Description says 'default 20' but does not specify min/max. What happens if limit=999999? Unbounded numbers invite LLM errors or API overload.