Comprehensive MCP server for code analysis and web scraping. Supports code quality analysis, linting, dependency analysis, static/dynamic web scraping, and API discovery.
This MCP server has significant quality gaps across all definition dimensions. While 23 tools are registered with basic schemas, most lack meaningful descriptions, parameter types are inconsistent, and error handling is minimal. Tool names follow verb_noun convention reasonably well, but descriptions are generic ('Analyze code quality for a file or set of files') without explaining WHEN to use the tool, HOW it differs from similar tools (e.g., analyze_code_quality vs analyze_complexity vs detect_code_smells), or what the output structure contains. Many parameter schemas are incomplete, options objects lack internal property types and descriptions. The web scraping and API discovery tools expose web request parameters (url, config) without explaining rate limits, timeouts, or security implications. No tool includes output schema documentation, making it impossible for LLMs to know what fields to expect. Error handling in server.ts returns generic InternalError with only the message and stack, with no recovery guidance or actionable next steps for agents.
Missing output schema documentation. No tool specifies what fields the response contains, their types, or structure. LLMs cannot plan downstream tool calls or extract needed data without knowing response fields.
Add explicit output schema documentation to every tool. For example, analyze_code_quality should document: 'Returns { complexity: number, maintainabilityIndex: number, technicalDebt: string, codeSmells: CodeSmell[], duplications: Duplication[], linesOfCode: number, cyclomaticComplexity: number }' (reference types/index.ts CodeQualityMetrics).
Expand tool descriptions from generic statements to LLM-optimized guidance (50 - 200 chars). Example: 'Analyze cyclomatic and cognitive complexity for code files. Use this to identify overly complex functions that need refactoring. Returns complexity scores and specific line numbers. Different from calculate_complexity (single-file) which focuses on one function.' This disambiguates from similar tools.
Document web scraping tool constraints explicitly. For scrape_html_static and scrape_dynamic_content, add to description: 'Timeout defaults to 30s. Use followRedirects=true only for trusted domains. Returns up to 1000 elements per request; use pagination for large results. Respects robots.txt.'
Consolidate overlapping code analysis tools. Keep analyze_code_quality as the primary multi-metric tool; rename or remove calculate_complexity and analyze_complexity to avoid redundancy. If needed, create separate tools with clear names: analyze_cyclomatic_complexity, analyze_cognitive_complexity.
Score history
Overall score trend
↑ 38 points across a rubric change (v1 → v2)
38/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
38
2026-07-28+
v2
2026-03-09
F
0
-
v1
Discover API endpoints by monitoring network requests
extract_api_schemaread only48/100
Extract API schema from responses
extract_imagesread only50/100
Extract image URLs from webpage
extract_linksread only50/100
Extract all links from webpage
extract_tablesread only50/100
Extract tables from webpage
extract_textread only50/100
Extract text content from webpage
find_duplicationsread only50/100
Find code duplications across files
format_codewrite50/100
Format code using Prettier
lint_coderead only50/100
Lint code files for style and quality issues
scan_security_issuesread only50/100
Scan code for security issues
scrape_by_selectorread only50/100
Scrape HTML content by CSS selector
scrape_dynamic_contentread only50/100
Scrape dynamic content rendered by JavaScript
scrape_html_staticread only50/100
Scrape HTML content from URL using static method
screenshot_pageread only50/100
Take screenshot of webpage
test_api_endpointread only50/100
Test API endpoint
Generic, underdescriptive parameter descriptions. Many parameters have descriptions like 'Files to scan' or 'Optional analysis options' without explaining what the tool returns, when to use it vs similar tools, or required input formats. Descriptions should explain WHAT the tool does, WHEN to call it, and any prerequisites (54 chars avg vs 194 chars baseline for A+ tools).
Incomplete parameter schemas in 'options' objects. Parameters like 'options' in analyze_code_quality, detect_code_smells, and find_duplications are declared as type 'object' with 'description' but lack internal 'properties' definitions and sub-parameter descriptions. This forces LLMs to guess what options are valid.
Web scraping tools (scrape_html_static, scrape_dynamic_content, extract_text, extract_links, extract_images, extract_tables, screenshot_page) do not document security implications, rate limits, or timeouts. These tools make external HTTP requests; agents need guidance on when they might fail, how long they block, and whether rate limits apply.
Tool naming conflicts and redundancy. Multiple tools perform overlapping analysis: analyze_code_quality, analyze_complexity, calculate_complexity, and calculate_cognitive_complexity all relate to code metrics. Descriptions do not clarify which to call for which analysis, forcing LLM to reason about subtle differences.
Generic error handling. Server catches all exceptions as InternalError with only message and stack. No recovery guidance for LLM. Example: if a file path is invalid, the error should say 'File not found: /path/to/file. Verify the path and try again.' Not just 'Tool execution failed: ENOENT'.
No pagination support. Tools returning lists (e.g., find_duplications, extract_links, extract_tables, analyze_dependencies) do not declare limit, offset, or cursor parameters. Large results will overflow context windows and degrade agent reasoning.
format_code is marked as WRITE risk but lacks confirmation/dry-run mechanism. Agents can irreversibly modify code without checking implications. Destructive tools should support dry-run or confirmation patterns.
No tool annotations. Tools do not declare readOnlyHint, destructiveHint, or idempotentHint metadata. Only format_code is marked as WRITE in the schema; other tools lack explicit hints.
Implement actionable error messages. Wrap tool handlers with try-catch that classifies errors: file-not-found, invalid-format, permission-denied, timeout, unsupported-language. Return specific guidance. Example: 'File /path/to/file.js not found. Verify path exists and is readable.'
Add pagination support to list-returning tools. Add optional parameters: limit (1-100, default 20), offset (default 0). Return { results: [...], total: number, hasMore: boolean } to enable agents to fetch all results if needed.
Add dry-run support to format_code. Accept optional dryRun boolean parameter. When true, return what would be changed without modifying files.
Enumerate valid config properties for web scraping tools. Replace vague 'config: object' with explicit properties schema including: selectors (array of strings), timeout (number, 1000-60000ms), headers (object with string keys/values), followRedirects (boolean), maxRedirects (number, 0-10).
Add tool annotations. For each tool, declare metadata: { readOnlyHint: true } for read-only tools like analyze_code_quality; { destructiveHint: true } for format_code; { idempotentHint: true } for tools that can be safely retried.
Document which tools can be called in sequence to accomplish user intents. Example: to refactor code, call analyze_code_quality → detect_code_smells → lint_code → format_code. Include this chaining guidance in tool descriptions.
Add parameter constraints and ranges. Example: analyze_dependencies depth parameter should have minimum: 1, maximum: 10. timeout parameters should be numeric ranges: minimum: 1000, maximum: 60000.