Loading ToolBench
Cross-platform installer and tooling bundle for aigentry-devkit with MCP server registration, workspace scaffolding, and session management
This MCP server exhibits critical definition quality issues across nearly all dimensions. The server exposes 22 tools, but the evidence shows: (1) Tool definitions are inferred from file paths and descriptions only, no explicit schema registration visible in source code; (2) Input schemas exist in the submitted TOOLS array but are NOT corroborated in the actual source files provided (lib/scaffold/project/index.js, bin/aigentry-devkit.js, bin/ctx-router.sh, etc.); (3) Descriptions are present but terse (10-40 chars for many tools like 'doctor', 'profiles', 'init', 'bootstrap', 'status'); (4) No output schemas documented; (5) Error handling guidance is absent; (6) Many tools lack parameter descriptions or have minimal ones; (7) Tool composition is poor, tools have overlapping purposes (scaffold vs workspace-init), unclear sequencing (ctx-on-* tools), and no demonstrated idempotency or recovery patterns. The server appears to be a CLI wrapper bundled as an MCP server without MCP-native design.
Provision ~/.aigentry/ structure and MCP configs
Decompose a task into sub-tasks for parallel assignment
Classify a context event type and determine storage destination (ephemeral, long-term, or both)
Install Claude hooks and git templates for context routing (pre-compact and session-start hooks)
Handle git post-commit event (Event 5.3) - append decision to brain
Handle Claude PreCompact event (Event 5.1) - flush session state and create summary
Handle session lifecycle end (Event 5.5) - final handoff and promote LEARNING markers to brain
Handle Claude SessionStart:compact event (Event 5.2) - restore merged context for hook output
Tool definitions are inferred, not explicitly registered in MCP protocol. No CallTool handlers or Tool message definitions visible in source code.
Many tool descriptions are under 20 characters, falling below the rubric minimum of 10-1024 chars. Tools like 'doctor' (27 chars), 'update' (31 chars), 'init' (49 chars), 'status' (43 chars), 'repair-gemini-mcp' (48 chars) lack sufficient context for LLM tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Handle task-queue status change (Event 5.4) - log transition and promote done tasks to brain
Read wtm handoff and brain summary, emit merged markdown context for session restoration
Diagnose installation health and optionally check installed skills against devkit source of truth
Initialize ~/.config/aigentry/ config directory
Open an aigentry session in the user's current terminal environment with cross-terminal universality (tmux, cmux, iTerm, wezterm, ghostty, generic)
List installer profiles available in the manifest
Re-run canonical Gemini MCP registration for deliberation
Scaffold project files for an AI CLI session (claude, codex, or gemini)
Universal session termination primitive - flush state, terminate via telepty, cleanup cmux workspace
Install/setup aigentry-devkit with optional profile selection and component installation
Show health status of all modules
Switch active task queue focus or show current focus with next actionable tasks
Update aigentry-devkit to latest version
Initialize workspace for AI CLI session (alias for scaffold with legacy argument form)
Output schemas completely undocumented across all tools. The source code shows no structured return type definitions or documentation of what fields LLMs should expect. LLMs cannot plan downstream tool calls or extract the right data without knowing the response structure.
No error handling guidance. Tools do not document what errors they might return, which errors are retryable, or what the LLM should do next if a tool fails. E.g., 'scaffold' with dry-run might fail if --cwd does not exist, but no error message guidance is documented.
Tool composition is poor. 'scaffold' and 'workspace-init' do nearly identical things (scaffold a project for AI CLI sessions), yet they are separate tools with different parameter signatures. This forces LLMs to reason about which to choose and wastes tokens. 'ctx-on-*' tools form a scattered event handler pattern with unclear sequencing and no explicit state machine or dependency documentation.
Many parameter descriptions are missing or minimal. E.g., 'ctx-on-git-commit' has a 'msg' param with description 'Commit message (optional)', but no indication of format, length limit, or whether it's the full message or a reference. 'open-session' has an 'extra-flags' param with description 'Additional CLI flags', but no guidance on valid flags or format.
No confirmation or dry-run patterns for destructive tools. 'session-cleanup' is marked IRREVERSIBLE (hard delete), and 'scaffold --uninstall' removes files, but neither tool documents a confirmation step or offers a safe preview mode before executing. Per pattern: 'Irreversible operations should support a dry-run or confirmation step.'
No evidence of idempotency guarantees. Tools like 'setup' (with force flag), 'scaffold', and 'init' may have side effects (write files, install packages), but there is no documentation of whether repeated calls with the same input produce the same result or risk duplication. Agents retry on failure, non-idempotent tools risk double-installs or duplicate state.
Enum constraints missing. Parameters like 'cli' (should enum: claude|codex|gemini), 'event-type' (should enum: precompact|session-start|git-commit|tq-transition|session-end), and 'new-status' / 'old-status' (task queue status values not enumerated) should declare valid values as enums instead of free-form strings.
No documentation of parameter dependencies or mutual exclusivity. E.g., 'setup' has 'profile', 'manifest', and 'resume' params, but no guidance on which can be used together or if one overrides another. 'scaffold' has 'backup' and 'no-backup' flags that are mutually exclusive, but this is not stated.