Universal MCP Server Manager with Web Interface - manages and routes tools from multiple MCP servers through a unified HTTP/WebSocket interface with web dashboard
Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
MCPDog presents a mock tool database with 17 tools spanning email, database, file, image, and HTTP operations. However, the actual tool DEFINITIONS are not visible in the provided source code. The tools are referenced in src/mock-tool-database.ts as metadata objects (name, description, exampleParams) but there is NO evidence of explicit MCP tool registration with JSON Schema input definitions. The 'exampleParams' field in the mock database is NOT the same as a properly-defined JSON Schema with type constraints, descriptions per parameter, and output schemas. Without seeing the actual tool registration code (e.g., via server.setRequestHandler(CallToolRequestSchema, ...) or equivalent), we must treat tool definitions as inferred rather than directly visible. Per the HARD SCORING RULES, inferred tool definitions are capped at 50 per-tool overall. Additionally: (1) Parameter descriptions are minimal or absent in the schema view provided ('description' field in Input shows brief text, but no enum constraints, ranges, or format specifications for critical parameters like 'query', 'table', 'filename', 'url'). (2) Output schemas are not documented anywhere, we see no evidence of what these tools return, what fields are included, or how pagination/errors are handled. (3) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. (4) Many tools lack clarity on error handling, retryability, and recovery guidance. Email tools (send_email, gmail_send, smtp_send) are semantic duplicates with no clear delineation. File operations (read_file, write_file, convert_format) lack path validation guidance. Database tools (db_query, db_insert, mongo_find, mongo_insert) expose raw query/document interfaces, major security risk without input sanitization documentation. Overall, the server appears to be a mock/demonstration tool database, not a production-grade MCP server with validated schemas.
Tool definitions inferred, not explicitly visible. The mock-tool-database.ts defines tools as metadata objects with 'exampleParams' rather than formal MCP tool registration with JSON Schema. No evidence of CallToolRequest handler with proper schema validation.
No output schemas documented. Tools do not declare what they return, making it impossible for LLMs to plan downstream calls or extract relevant data from responses.
Add explicit MCP tool registration via server.setRequestHandler(CallToolRequestSchema, ...) or equivalent. Define each tool with formal JSON Schema input schemas, not mock metadata objects. Include 'type', 'properties', 'required', and 'description' for every parameter.
Document output schemas for all tools. Specify what fields each tool returns, their types, and whether results are paginated. Include examples of successful responses.
Consolidate duplicate email tools: either unify send_email + gmail_send + smtp_send into a single configurable tool, or clearly document when each should be used (e.g., 'Use send_email for generic SMTP, gmail_send for Gmail API, smtp_send for custom SMTP servers'). Use distinct naming to make the difference obvious.
Add path validation for file operations: document allowed root directories, reject paths containing '..', and validate against symlink attacks. E.g., 'read_file accepts paths under /data/user_files only; paths must not contain '..' or symlinks.'
Add URL validation for HTTP tools: document SSRF prevention, allowed domains/schemes, and header sanitization. E.g., 'http_get accepts http:// and https:// only; blocks requests to 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and other private ranges.'
Add input validation guidance for database/NoSQL tools: document SQL injection prevention (parameterized queries), NoSQL injection prevention, and query timeout limits. E.g., 'db_query uses prepared statements; all user input is parameterized; max query time: 30s.'
Multiple semantic duplicates for email sending: send_email, gmail_send, smtp_send, send_bulk_email lack clear delineation. LLMs cannot easily distinguish when to use each. Naming convention does not make differences obvious.
Raw query/document parameters (db_query, db_insert, mongo_find, mongo_insert) expose SQL/NoSQL interfaces without documented input validation or sanitization. SQL injection and NoSQL injection risks not addressed. No guidance on error handling for invalid queries.
File path parameters (read_file, write_file, convert_format, resize_image, crop_image) lack constraints. No documentation of allowed directories, path traversal prevention, or validation rules. LLM could be tricked into reading /etc/passwd or overwriting system files.
HTTP tools (http_get, http_post) accept arbitrary URLs and headers. No documentation of URL validation, SSRF prevention, or header sanitization. LLM could be tricked into making requests to internal services or injecting malicious headers.
No parameter descriptions for critical fields. 'query' in db_query lacks format guidance. 'filter' in mongo_find lacks documentation on syntax. 'url' in http_get/http_post has minimal guidance. Parameters like 'encoding' lack enum constraints or default explanation.
Destructive tools (write_file, db_insert, mongo_insert, send_email, gmail_send, etc.) lack confirmation or dry-run patterns. No tool annotation or guidance on retryability, idempotency, or side effects. LLM may unintentionally execute irreversible operations.
No error handling guidance. Tools do not document how failures are communicated (what fields, error codes, recovery suggestions). LLM has no guidance on retry logic, user-fixable errors, or fatal conditions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLM cannot infer tool safety properties without explicit hints. Especially critical for database and file operations.
Add tool annotations: mark readonly tools (gmail_read, db_query, mongo_find, http_get, read_file, scrape_page) with readOnlyHint=true; mark destructive tools (write_file, db_insert, mongo_insert, send_*) with destructiveHint=true; mark idempotent tools with idempotentHint=true.
Add error handling guidance: for each tool, document error scenarios (e.g., 'User not found', 'Invalid SQL syntax', 'File not found'), categorize as retryable/user-fixable/fatal, and provide recovery suggestions. E.g., 'db_query returns {success: false, error: 'Invalid SQL syntax at line 5', retryable: false}. Fix the query and retry.'
Add enum constraints for parameters with known values: convert 'encoding' in read_file to enum ['utf-8', 'ascii', 'utf-16']; 'format' in convert_format to enum ['pdf', 'png', 'jpg', 'docx']; 'database' in db_query to enum of available databases.
Document pagination for list-returning tools: gmail_read and http_get/http_post responses should include limit, offset/cursor, and total count. E.g., 'gmail_read returns {emails: [...], limit: 10, offset: 0, total: 47}. Use offset to fetch next page.'
Add WRITE risk summary in descriptions: e.g., 'send_email sends an email immediately; this is irreversible. Confirm recipient and subject before calling.' This helps LLMs reason about side effects.
Add parameter type hints: 'max_results' in gmail_read should note 'integer, 1-100, default 20'; 'filter' in mongo_find should show example syntax (e.g., {status: 'active', age: {\$gte: 18}}); 'query' in db_query should note 'Parameterized SQL only; values passed via separate params.'
Strip verbose response fields: document which API fields are stripped (e.g., raw HTTP headers, full error stack traces, pagination metadata) to keep context small and focused on relevant data.
Add idempotency guarantees: document which tools are safe to retry (e.g., send_email with the same recipient/subject is idempotent if it includes a deduplication key) vs which have side effects on retry.
Verify actual tool registration in main server code: if tools are not explicitly registered with MCP CallToolRequest handlers, rewrite the registration layer to do so. Mock metadata alone is insufficient for a production MCP server.