A FastMCP server that exposes the GroupMe API v3 to MCP clients.
Server has 7 tools with basic descriptions but critical gaps in schema visibility and parameter documentation. Tool names follow verb_noun convention (list_, read_, get_, search_, send_, react_to_). Descriptions are present but brief (10-50 chars for most). No input schemas visible in provided source code, cannot verify parameter types, constraints, or output structures. Error handling and recovery guidance absent. Security: credentials handled via environment (GROUPME_ACCESS_TOKEN), which is correct. Composition is reasonable (single responsibility per tool), but lack of schema documentation prevents confident assessment of chaining capability.
Orient yourself in one group with conversation context.
Catch up on a busy group with highlights (top-liked messages and member aggregates).
Lists groups and direct-message chats along with the group_id / other_user_id values every other tool takes.
Like or unlike a message (ids from read_messages' detailed format).
Read history with oldest first, next_before_id cursor. Accepts response_format="concise" (default, human-readable) or "detailed" (full ids and metadata).
Find specific messages in a conversation.
Write a new message to a conversation. Each call posts a new message.
No input schemas visible in source code. Cannot verify parameter types, constraints (enums, ranges), or descriptions.
Tool descriptions are too brief (10-65 chars). Rubric baseline: 194 chars average, p10=34, p90=392. Descriptions lack WHEN to use, prerequisites, and return value hints. E.g., 'read_messages' mentions cursor and format but not pagination limits or result structure.
No output schema documentation visible. LLMs cannot plan downstream calls or extract required fields (e.g., does list_conversations return group_id for use in read_messages?). Breaks tool chaining.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
No error handling or recovery guidance visible. Tools lack actionable error messages (e.g., 'Conversation not found. Call list_conversations() to see available IDs'). Agents cannot self-correct on failures.
send_message and react_to_message are write operations but lack confirmation/dry-run pattern. Agents can accidentally spam or react to wrong messages. No idempotency guarantees documented.