An MCP server for customer support operations including FAQ generation, support response writing, knowledge base creation, and support ticket analysis.
Server has 4 tools with complete Zod schemas and descriptions. Naming follows verb_noun convention (generate_faq, write_support_response, create_knowledge_base, analyze_support_tickets). All tools have descriptions (100-200 chars, within baseline). However, many parameter descriptions are missing or trivial: product_name lacks description in generate_faq and create_knowledge_base; category enum in generate_faq has null description; issue_type enum in write_support_response has null description. Output schemas are undocumented, responses return generic {content: [{type: 'text', text}]} with no field-level documentation. Error handling is absent: no validation of Groq API failures, no guidance for LLM timeouts, no recovery paths. Tools are read-only (no state mutation) but lack explicit idempotent hints. Parameter relationships (e.g., resolution/cannot_do in write_support_response) are undocumented.
Analyze a batch of support tickets or customer feedback to identify top issues, patterns, and product improvements.
Create a structured knowledge base outline with article titles, descriptions, and content for key support topics.
Generate a comprehensive FAQ page for a product or service. Covers the questions customers actually ask.
Write a professional, empathetic customer support response to any customer issue or complaint.
Enum parameters lack descriptions: category in generate_faq, issue_type in write_support_response, goal in analyze_support_tickets have null or missing descriptions. LLMs cannot infer when to use each enum value.
Required parameters lack descriptions: product_name in generate_faq and create_knowledge_base have null descriptions. LLMs cannot determine what content to pass.
Output schema is undocumented. All tools return {content: [{type: 'text', text}]} but no schema is published. LLMs cannot plan downstream operations or extract structured data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
No error handling or recovery guidance. Groq API failures (rate limits, auth errors, timeouts) are unhandled. LLMs receive raw exceptions with no actionable next steps.
No tool annotations (readOnlyHint, idempotentHint). Tools are read-only and idempotent but do not declare this via MCP annotations, forcing LLMs to infer safety.