Loading ToolBench
Unified MCP server for the marvin plugin — core dev tools, security, taskmaster pipeline, and task tracker under one /marvin: slash prefix. Provides spec-driven development, security scans, decision records, task tracking, and visual widgets.
Marvin-toolkit exhibits significant definition quality gaps. While 14 tools are registered with descriptions and basic schemas, most descriptions are vague or generic (e.g., 'Marvin welcome banner and command reference' for help; 'Query project metrics and analytics' for metrics). Parameter descriptions exist but lack specificity on constraints, formats, and valid ranges. No output schemas are documented. Tool names lack consistent verb-noun structure (e.g., 'task', 'tracker', 'dashboard' are nouns, not action verbs). Error handling guidance is absent. The server appears to be a monolithic plugin with tools inferred from file locations rather than explicit registration visible in source. Critical patterns like idempotent operation hints, permission gates, and recovery guidance are missing.
Create a structured Architecture Decision Record (ADR) capturing context, alternatives considered, the decision, and consequences in MADR/Nygard format.
Security audit and findings viewer — displays security scan reports, vulnerability findings by severity (critical/high/medium/low), and audit status.
Marvin toolbox dashboard — aggregates task board, current work, recent handoffs, audit findings, artifact inventories with freshness, ADR corpus by status, lessons stats, and local usage summary in one report.
Capture current work context into a durable handoff document under .marvin/handoff/ and emit a paste-ready prompt to continue in a fresh session — enables session continuity and knowledge transfer.
Marvin welcome banner and command reference — displays project summary, configured MCP servers, command groups, and full per-command reference with optional filtering by section (core/adr/pr/task/sec/refactor/audit/track).
Browse and manage the project lessons-learned store under .marvin/memory — search lessons, add new ones, show counts by type/tag, or prune stale and duplicate entries.
Tool names lack action verbs. 'task', 'tracker', 'dashboard', 'help', 'audit', 'report' are nouns. LLMs infer intent from verb-noun pairs (e.g., 'create_task', 'list_tasks', 'get_dashboard'). Noun-only names force LLMs to guess the action.
No output schemas documented. Tools return unstructured responses (e.g., 'displays security scan reports'). LLMs cannot plan downstream calls or extract structured data without knowing response fields, types, and nesting.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2025-06-18+ | v2 |
Query project metrics and analytics — task completion rates, velocity, cycle time, and other development metrics from the task board and artifact history.
Unified viewer over every generated .marvin/ report — security, refactor, task, handoff, critique — newest first with per-report freshness, triage mode for recent changes, and snapshot baseline recording.
Create and manage specification documents with Definition of Ready validation — formalizes requirements into executable specs with frontmatter, spec contract, traceability, and file path validation.
Generate a task summary widget showing delivery criteria, gates, and commits — what the task actually delivered with acceptance criteria status and verification results.
Create, manage, and track development tasks with spec-driven workflow — create a new task with title and description, move between states (backlog/doing/review/done), link to pull requests, and view task details.
Retrieve detailed information about a specific task including its full body, acceptance criteria, linked pull requests, and current state.
Query and manage the task board state — list tasks by status (backlog/in progress/done), filter by tags, and get board statistics.
Run verification gates and quality checks — executes build verification, test suites, and deterministic quality gates that refuse incomplete specs or red builds.
Parameter descriptions lack constraint details. 'status' param in tracker accepts 'backlog, in progress, or done' but no enum constraint visible. 'period' in metrics says 'week, month, or quarter' but no validation. LLMs hallucinate invalid values without formal enums.
No error handling guidance. Tools lack recovery hints (e.g., 'If task not found, try list_tasks() first'). Agents cannot self-correct on failures.
Tool definitions inferred from file paths, not explicit registration visible in source. No explicit tool registration code shown (e.g., server.tool() calls).