AI-powered daily summary and newsletter generation platform with FastAPI backend and React frontend
This HTTP-based FastAPI MCP server exposes 8 read-only tools for a news aggregation platform. All tools have descriptions and input schemas are visible in the code. However, the schemas lack depth, most parameters are missing detailed constraints, enums, and type specifications beyond basic types. Descriptions are present but generic (avg ~80 chars), falling short of the LLM-optimized 50-200 char range. Parameter descriptions exist but are minimal ('Search query', 'Filter by topic'). Output schemas are not documented anywhere in the source. Error handling and recovery guidance are absent. The server is composition-sound (each tool has one responsibility) but lacks polish expected of production-grade agent toolkits.
Get a single article by ID.
Get a single source by ID.
Get daily summary for a specific date.
Health check endpoint.
List articles with optional filters.
List all sources.
List daily summaries.
Output schemas not documented. LLMs cannot plan downstream operations or extract required fields when response structures are undocumented.
Parameter descriptions are minimal and lack actionable context. E.g., 'Search query' does not explain what fields are searched, whether it supports operators, or expected format.
Input schemas lack enums for constrained parameters. 'source_type' and 'exclude_source_type' accept free-form strings instead of an enumerated set (rss|newsletter|github|crawler). LLMs will hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Semantic search: embed the query and rank by pgvector cosine distance. Falls back to keyword ILIKE search if embedding fails (e.g. LLM API down).
No error handling or recovery guidance. Tools provide no error examples or guidance on how an LLM should respond to failures (e.g., 'Date not found' or 'Semantic search failed, retrying with keyword search').
Tool descriptions are too brief (avg 60-70 chars). LLM-optimized descriptions should be 50-200 chars and include WHAT the tool does, WHEN to use it, and what it returns. Current descriptions lack context for proper tool selection.
No chaining IDs in responses documented. If list_articles returns articles, the response structure is not specified, does it include article_id for get_article? Does it include date for get_summary chaining?
health tool is operational but conventionally not exposed as an agent tool. Health checks are infrastructure concerns, not agent-facing capabilities. Remove or mark as internal.