Loading ToolBench
Outrig defines 12 tools with complete JSON schemas and descriptions. Naming follows verb_noun convention (subagent, wait_results, get_result, list_docs, validate_*). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. All parameters have type definitions and descriptions. However, output schemas are not documented, callers cannot see what fields to expect from results. Error handling is implicit (no recovery guidance in descriptions). Tool composition is strong: subagent/subagent_send/wait_results/get_result form a coherent async pattern. Self-tools (list_docs, get_doc, validate_*) are well-scoped. No security issues detected (no secrets in params). Baseline: 549 production tools average 18-char names, 194-char descriptions, 4 params/tool, outrig aligns well on naming and description length but lacks output schema documentation.
Return the JSON Schema for outrig's config.toml, plus where the repo and global config files live and which OCI labels an image can carry. Use it before writing or editing a config.
Return the full markdown of one outrig documentation page. Pass a `page` from outrig__list_docs.
Collect a subagent's result and clear it from the registry.
List the base images outrig suggests for an agent container, with a one-line note on each. Suggestions, not a registry.
List outrig's own documentation pages with one-line summaries. Start here when the user asks how outrig works, how to configure it, or what a config key means -- the pages are the shipped docs for this exact build, so they beat recalling it.
List the MCP servers outrig knows how to install into an image, with their packages and run commands, plus guidance on shell servers. Suggestions, not a registry.
Output schemas not documented. Callers cannot see what fields to expect from tool results (e.g., what does get_result return? what structure does list_docs provide?). This forces LLMs to guess and wastes tokens on discovery.
Error handling lacks recovery guidance. Descriptions do not explain what to do if validation fails, a subagent times out, or a result is not found. E.g., validate_dockerfile should say 'Returns warnings as a list; if critical issues found, fix and retry.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Launch a subagent to work on a task in the background, and return immediately. The subagent shares your container, tools and workspace, but starts with a fresh context: it sees only the preamble and prompt you give it, so write them to stand alone. Launch several to work in parallel. Collect a subagent's findings with outrig__get_result. You are responsible for not giving concurrent subagents overlapping edits to the same files.
Send a prompt to a subagent you already launched -- to follow up on a result, or to redirect one mid-task. Works whether it is idle or still working: an idle subagent starts a new round, a busy one sees your message at its next step. It keeps its history, so you can refer back to what it already did.
Parse and validate a config.toml fragment containing [images.<name>] entries, returning parse and validation errors. Run it on any config you write before telling the user it is ready.
Check a proposed agent-container Dockerfile against outrig's conventions and return advisory warnings. Run it on any Dockerfile you write before telling the user it is ready.
Parse and validate the complete contents of a standalone image.toml (the file `outrig image init` writes).
Block until enough subagents have something to collect, and say which. Carries no payloads on purpose.
wait_results description is terse (18 chars: 'Block until enough subagents have something to collect, and say which. Carries no payloads on purpose.'). Expand to explain: when to call it, what 'min_count' means, and what the return value contains (list of ready subagent names?).
list_mcp_server_suggestions name is long (31 chars; baseline p90=27). Consider 'list_mcp_servers' or 'suggest_mcp_servers' for brevity without losing clarity.
No pagination or result limits documented. If list_docs, list_base_images, or list_mcp_server_suggestions return large result sets, LLMs need to know the limit and how to paginate. Baseline: cap at 20-50 items and offer offset/limit params.