Syncs Sana.AI meeting transcripts to this machine and serves them to AI agents over MCP, to a person through an interactive application, and to scripts through a CLI.
This server has critical structural issues. The primary tool 'meeting_transcripts' is a dispatcher that accepts arbitrary sub-tool names as string parameters, making it impossible for LLMs to understand what operations are available without calling help first. Input schemas are present but poorly designed: the dispatcher uses a generic {tool, args} pattern rather than individual tool definitions. Most sub-tools (help, status, list, read, search, summary, participants, recording, login, correct) are not explicitly registered as separate MCP tools, they exist only as handler functions dispatched by the wrapper. This violates the single-responsibility principle and prevents LLMs from discovering and reasoning about individual operations. Descriptions are present but generic (e.g., 'Dispatches calls to various meeting transcript handlers'). Parameter descriptions exist but lack detail on constraints, formats, and valid values. No output schemas are documented. Error handling returns text strings without recovery guidance.
Corrects a line in a transcript and stores the correction
Shows help text for a specific tool or all available tools
Lists meetings with optional pagination, filtering by status/date, searching, and sorting
Initiates or completes the email-code sign-in flow for Sana.AI
Dispatches calls to various meeting transcript handlers based on the tool argument
Returns meeting participants and speakers with attendance information
Reads a meeting transcript with options for full text, line ranges, and timestamp display
Fetches the recording link for a meeting (link expires after a few hours)
Dispatcher anti-pattern: 'meeting_transcripts' is a single tool that accepts arbitrary sub-tool names as string parameters. LLMs cannot discover available operations without calling help first. This violates the single-responsibility principle and prevents proper tool selection reasoning.
Sub-tools (help, status, list, read, search, summary, participants, recording, login, correct) are not registered as individual MCP tools. They exist only as handler functions inside the dispatcher. This prevents LLMs from discovering them via tool listing and forces all calls through the wrapper.
No output schemas documented. Tools return text strings without structured field definitions. LLMs cannot plan downstream operations or extract specific data fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
Searches transcripts using BM25 keyword search with pagination and sorting
Returns the current sync status including phase, meetings total/downloaded, transcripts total/done, and remaining items
Returns the AI-generated summary for a meeting
Parameter constraints missing. 'list' accepts 'sort' and 'filter' as free-form strings/objects without enums or format specifications. 'read' accepts 'lines' as an array without documented structure. LLMs cannot validate inputs.
Error handling returns plain text without recovery guidance. No categorization of errors as retryable, user-fixable, or fatal. LLMs receive no actionable next steps on failure.