NestJS-based backend server for managing Minecraft servers with user authentication and scheduling
This NestJS backend exposes 7 tools via HTTP controllers, but lacks MCP-specific protocol implementation. Tool definitions are inferred from controller methods and DTOs rather than explicitly registered via MCP. Schemas are present in DTOs (CreateServerDto validates version pattern, port range) but descriptions are minimal (10-30 chars, well below the 50-200 char baseline for LLM optimization). Parameter descriptions exist but are generic ('Server ID to start' vs actionable guidance). No error recovery hints, no output schema documentation, and critical security gaps (deleteServer lacks ownership verification visible in controller). Tool naming follows verb_noun convention (good), but composition issues exist: startServer and stopServer should accept userId for ownership checks, yet stopServer omits this in the controller signature.
Create a new Minecraft server with specified name, version, and port
Delete a Minecraft server and remove it from the database
Retrieve all servers belonging to the authenticated user
Authenticate user with email and password, returning JWT access token
Register a new user with email and password
Start a stopped Minecraft server by spawning a Java process with the server jar
Stop a running Minecraft server by sending stop command to the process
No explicit MCP tool registration detected. Tools are inferred from NestJS controller methods, not registered via MCP protocol. This violates the tool definition pattern and prevents proper schema exposure to MCP clients.
Descriptions are too short (10-40 chars, baseline 50-200). 'Retrieve all servers belonging to the authenticated user' (54 chars) is acceptable, but 'Server ID to start' (18 chars) lacks context. No guidance on when to use each tool or what happens on error.
deleteServer lacks visible ownership verification in controller (Delete method omits userId check). This is a critical security gap, any authenticated user could delete any server. Violates permission-gate pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2026-07-28+ | v2 |
No output schema documentation. Tools return Prisma objects or service responses, but LLMs cannot see what fields to expect. E.g., createServer returns a server object, what fields? Does it include userId, path, status? Violates response-shaper pattern.
No error recovery guidance. Errors are thrown (ConflictException, NotFoundException) but descriptions do not tell LLMs what to do next. E.g., 'Server not found' should suggest 'Call getUserServers() to list available servers.'