Loading ToolBench
AI Linter & Code Quality for AI-Assisted Development. Provides code quality analysis, secret scanning, refactoring guidance, and vulnerability detection for AI-assisted coding.
ailinter provides 7 tools with clear, domain-specific descriptions (avg 180 chars, within baseline 194). All tools have verb-noun naming (analyze_, scan_, get_, assess_, set_, list_). However, input schemas are not visible in the provided source code, only parameter names and descriptions are shown. Tool definitions appear to be registered in internal/mcp/server.go but the actual JSON Schema definitions are not included in the evaluation materials. Error handling is present (tool descriptions mention prerequisites and next steps), but output schemas are undocumented. Parameter descriptions are present but lack format constraints (e.g., no enum for smell_name in get_refactoring_strategy, no bounds on max_commits). Overall: solid naming and descriptions, but schema visibility and parameter constraints are weak.
Analyze a source file for Code Quality issues (complexity, nesting, size, bumpy roads) and security vulnerabilities (injection, XSS, deserialization, weak crypto, XXE). Returns a quality score (0-100) and detailed findings. Run before and after every AI edit. For a quick go/no-go safety check, use assess_file instead.
Quick assessment of whether a file is safe for AI modification. Returns 'Go Ahead' (80-100), 'Proceed with Care' (60-79), 'Needs Work' (40-59), or 'Stop & Refactor' (0-39) with a summary. For detailed findings and a full quality score, use analyze_code instead.
View current ailinter configuration.
NEXT STEP after analyze_code or assess_file reports issues. Returns exact, actionable refactoring instructions with before/after examples and verification steps. Supports: deep_nesting, brain_method, bumpy_road, complex_conditional, god_class, long_parameter_list, primitive_obsession, duplicated_code.
List frequently-changed files with low quality scores. Requires the repo to be a git repository.
Input schemas not visible in source code. Tool definitions reference parameter names and descriptions, but JSON Schema type definitions, constraints (enum, min/max, pattern), and required field declarations are not provided.
Output schemas undocumented. No tool description specifies what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract data without knowing response shape. E.g., analyze_code returns 'quality score (0-100) and detailed findings' but field names, nesting, and pagination are unknown.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Scan source code content for hardcoded secrets: API keys, tokens, passwords, private keys. Uses 150+ detection rules.
Set an ailinter configuration value. Valid keys: access_token, onprem_url, default_path, language, repo_path, enabled_tools, read_only, disable_git.
get_refactoring_strategy lacks enum constraint on smell_name parameter. Description lists 8 valid values (deep_nesting, brain_method, etc.) as free text. Should be declared as enum to prevent LLM hallucination of invalid smell names.
set_config parameter 'key' lacks enum constraint. Description lists 8 valid keys (access_token, onprem_url, etc.) but does not declare them as enum. LLM may pass invalid keys, causing silent failures or unexpected behavior.
list_hotspots max_commits parameter lacks bounds. Description says 'default: 500' but does not specify min/max range. Unbounded numeric parameters allow LLMs to pass absurd values (e.g., 1000000) that break performance or timeout.