Loading ToolBench
Cybersecurity knowledge graph for code review with evidence-backed answers
CyberGraph MCP server has 12 tools with complete input schemas and descriptions. Naming follows verb_noun convention (build_, query_, explain_, analyze_, etc.). Descriptions are substantive (100-300 chars), explaining WHAT each tool does and WHEN to use it. However, output schemas are not formally documented in the code, responses are inferred from return type hints (dict[str, Any]). Parameter descriptions are present but minimal (10-30 chars). No error handling guidance, no recovery hints, and no parameter constraints (enums, ranges). Security-focused domain is well-served by the tool set, but LLM-facing documentation lacks the depth needed for confident tool selection in ambiguous scenarios.
Build the graph and run every analysis; return the full result as JSON.
Build the local CyberGraph database for a repository.
Check whether the current change preserves this project's guarantees. Returns the same object as `cybergraph check --json`. `state` is "accept" or "review"; `checks` gives a per-capability result; and `not_evaluated` lists what CyberGraph could not check on this change. An "accept" means the checks that ran found nothing — read `not_evaluated` before treating it as broader assurance.
Explain possible entrypoint-to-sensitive-sink paths.
Answer a security question with cited, confidence-scored graph evidence. Local-only: returns structured evidence and an explicit confidence level (high/medium/low/insufficient) without contacting any external LLM.
Return cloud attack paths (public exposure -> privileged IaC resource).
Output schemas not formally documented. Tools return dict[str, Any] with inferred field names (e.g., 'answer', 'top_risks', 'count', 'text'). LLMs cannot reliably extract nested fields or plan downstream tool chains without explicit schema documentation.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., build_security_graph_tool may fail if repo_root is invalid, but no recovery hint is provided.
Parameter descriptions are minimal (10-30 chars). 'Root directory of the repository' is clear, but 'Maximum depth for path traversal' lacks context on why depth matters or what happens at max_depth. Descriptions should explain WHEN to adjust parameters.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Import findings from a Semgrep, SARIF, or Gitleaks JSON report into the graph.
Import an OSV Scanner or npm audit vulnerability JSON report into the graph.
Return dependency vulnerabilities ranked by severity x reachability.
Ask a security-review question and return evidence-backed text.
Return prioritized secret-exposure paths (reachable secret -> sink).
Return the ranked top security risks across all graph layers.
No parameter constraints (enums, ranges, patterns). 'limit' parameters accept any integer but should be bounded (e.g., 1 - 100). 'max_depth' should have a documented range. Free-form integers invite hallucinated values.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk labels (WRITE, READ_ONLY) in metadata but not exposed to the LLM via MCP tool annotations. LLMs cannot infer safety properties without explicit hints.