Automated code analysis, bug detection, and fixing with feedback support for code generation. Analyzes code files for bugs, anti-patterns, provides improvements, explains code, generates tests, refactors code, and generates code.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server exhibits significant quality gaps across naming, descriptions, parameter schemas, and error handling. While tool names follow verb-noun conventions adequately, descriptions are frequently vague or generic. Most critically, the provided source code does NOT include the actual tool implementations or explicit schema definitions, only a high-level tool list. This means parameter types, constraints, enums, and output schemas cannot be verified from the source. Per the hard rules, tools without visible schemas score 0 on schema dimension. Descriptions are present but many are under 100 characters and lack WHEN-to-use context, output documentation, or actionable error guidance. No evidence of permission gates, secret injection, audit logging, or rate limits. The codebase includes a tool_meta decorator (in client/tool_meta.py) that suggests capability tagging infrastructure, but this is CLIENT-SIDE metadata routing, not MCP server tool registration. The actual fastmcp server implementation in servers/code_assistant/server.py is not provided in the source listing, making it impossible to verify schemas, error handling, or protocol compliance.
Tools (10)
analyze_code_fileread onlysource verified57/100
Analyze a code file for bugs, anti-patterns, and issues. Supports Python (AST-based deep analysis), JavaScript, TypeScript, Rust, and Go.
analyze_projectread onlysource verified53/100
Analyze entire project structure and codebase for issues and metrics.
explain_coderead onlysource verified53/100
Explain what code does in natural language.
fix_code_filewritesource verified55/100
Automatically fix detected issues in a code file. Creates backup, applies fixes, runs formatter.
generate_codewritesource verified55/100
Generate code from natural language specifications.
Tool schemas not visible in source code. Provided tool list includes parameter names and defaults but no explicit JSON Schema definitions, type constraints, enums, or validation rules.
Descriptions lack WHEN-to-use context, output documentation, and error recovery guidance. E.g., 'Automatically fix detected issues in a code file' does not explain: What issues? What frameworks? What happens on failure? What should the agent do if the fix is partial? Missing ~100+ character descriptions with actionable context.
Provide complete JSON Schema definitions for all tool inputs in the fastmcp server implementation. Each parameter must have explicit type (string, integer, boolean, array, object), minLength/maxLength, pattern, enum, or example. Make schemas visible in source or auto-generated documentation.
Expand tool descriptions to 100-200 characters. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) what it returns, (4) what to do on failure. Example: 'Analyze code file for bugs and anti-patterns via AST parsing (Python) or syntax tree inspection (JS/TS/Rust/Go). Returns list of [issue_id, line, severity, description, fix_suggestion]. If syntax is invalid, returns error with line number, try fix_syntax_errors first.'
Document all parameter constraints in descriptions: supported languages for language override, file path rules (absolute/relative/symlinks), regex patterns, min/max values, enum options. Replace implicit examples with formal constraints. E.g., instead of 'default "auto"', say '"auto"|"python"|"javascript"|"typescript"|"rust"|"go"'.
Add output schema documentation showing response fields, types, and meanings. Example for analyze_code_file: '{issues: [{id: string, line: int, severity: "error"|"warning"|"info", description: string, suggestion: string}], total_issues: int, language_detected: string}'.
Implement permission gates. Declare which tools require read-only vs write authority. Verify user/agent permissions before executing destructive operations (fix_code_file, generate_code, refactor_code). Log all mutations to audit trail with timestamp, user, tool, parameters, and result.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 7 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
<=2025-11-25
v2
2026-03-09
F
42
-
v1
writesource verified55/100
Refactor code for better structure, readability, and maintainability.
No documented error handling or recovery paths. Tools like fix_code_file and generate_code can fail (syntax errors, model hallucinations, file I/O errors) but descriptions offer no guidance on how LLM should recover (retry, fallback, ask user).
Destructive/write tools (fix_code_file, generate_tests, refactor_code, generate_code) lack explicit confirmation or dry-run affordances. Per pattern:confirmation-request, irreversible operations should warn the LLM and offer a preview step. Current descriptions do not mention rollback, dry-run safeguards, or what happens if the tool partially fails.
No evidence of permission gates or audit logging. Tools operate on user files and code without documented permission checks (read-only vs write scope). Per pattern:permission-gate, tools should declare required permissions and verify calling user/agent has authority before executing.
Parameter descriptions are minimal or missing actionable constraints. E.g., 'language override' does not specify: which languages are supported? What is the fallback if auto-detection fails? 'file_path' does not specify: relative vs absolute? symlink handling? max path length?
Output schemas not documented. No evidence that responses include structured fields (status, modified_lines, error_code, suggestions) with descriptions. LLMs cannot plan downstream steps without knowing what fields to expect.
Language and framework support undocumented. analyze_code_file claims to support 'Python (AST-based), JavaScript, TypeScript, Rust, Go' but no tool description specifies what analysis is performed for each language, or what happens if code syntax is invalid. Ambiguous scope invites hallucinated behavior.
No evidence of input validation or sanitization against path traversal, command injection, or other attack vectors. Tools accept file_path and project_path directly. Per pattern:tool-gateway, all agent-provided input must be validated; LLMs can be tricked into passing '../../../etc/passwd' or similar.
Missing tool composition documentation. No guidance on how tools chain together. E.g., if analyze_code_file returns issues, does fix_code_file accept the same file_path? Are there IDs or references that link outputs to subsequent tool inputs? Per pattern:tool-chain, tool A's output must contain IDs and references tool B needs.
Add dry-run support to all write tools. E.g., fix_code_file should accept dry_run=true to preview changes without modifying files. LLM should call dry_run first, review, then call with dry_run=false to apply.
Implement comprehensive error handling with recovery guidance. When file not found, return: 'File not found: /path/to/file. Check that the path is correct and readable by the current user.' When syntax errors occur, return: 'Syntax error at line N: (excerpt). Try calling fix_syntax_errors() or ask the user to correct the code manually.'
Add tool-chaining metadata. If fix_code_file modifies a file, return the updated file_path, line count, and summary of changes so suggest_improvements can operate on the result. If analyze_project returns a list of problematic files, include file_path and issue_id in each result so fix_code_file can iterate.
Implement input validation against path traversal, command injection, and file size limits. Example: validate that file_path does not contain '..' or start with '/etc', and that project_path is within an allowed root. Return clear error messages: 'Invalid path: /etc/passwd is outside allowed directory. Allowed root: /home/user/projects/'.
Add rate limiting and timeout controls. Specify in tool descriptions: 'Timeout: 30 seconds per file. Large projects (>10K files) may exceed timeout, use exclude_patterns to reduce scope.' Return actionable timeout errors: 'Analysis timeout after 30s. Scanned 2000 files. Try narrowing include_patterns or reducing max_depth.'
Document idempotency and retry safety for each tool. E.g., 'analyze_code_file is idempotent, calling twice with same input returns same output, no side effects. Safe to retry.' For non-idempotent tools (fix_code_file, generate_code), document: 'Not idempotent, may produce different output on retry due to LLM randomness. Use dry_run to preview.'
Implement tool annotations (readOnlyHint, destructiveHint, idempotentHint) if using fastmcp >= 0.2. Example: @tool(destructiveHint=True) for fix_code_file, @tool(readOnlyHint=True) for analyze_code_file. This signals MCP clients and LLMs which tools have side effects.