This is not an MCP server, it is a Cypress test framework with a minimal, incomplete MCP-like plugin stub. The two 'tools' are not properly registered as MCP tools, lack formal schemas, and have critical documentation gaps. The codebase shows no evidence of MCP protocol implementation (no message handling, no resource/prompt/tool endpoints, no proper serialization). The 'mcpHealthCheck' task is a Cypress plugin hook, not an MCP tool. The 'login' command is a Cypress custom command, not an MCP tool. Neither has input validation, error handling, or composition patterns. The descriptions are minimal (13 and 8 words respectively), far below the 50-200 char baseline for LLM-optimized tools. No parameter descriptions exist. No output schemas are documented. This artifact is fundamentally misclassified as an MCP server.
Tools (2)
loginwritesource verified25/100
Custom command to login to the application
mcpHealthCheckread only17/100
Minimal health check; tests can call this task and handle null/ok accordingly. If you have more logic (HTTP check to MCP_BASE_URL) add it here.
Not a valid MCP server implementation. No MCP protocol endpoints, message handlers, or resource/tool/prompt/logging interfaces. Codebase is a Cypress test framework with Cypress plugin hooks and custom commands, not MCP tools.
Tool descriptions are critically insufficient (8-13 words). Baseline is 50-200 chars. Neither tool explains WHAT it does, WHEN to use it, or what it returns. LLMs cannot determine tool selection from these descriptions.
No error handling or recovery guidance. No indication of what errors can occur, how to classify them (retryable, user-fixable, fatal), or what the LLM should do next.
Recommendations
This codebase is a Cypress test framework, not an MCP server. To create a valid MCP server: (1) Implement proper MCP protocol transport (STDIO or HTTP with SSE). (2) Define tools via the MCP tool registration mechanism with proper JSON-RPC message handling. (3) For 'mcpHealthCheck': rename to 'check_mcp_health', expand description to 100+ chars explaining it verifies MCP availability (does HTTP check to MCP_BASE_URL if provided), document output schema {ok: boolean, message?: string}. (4) For 'login': refactor as a resource or separate authentication mechanism, never accept credentials as tool parameters. If kept, rename to 'perform_login', expand description to 150+ chars, document email validation (RFC 5322), password constraints, output schema with session_token or user_id, and error cases (invalid_credentials, account_locked). (5) Add proper error handling with recovery guidance per pattern:recovery-guide. (6) Document all parameters with format, validation, and constraints in the description text (not just name).
Implement transport layer: choose STDIO (for local use) or HTTP with SSE (for remote access). Add MCP protocol message handlers (initialize, tools/list, tools/call, etc.).
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to guide agent planning. 'mcpHealthCheck' should be marked readOnlyHint=true; 'login' should be marked destructiveHint=true (or removed entirely in favor of session management).
Create proper output schemas for both tools. Example: mcpHealthCheck returns {ok: boolean, timestamp: string}; login returns {session_id: string, user_id: string, expires_at: string} or error with detailed message.
Credentials exposed in parameters. 'login' tool accepts email and password as plain parameters. Server-side secret injection pattern violated, credentials will appear in agent traces and logs.
Parameter descriptions are trivial (2-3 words each). 'User email address' and 'User password' do not explain format, validation, constraints, or what the tool does with them.
No idempotency guarantee. Calling 'login' multiple times may create multiple sessions or fail in unexpected ways. No documentation of side effects.
login
Add parameter constraints: email parameter should have a regex pattern for email validation; password should document minimum length and character requirements.
Remove credentials from tool parameters. Use environment variable injection (e.g., CYPRESS_USER_EMAIL, CYPRESS_USER_PASSWORD) or a secrets vault. Log no credentials.
Add per-tool examples in documentation: 'Call check_mcp_health to verify the server is responding. Call perform_login with valid credentials to start a session before running tests.'
Implement pagination and result limits if tools return lists (not currently applicable, but anticipate if tools expand).
Add audit logging: record which agent invoked which tool, with scrubbed parameters (never log passwords), timestamp, and result.
If this is meant to be a Cypress helper (not an MCP server), clarify that and remove MCP claims. If it is meant to be an MCP server, completely redesign it to implement the MCP protocol spec (2026-07-28).