A Spring Boot MCP server that provides tools for managing Kook announcements
Critical gaps across all dimensions. Two tools with minimal descriptions (13-14 chars, well below 20-char floor). No input parameter descriptions visible, parameters lack type info beyond 'integer' for one tool. No output schemas documented. Tool definitions appear inferred from Spring-AI annotations rather than explicit registration. No error handling guidance, no security considerations, no composition patterns. This is a skeleton implementation.
Get announcement from Kook by id
Get all announcements from Kook
Tool descriptions are critically short (13-14 chars). 'Get all announcements from Kook' and 'Get announcement from Kook by id' fail the 20-char minimum and provide no context for LLM selection, no prerequisites, no return value hints.
No input parameter descriptions visible. The 'id' parameter in get_kook_announcement has type 'integer' but no description explaining what the ID represents, valid range, or how to obtain it. LLMs cannot infer parameter semantics from names alone.
No output schemas documented. Tool definitions do not specify what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract required data without knowing the response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Tool definitions appear inferred from Spring-AI framework annotations rather than explicitly registered with full schemas. Source code shows ToolCallbacks.from(announcementsService) but no visible AnnouncementsService implementation with @Tool/@ToolMethod annotations. Cannot verify actual parameter/output contracts.
No error handling guidance. No indication of what errors are possible (network failure, invalid ID, rate limits), whether they are retryable, or what the LLM should do next. Agents will have no recovery path on failure.