Loading ToolBench
MCP server for Granola.ai meeting intelligence
Granola MCP Server demonstrates partial alignment with agentic tool patterns. All 5 tools are explicitly registered with names, descriptions, and input schemas in granola_mcp_server/server.py. Naming follows verb_noun convention (search_meetings, get_meeting_details, etc.), which is strong. However, descriptions are terse (10-65 characters), well below the baseline average of 194 chars, offering minimal context for LLM tool selection. Parameter descriptions exist but are minimal. Input schemas are properly typed with required fields declared. Output schemas are not documented in the provided code. Error handling, recovery guidance, and idempotency patterns are not visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only operations.
Analyze patterns across multiple meetings
Get detailed information about a specific meeting
Get documents associated with a meeting
Get transcript for a specific meeting
Search meetings by title, content, or participants
Tool descriptions are extremely terse (10-65 characters, baseline 194). 'Search meetings by title, content, or participants' lacks context on WHEN to use it vs. other tools, what fields are searched, result ordering, or what happens on no matches. Below the 10-1024 character guidance and insufficient for LLM tool selection.
Output schemas are not documented. LLMs cannot infer what fields to expect from search_meetings, get_meeting_details, or analyze_meeting_patterns responses. This forces agents to guess field names and breaks composition with downstream tools. Missing output schema blocks result extraction and chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite all 5 tools being pure read-only operations. Adding readOnlyHint=true to all tools signals safety to agents and enables them to retry without side-effect risk. Current spec (2026-07-28) encourages these annotations.
Parameter descriptions are minimal or absent in schema (e.g., 'query' described as 'Search query for meetings' but no detail on searchable fields, exact vs. substring matching, or case sensitivity). Pattern_type enum provides values but no explanation of what 'topics', 'participants', 'frequency' analyze or how results differ. LLMs cannot infer parameter semantics from names alone.
No error handling guidance visible. No indication of retryable vs. fatal errors, no recovery steps (e.g., 'If meeting not found, try search_meetings()'), no actionable error messages. Agents have no way to know if a failure is permanent or transient.
search_meetings lacks pagination parameters (limit is present but no offset, cursor, or page). If Granola returns thousands of meetings, the entire set will be forced into the response, blooming context and risking agent reasoning degradation. Baseline pattern expects pagination support with result limits.
No documentation of what fields are returned by search_meetings or get_meeting_details. If search_meetings returns a meeting_id, agents can call get_meeting_details, but without documented output fields, composition is opaque. Result-chaining IDs (meeting_id, participant IDs, document_ids) must be explicitly listed in output descriptions.