MCP server wrapping the api.phish.net v5 and phish.in v2 APIs.
MCP Phish exposes only one tool: 'health'. The tool name lacks a clear action verb (should be 'check_health' or 'get_health_status'). The description is verbose (180+ chars) but does not follow the pattern:tool-description guidance of 10 - 1024 chars optimized for LLM selection. No input schema is visible in the provided source code, the tool appears to accept no parameters, but this is not explicitly documented. No output schema is documented. The server is HTTP-based (fastmcp), which is positive for transport, but the single tool's definition quality is severely limited by missing schema documentation and unclear naming.
Lightweight liveness endpoint for the Docker HEALTHCHECK. Separate from the HTTP /health route: returns server health status including cache hit/miss timestamps, upstream API reachability, and vault staleness.
Tool 'health' lacks explicit input schema definition. No JSON Schema visible in source code for parameters or return type.
Tool name 'health' does not start with an action verb. Should be 'check_health', 'get_health_status', or 'get_server_health' to clarify intent.
No output schema documented. LLMs cannot plan downstream calls or extract fields without knowing what 'health' returns (e.g., does it return {status, cache_hits, cache_misses, upstream_reachable, vault_staleness}?).
Description is verbose and mixes implementation details ('Docker HEALTHCHECK', 'separate from HTTP /health route') with functional intent. Should focus on WHAT the tool does and WHEN to call it.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | <=2025-11-25 | v2 |
Server exposes only one tool. This is a minimal MCP server, likely a health-check utility rather than a full integration. Limited domain coverage.