An MCP server implementation in Go that exposes tools, resources, and prompts to AI clients through the Model Context Protocol
Server has 2 tools with basic schemas and descriptions. list_posts has a well-defined enum constraint on 'status' and proper parameter types (string, integer), meeting baseline schema requirements. list_sections lacks parameters entirely. Both descriptions are present but brief (under 100 chars), providing minimal context for LLM selection. No output schemas documented. Error handling is present in server.go (validation, authorization checks, helpful error messages listing available tools), but tool-level recovery guidance is absent. Security model is sound (subject-based authorization enforced at Call boundary), but no tool annotations (readOnlyHint, destructiveHint) despite both being READ_ONLY. Composition is clean: two single-responsibility tools with clear names starting with action verbs.
List posts with optional filtering by status and limit
List sections from the blog
list_sections has no input parameters defined; schema is empty object. Cannot validate or guide LLM on how to filter or paginate results.
No output schemas documented for either tool. LLMs cannot infer what fields to expect (e.g., does list_posts return post_id, title, status, created_at?) or plan downstream tool calls.
Tool descriptions are under 100 characters and lack context. 'List posts with optional filtering by status and limit' does not explain WHEN to use this tool vs alternatives, what the response structure is, or whether results are paginated.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite both tools being READ_ONLY. Annotations help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
list_posts 'limit' parameter has no minimum/maximum bounds. Unbounded integers let LLMs pass absurd values (e.g., limit=999999) that could timeout or exhaust memory.