Loading ToolBench
Neo4j-backed knowledge graph server for immutable compliance auditing, data lineage tracing, and breach detection via the Model Context Protocol (MCP). Exposes unified graph query tools for forensic analysis of data asset storage, replication, encryption, and compliance governance.
Server has 7 tools with clear verb-noun naming (trace_, get_, check_, resolve_, log_, retrieve_, audit_). All tools have descriptions (avg 150 chars, within baseline 34-392). Input schemas present with typed parameters and descriptions. However, output schemas are undocumented, tools return JSON strings without declared field structures. Error handling is minimal (generic 'Database query failed' messages). No parameter constraints (enums, ranges) despite several tools accepting free-form strings. Missing tool annotations (readOnlyHint, destructiveHint). One tool (log_audit_finding) is WRITE but lacks confirmation/dry-run pattern. Composition is sound, tools chain well (resolve_location → location-based tools). No secrets exposed in parameters.
Scans the entire graph for data assets crossing compliance boundaries. This is the primary breach detection scan — use for full compliance audits. Optionally pass a classification (e.g. 'Highly_Restricted') to scope the scan; the summary then reports the distinct-asset count for that class.
Checks the sovereignty and compliance boundaries governing a compute node.
Finds all data assets stored or replicated to a specific compute node. Use this to determine the blast radius of a compromised server.
Logs an immutable compliance finding to the knowledge graph. This is a WRITE that mutates the graph. Call it ONLY when the user explicitly asks to log, record, or write a finding. Do NOT log a finding as an automatic side effect of tracing, identifying, or auditing — those are read-only actions.
Resolves an informal or partial location phrase (e.g. 'APAC gateway') to an EXACT Compute_Node name. Returns the exact name on a single match, or a candidate list to disambiguate. Call this before a location-based tool when the phrasing is not already an exact node name.
Output schemas undocumented. All tools return JSON strings without declared field structures. LLMs cannot plan downstream calls or extract specific fields reliably.
No parameter constraints (enums, ranges). 'classification' in audit_restricted_asset_leaks and 'finding_type' in log_audit_finding accept free-form strings, inviting hallucinated values.
Error messages are generic and non-actionable. 'Database query failed: {e}' gives LLM no recovery path. Should include 'Try searching with a partial name' or 'Check that the asset exists in the graph'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Retrieves historical audit findings previously logged for an asset.
Traces the full lineage of a data asset including storage, replication, encryption, and compliance governance.
log_audit_finding (WRITE tool) lacks confirmation/dry-run pattern. Agents can accidentally log false findings without review. Should support a 'dry_run' parameter or require explicit confirmation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints.