NOT AN MCP SERVER: This is a Next.js REST API application with no MCP protocol implementation visible. Tool definitions are inferred from file structure, not registered with MCP server. MCP requires explicit tool registration via SDK (e.g., @modelcontextprotocol/sdk); none found in source.

No input schemas visible for 7 of 14 tools (GET endpoints, logout, callback). Cannot verify parameter types, constraints, or descriptions.

Descriptions are generic and lack LLM-optimization. Most descriptions (10/14) are 35-55 chars, meeting minimum rubric length (10-1024) but falling below baseline (194 chars avg for A+ tools). Examples: 'Retrieve user achievements' (27 chars), 'Get current session information' (31 chars) do not explain WHEN to use, WHAT happens, or dependencies.

Destructive operations (DELETE /api/cards/[id]) lack confirmation or dry-run support. Description does not indicate irreversibility or ask for confirmation before executing. Per pattern:confirmation-request, LLMs need explicit guidance for destructive ops.

No output schemas documented for any tool. Tools return responses (cards, sessions, etc.) but the structure is not defined in visible source. LLMs cannot plan downstream tool calls without knowing what fields to expect.

No error handling guidance visible. Tool descriptions do not indicate what errors are possible, which are retryable, or what the LLM should do next. Per pattern:recovery-guide, errors should tell agents what to do, not just fail.

Parameter 'id' in GET /api/cards/[id] and DELETE /api/cards/[id] is named ambiguously. In Next.js routes, this is a path parameter, but the schema should clarify: is it a UUID, numeric ID, or slug?

OAuth callbacks (GET /api/auth/google/callback) should not be exposed as standalone tools. MCP tools represent user-callable actions; OAuth callbacks are internal redirect handlers. This indicates confusion about what constitutes a tool.

No pagination support visible for list-like tools (GET /api/achievements, GET /api/decks/[id]/card-performance). Per pattern:paginated-result, tools returning arrays must support limit/offset and return a count. Descriptions do not mention pagination.

Parameter descriptions lack constraints. E.g., POST /api/cards expects 'deckId' (string) but no description states if it's required, its format (UUID vs numeric), or what happens if invalid.