Minimal self-contained MCP stdio server exposing a health-check tool to verify MCP wiring end-to-end
The caddis server exposes only one tool: caddis_ping. While the tool name follows verb_noun convention (ping is a weak verb but acceptable for health checks), the implementation is severely limited. The tool has an empty input schema (no parameters), minimal description (18 chars, below the 34 char p10 baseline), and no documented output schema. The server appears to be a minimal health-check stub rather than a functional MCP tool suite. The description 'Health-check tool, returns a caddis marker so MCP wiring can be verified.' is technically present but extremely terse and does not follow LLM-optimized guidance (10-200 char range is acceptable but lacks context about when/why to call it). The input schema is valid JSON but offers no parameters for configuration or control. No error handling guidance, no recovery patterns, and no output schema documentation visible in the provided code.
Health-check tool — returns a caddis marker so MCP wiring can be verified.
Tool description is extremely terse (18 chars), below baseline p10 of 34 chars. Lacks context about what 'caddis marker' means, when to call the tool, and what output structure to expect.
No output schema documented. LLMs cannot infer what fields the tool returns or plan downstream operations. Pattern requires documenting return types for all tools.
No error handling guidance provided. Tool description does not explain failure modes, retry behavior, or what an LLM should do if the health check fails.
Single-tool server suggests incomplete implementation. Caddis appears to be a plugin harness (based on repo context) but only exposes a diagnostic ping tool. Verify this is intentional or add functional tools for the core use case.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |