Loading ToolBench
Local dashboard for syncing AI coding tool rules, MCP servers, and skills across Claude Code, Cursor, Codex, Gemini CLI, Qwen Code, DeepSeek Harness, and OpenCode.
18 tools with mixed quality. All have descriptions (good), but most lack formal input schemas with type definitions and parameter descriptions. Tool names follow verb_noun pattern (snapshot*, list*, get*, toggle*, remove*, preview*, apply*, import*, getRules*, applyRules*) which is strong. However, parameter documentation is sparse: most tools show only parameter names and basic types in the input object, without descriptions explaining what each parameter controls or its constraints. Output schemas are not documented. Error handling guidance is absent. The server is STDIO-only, which caps protocol readiness at 50 regardless of definition quality.
Apply the import: write everything from the preview into the personal layer. 'new' candidates are added as new entries; 'extend' candidates append missing agents to enabledAgents.
Apply the canonical rules to specified agents (or all agents if not specified). Places rules via symlink or copy based on sync strategy.
One-shot cleanup: scan every agent's skills dir for .plexus-backup-* residue (left by old versions of placeLinkOrCopy) and quarantine them into the central backups area. Idempotent.
Generate a debug snapshot - a one-shot dump of every path Plexus cares about. Designed to be copy/pasted into a chat with a maintainer when something goes wrong.
Detach rules from an agent by converting a symlink to a copy of the canonical rules, allowing the agent to have independent rules.
Format a debug snapshot into human-readable text output.
Get the effective view - the union of items present in any agent's native config OR in the Plexus store. Each item is keyed by id; the row tells you which agents currently have it and where authority lives.
Input schemas lack parameter descriptions. Tools show parameter names and types (e.g., 'reason': {'type': 'string'}) but omit descriptions explaining what each parameter controls, valid ranges, or constraints.
Output schemas not documented. Tool descriptions do not specify what fields are returned, their types, or structure. LLMs cannot plan downstream calls or extract data without knowing the response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Get the effective view of skills - the union of items present in any agent's native config OR in the Plexus store.
Get the current status of rules across all agents, including whether they are in sync and how they are deployed.
Import rules from a specific agent's instruction file into the personal canonical rules.
List all backup snapshots stored in the Plexus backups directory.
Compute what would be imported from agents' native configs (preview only — no writes). Reads BOTH personal and team layers as the existing store.
Move a colliding file/dir into the central backups area instead of leaving <name>.plexus-backup-<ts> debris in the agent's own directory. Called by adapter placeLinkOrCopy whenever it needs to evict a real file/dir before placing a symlink.
Remove an MCP server from all agents and the store.
Remove a skill from all agents and the store.
Plexus snapshots every agent's native MCP config file and native skill bundles before sync writes. Snapshots live under ~/.config/plexus/backups/<ISO-timestamp>/ so a user can recover if Plexus makes a wrong decision.
Snapshot a single file (e.g. CLAUDE.md) before edit. Stored alongside the regular sync snapshots so the user has one consistent recovery surface.
Toggle whether an agent should have an MCP server. Promotes a native-only item into the personal layer if needed, updates enabledAgents, and runs sync so the change is visible immediately.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. Destructive tools (removeMcpEverywhere, removeSkillEverywhere) lack confirmation or dry-run patterns.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. This is a hard architectural limitation that caps protocol readiness at 50.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. The Risk field in the spec (READ_ONLY, WRITE, DESTRUCTIVE) is present in the evaluation data but not visible in the actual tool definitions, suggesting annotations are not implemented.