A comprehensive security auditing tool designed to detect vulnerabilities and misconfigurations in applications using the Model Context Protocol (MCP).
SecureMCP is critically underdeveloped as an MCP server. The codebase shows only one tool ('scan') with a minimal schema and no meaningful parameter descriptions. The tool definition exists in the HTTP handler (internal/server/server.go:handleScan) but lacks proper MCP tool registration semantics. The 'scan' tool accepts only a 'target' string parameter with no validation, range, format guidance, or examples. The description 'Scan an MCP server for vulnerabilities' is generic and does not explain when to use it, what vulnerabilities it detects, or what the output structure is. The implementation is incomplete, both handleScan and handleGetReports contain TODO comments indicating core logic is not implemented. There is no evidence of an MCP-compliant tool registry, no output schema documentation, no error handling guidance, and no indication this implements the current MCP spec (2026-07-28). The server uses a custom HTTP/Gin-based setup without demonstrable MCP protocol compliance.
Scan an MCP server for vulnerabilities
Tool registration missing MCP protocol structure. No evidence of tools being registered with the MCP spec (tool_name, description, inputSchema). Only a raw HTTP handler exists.
Parameter description is missing or trivial. 'target' parameter has no description explaining format (URL? hostname? IP?), constraints (required, max length?), or examples of valid values.
Output schema not documented. The scan tool returns a generic JSON response ('message' field) with no defined structure, field types, or documentation of what the LLM should expect or how to interpret results.
Tool description is too generic and does not specify WHAT the tool does or WHEN to use it. 'Scan an MCP server for vulnerabilities' lacks context: which vulnerabilities? How long does scanning take? What does the output contain? What are the prerequisites?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
No error handling or recovery guidance. The handleScan handler returns a basic 400 error on binding failure but provides no actionable message. No guidance for what the LLM should do if scanning fails, times out, or the target is unreachable.
Core functionality not implemented. Both handleScan (line 'TODO: Implement scan logic') and handleGetReports contain TODO comments, indicating the tool does not actually perform its intended function. An MCP server with unimplemented tools cannot be used.
No parameter validation or constraints. The 'target' parameter accepts any string with no validation of format (URL syntax), length limits, or whitelist. LLMs will pass arbitrary values.
No input schema visible in tool definition. The HTTP handler uses a basic struct binding (target string) but this is not formalized as a JSON Schema with type, description, and constraint metadata required by the MCP spec.