Loading ToolBench
Invisible engineering infrastructure for opencode agents. Provides code graph analysis, execution (lint/test/typecheck), persistent memory, and A2A hub task delegation.
n3rv exposes 27 tools across 4 MCP servers with generally clear naming (verb_noun pattern) and complete input schemas. However, descriptions vary significantly in quality and depth. Code graph tools (code_graph_*) have solid descriptions explaining purpose and use cases. Memory tools are well-described with clear semantics. Exec tools (lint, test, typecheck) lack depth on what 'affected' means and how base_ref is used. Hub delegation tools have minimal descriptions. Output schemas are not documented in the source, LLMs cannot predict return structures. Error handling guidance is absent across all tools. Parameter descriptions are present but often generic (e.g., 'Path to the file to analyze' without format/constraint details). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible, despite clear risk classifications in the spec.
Check pending tasks assigned to the current agent. Pass agent_id explicitly when N3RV_AGENT_SOURCE is not set.
Impact analysis: which files would be affected if this file changes.
Surgical explore: one call returns relevant source + call paths + blast radius.
Show import graph for a file: what it imports, and what imports it.
Index project Python files into the code graph. Incremental (skips unchanged files).
Find all call sites for a function or method by name.
List symbol definitions (functions, classes, methods) in a file or across the project.
Output schemas not documented. LLMs cannot predict return structures for any tool. No documentation of what fields are returned, their types, or how to chain results to downstream tools.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk classifications exist in spec (WRITE, READ_ONLY, REVERSIBLE) but are not exposed to the MCP protocol, preventing clients from applying safety policies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Mark a task as completed after executing it. Provide the task_id from check_pending_tasks or list_pending_tasks and a result summary.
Delegate a task to another agent via the A2A hub. skill_id must match one of the registered agent skills. The task stays assigned until the delegated agent calls complete_task.
Run lint with structured return (auto: ruff→eslint→golangci-lint). Prefer over bash.
Run tests with structured return (auto: pytest→npm test→go test). Prefer over bash.
Run typecheck with structured return (auto: mypy→tsc→go vet). Prefer over bash.
Get the current state of a task by its ID.
List tasks assigned to an agent that are not yet completed. If agent_id is omitted, uses the current agent from N3RV_AGENT_SOURCE.
Query conflict log for LWW merge decisions.
Return recent memories in reverse chronological order.
Delete a stored memory by id, optionally removing it permanently.
Fetch full content of a single active memory by ID.
Record an agent verdict on the relationship between two memories.
Soft-delete memories of a given scope older than N days. Optionally filter by type.
Recall a single memory by topic key.
Persist a memory observation to project-local ChromaDB.
Semantic search across stored engineering memories.
Persist a session-start context entry and return the new session id.
Persist a session summary as a memory of type summary.
Return aggregate counts for active memories.
Return active memories surrounding a focus memory id.
Exec tools (lint, test, typecheck) lack clarity on 'affected' parameter semantics. What does 'affected' mean? How is base_ref used? Does it require git? What happens if git is unavailable?
Hub delegation tools (delegate_task, check_pending_tasks) have minimal descriptions. What is a 'skill_id'? How does the A2A hub work? What happens if delegation fails? Descriptions do not guide LLM selection or usage.
No error handling guidance. Tools do not document what errors can occur, how to recover, or what the LLM should do next. E.g., code_graph_index does not explain what happens if the project_path is invalid or inaccessible.