Loading ToolBench
The agent harness you shrug on in one motion — don a full kit of agents, gates, MCP servers, and doctrine onto any repo. Reversibly.
loadout-harness defines 9 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear action verbs (catalog, detect, user_signals are ambiguous; forge_agent, forge_mcp, synth_mcp use non-standard verbs). Descriptions range 50 - 200 chars but lack WHEN/WHY guidance. Input schemas are visible and typed, but parameter descriptions are sparse or missing context. Output schemas are undocumented, LLMs cannot predict return structure. Error handling is absent from descriptions. No tool annotations (readOnlyHint/destructiveHint). Risk labels (READ_ONLY, WRITE) are metadata, not schema constraints. Overall: functional but below production baseline.
Generate a compact, scannable index of every gear manifest and ready-made loadout from YAML manifests. Supports markdown and JSON output formats. Can validate that CATALOG.md is in sync with source manifests.
Read-only stack profiler. Introspects a repo against a data-driven signal table and emits a StackProfile with matched signals, facts (language, cloud, iac, tracker, etc.), and candidate gear ids.
Scaffold a NEW agent into a project. Takes interview answers and generates an archetype persona template and gear manifest. Validates against the project's profile and warns on overlapping catalog entries.
Source an MCP server from the registry and synthesize a self-contained mcp gear manifest. Resolves a server by query or UUID, flattens it to a Spec, and generates donnable gear.
Assemble a schema-valid profile and loadout from a stack scan and interview answers. Profiles the stack, merges answers, validates, and writes artifacts. Fails loud if required fields are missing.
Resolve a single MCP server by name or UUID from the official registry. Returns a Spec with packages, remotes, and metadata.
Tool names lack action verbs. 'catalog', 'detect', 'user_signals', 'synth_mcp' do not start with clear verbs (get_, create_, search_, list_). LLMs cannot infer intent from names alone.
Output schemas are completely undocumented. No tool describes what fields it returns or their types. LLMs cannot plan downstream calls or extract required data.
Parameter descriptions are minimal or missing context. 'answers' (path to answers.json) lacks guidance on format/structure. 'spec' (object) has no schema. LLMs cannot validate inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Full-text search the official MCP Registry. Returns up to limit Specs ranked by trust (blessed first) and installability (npm/pypi packages over remote-only).
Synthesize an mcp gear manifest from a registry Spec. Selects the best installable package (stdio npm/pypi or remote), generates inline server config, and returns a donnable gear manifest with holster defaults for unknown/unvetted servers.
Read-only scan of the operator's environment. Reads home directory configs, dotfiles, installed plugins, and MCP server names. Returns signals, facts, installed plugins, MCP servers, and gear bias (endorse/avoid from wear log).
No error handling guidance in descriptions. Tools that write to disk (forge_agent, forge_mcp, init) do not document failure modes, recovery steps, or when to retry.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk labels exist in metadata but are not exposed in schema. LLMs cannot determine which tools are safe to retry.