Loading ToolBench
MCP server exposing LucidShark code quality and security analysis tools to AI agents. Provides unified pipeline for linting, formatting, type checking, security scanning (SAST, SCA, IAC, container), testing, coverage analysis, and code duplication detection across Python, JavaScript, TypeScript, Rust, Go, Java, Kotlin, C/C++, C#, Ruby, PHP, Swift, and Scala.
LucidShark provides 4 tools with comprehensive descriptions and reasonable schemas. The 'scan' tool has excellent, detailed documentation with clear guidance on when to call it and expected output format. However, there are gaps: the 'check_file' and 'get_fix_instructions' tools lack adequate descriptions for parameter relationships and expected outputs; 'apply_fix' lacks error handling guidance and confirmation patterns for a destructive operation. Parameter schemas are present but inconsistently documented, 'scan' has excellent inline guidance in the description, while other tools rely on minimal parameter descriptions. No tool declares permissions/scopes or includes audit/logging guidance. Output schemas are not formally documented in JSON Schema format, forcing LLMs to infer response structure.
Apply auto-fix for a fixable issue.
Check a specific file and return issues with fix instructions. Automatically detects the file type and runs relevant checks.
Get detailed fix instructions for a specific issue. Use after running scan to get more details about how to fix an issue.
Run comprehensive code quality checks. LucidShark is a unified pipeline for: LINTING (Ruff, ESLint, Biome, Clippy, Checkstyle, PMD - style issues, code smells); FORMATTING (Ruff Format, Prettier, rustfmt - code formatting); TYPE_CHECKING (mypy, Pyright, tsc, SpotBugs, cargo check - type errors); SAST security (OpenGrep - code vulnerabilities); SCA security (Trivy - dependency vulnerabilities); IAC security (Checkov - infrastructure misconfigurations); CONTAINER security (Trivy - container image vulnerabilities); TESTING (pytest, Jest, Karma, Playwright, JUnit, cargo test - runs tests); COVERAGE (coverage.py, Istanbul, JaCoCo, Tarpaulin - coverage gaps); DUPLICATION (Duplo - code clones). **CRITICAL**: By default, scans only changed files (uncommitted changes). Use all_files=true for full project scan. Use files=[...] to scan specific files. WHEN TO CALL: Run proactively after editing/writing code files, after fixing bugs, before reporting tasks as done, and before commits. Use fix=true to auto-fix linting and formatting issues. DOMAIN SELECTION: Pick domains based on files changed — .py/.js/.ts/.rs/.go/.java → ["linting", "type_checking"]; Dockerfile → ["container"]; Terraform/K8s → ["iac"]; dependency files → ["sca"]; security-sensitive code → ["sast"]; to run tests → ["testing"]; to check coverage → ["coverage"]; before commits or mixed changes → ["all"]. OUTPUT FORMAT: (1) Announce what you're checking. (2) List ALL issues grouped by domain. (3) Show pass/fail status for EVERY domain checked. (4) End with summary: total issues, count by severity, status per domain.
apply_fix tool (WRITE operation) lacks confirmation or dry-run support. This destructive operation should require explicit user confirmation before applying fixes to avoid unintended code changes.
check_file, get_fix_instructions, and apply_fix tools have minimal descriptions (35-45 chars). They do not explain WHEN to call them vs. scan(), what structure they return, or how they fit in a workflow. Descriptions must be 50-200 chars and answer: what does it do? When use it? What are dependencies?
No output schemas documented for any tool. LLMs cannot infer response structure, breaking tool chaining. scan() returns issues with 'issue_id' field, but check_file and apply_fix return formats are undocumented, forcing LLMs to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
apply_fix description does not indicate it is a state-modifying operation (write). Agents need explicit signal to know this is not retryable without side effects. Description should begin: 'Apply auto-fix for a fixable issue. WARNING: This modifies project files.'
Error handling guidance missing from all tools. No recovery hints, retryability classification, or next steps on failure. E.g., apply_fix should document: 'If fix fails, the file remains unchanged. Retry with the same issue_id or call scan() to verify the issue persists.'
No scope/permission declarations. Tools do not state what access they require (e.g., 'read:repo', 'write:files'). This prevents least-privilege agent configuration and audit trail clarity.
scan tool 'domains' parameter has a good enum (linting, type_checking, etc.), but default=['all'] is not validated. If an invalid domain slips into the array, error handling should be explicit: 'Invalid domain "xyz". Valid domains: [list]'. Current error behavior is undocumented.
scan tool accepts 'files' parameter but does not document the expected path format (absolute vs. relative to project root, glob patterns allowed?). Parameter description should clarify: 'Relative paths from project root. Glob patterns not supported. E.g., ["src/main.py", "tests/test_utils.py"]'.