MCP server for Granola.ai meeting intelligence
Server has 5 tools with complete input schemas and reasonable descriptions. All tools follow verb_noun naming convention (search_, get_, analyze_) and are read-only, which reduces risk. However, descriptions are generic and lack LLM-optimized detail about when to use each tool vs. alternatives. Parameter descriptions are minimal, most lack guidance on format, constraints, or dependencies. Output schemas are undocumented. Error handling is not evident in the tool definitions. The code shows proper use of mcp-sdk, Pydantic models, and timezone handling, but these implementation details don't compensate for weak schema documentation.
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
Output schemas not documented. Tools return results but the response structure, field names, types, and available fields are not declared. LLMs cannot plan downstream calls or extract data reliably without knowing what fields to expect.
Parameter descriptions lack actionable guidance. The 'query' parameter in search_meetings says 'Search query for meetings' but does not explain what fields are searched (title, content, participants, all?), format requirements, length limits, or special syntax. The 'pattern_type' enum in analyze_meeting_patterns lists values but does not explain what each type returns or when to use each.
Tool descriptions lack context for LLM selection. When would an agent call get_meeting_details vs. get_meeting_transcript vs. get_meeting_documents? All return data about a meeting but the descriptions don't differentiate their purposes or explain the agent's decision logic. This forces the LLM to guess or try all three.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Missing pagination parameters. The search_meetings tool accepts a 'limit' but no offset/page/cursor. Large result sets will blow the context window. No indication whether results are capped, whether pagination is needed, or how to retrieve additional results.
analyze_meeting_patterns has undocumented parameter dependencies. The 'date_range' parameter is optional but its fields (start_date, end_date) use date format. No guidance on whether both are required when provided, what happens if only one is set, or what the default date range is when omitted.
No error guidance. Tools make external API calls to Granola API but there is no error recovery guidance in the tool descriptions. What should the LLM do if a meeting_id is invalid? If the API times out? If the user lacks permission to view a meeting?
search_meetings limit default is 10 but no maximum is documented. Can an LLM pass limit=10000? This could exhaust the context window or cause API rate limits. The description should specify the valid range (e.g., '1 - 100, default 10').