Loading ToolBench
AI Code Security Scanner — detect vulnerabilities in AI-generated code using pattern matching, AST analysis, and optional AI-powered explanations and fix suggestions
mycop presents a focused security scanner with 5 tools covering a clear domain: code scanning, rule discovery, finding explanation, AI-powered review, and dependency checking. Tool names are action-oriented (scan, list_rules, explain_finding, review, check_deps) and descriptive. However, significant gaps exist in parameter descriptions and schema completeness. All tools have good conceptual descriptions (100-250 chars), but input parameter descriptions are sparse or missing in several cases. Error handling guidance is minimal, tools return generic errors without recovery hints. STDIO transport hard-caps the protocol readiness score.
Check project dependencies for hallucinated or suspicious packages. Reads requirements.txt and package.json to list all dependencies.
Get a detailed explanation of a specific security finding. Provides attack scenarios, impact analysis, and remediation guidance.
List available security rules. Filter by language (python, javascript, go, java), severity, or search term. Returns rule IDs, descriptions, CWE/OWASP mappings, and fix hints.
Deep AI-powered security review of a single file. Goes beyond rule-based scanning to find logic flaws, auth issues, and complex vulnerability patterns.
Scan files or directories for security vulnerabilities in Python, JavaScript, TypeScript, Go, and Java code. Returns findings with severity, CWE/OWASP mappings, and fix hints. Uses 200 built-in rules covering OWASP Top 10 and CWE Top 25.
Parameter descriptions missing or incomplete for most tools. 'path' appears in 4 tools but lacks format guidance (file vs directory? absolute vs relative?). 'severity' enums are present but no description of what 'critical' vs 'high' means in context of OWASP/CWE mappings.
Output schemas not documented. Tools return JSON responses but the structure/fields are not declared in the tool definition. LLMs cannot plan downstream calls or extract specific fields without knowing the response schema. Example: 'scan' returns 'findings' but the per-finding structure (fields, types, required) is not visible.
Error handling lacks recovery guidance. Tools return generic internal_error messages ('Serialization error', 'Task join error') without actionable next steps. No distinction between retryable errors, user-fixable errors, or fatal failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | 2024-11-05+ | v1 |
'scan' tool accepts 'paths' as array of strings but no guidance on whether globs are supported, whether symlinks are followed, or what happens if a path does not exist. Ambiguous parameter semantics.
'explain_finding' and 'review' accept 'ai_provider' enum with options like 'claude-cli', 'anthropic', 'openai', 'ollama', 'none' but no description of what each means, what credentials are required, or how fallback works if a provider is unavailable.
'max_results' parameter in 'scan' has no documented default or upper bound. Unbounded numeric parameters invite LLMs to pass absurd values (e.g., 999999) that could cause performance degradation.
No support for pagination in 'list_rules' or 'scan'. If rule count or findings exceed reasonable display size, results will be truncated or blow the context window. No limit or offset parameters present.