Eight tools visible. Forty-seven behind a gate.

01 · SurfaceWhat the model can name

top_level_tool_names() in src/capabilities/schema.rs returns exactly eight strings. Those eight are the only values the strict-JSON parser will accept in the name field, because parse_tool_action_with_schemas derives its allowed set from the keys of top_level_tool_schemas().

Three of them are the gate itself — capability_search, capability_load, capability_call. Two are bookkeeping: goal_update and memory_search. Three are terminal or near-terminal: verify, finish, mark_impossible.

The doc comment on signature_from_schema states the payoff directly: showing the model “the exact argument names + types the dispatcher validates against (instead of guessing q vs query), which is the dominant source of wasted steps and rejected calls.” Composite schemas collapse rather than expand — enum renders as enum, oneOf/anyOf as any — so the signature stays one line even for goal_update.

02 · The gateSearch, load, then call

The registry holds ten capability manifests. Each is a name, a description, a list of ToolManifest entries with full JSON input schemas, and a profile_fit list. The router holds a BTreeMap of the manifests currently loaded, and answers two questions the dispatcher needs: is_tool_loaded(name) and schema_for_loaded_tool(name).

A detail worth pulling out: capability_search matches against a haystack that concatenates the manifest name, description, profile_fit entries, and every tool’s name and description. It checks both the whole lowercased query and each whitespace-separated term. That is why a query like "read files" finds fs through its tool descriptions rather than through its one-word name.

03 · SchemasClosed objects, all the way down

Nearly every tool schema in the registry sets "additionalProperties": false. That is a small decision with a large effect: a model that adds a plausible-looking extra argument gets a schema-validation failure with the offending property named, rather than having it silently discarded and then wondering why the tool ignored it.

The one deliberate exception is capability_call, which sets additionalProperties: true — it has to, because the inner arguments object belongs to whichever concrete tool is being called and is validated separately against that tool’s own manifest schema.

ToolManifest {
    name: "fs.patch".to_string(),
    description: "Apply a precise patch.".to_string(),
    input_schema_json: serde_json::json!({
        "type": "object",
        "additionalProperties": false,
        "properties": {
            "path": {"type": "string"},
            "old":  {"type": "string"},
            "new":  {"type": "string"}
        },
        "required": ["path", "old", "new"]
    }),
}

The tool descriptions carry real operational knowledge, not just labels. browser_panel.open’s description runs to several sentences and is explicit about a specific failure it is preventing: “Never use shell.run with macOS open, /usr/bin/open, Chrome, Safari, or xdg-open to open pages.” That instruction is backed by an actual policy check — gui_open_reason in src/tools/shell.rs:191 hard-denies those commands, so the description describes an enforced rule rather than a hope.

04 · ProfilesRuntime policies, not personalities

The README is blunt about this: “Profiles are runtime policies, not separate chat personalities.” A ProfilePolicy is four fields — a prompt delta, a list of capabilities to preload, a character budget, and whether workers may be spawned. There is no persona, no tone, no roleplay.

Switching profile calls clear_loaded() before loading the new set. That is the entire security story for mode changes: a run that loaded shell as a Coder and then switches to Researcher cannot still call shell.run, because the manifest is gone from the router.

Only the Orchestrator can spawn workers, and it is the one profile that preloads nothing — it has to search and load like everyone else. The asymmetry is intentional: the profile that delegates does not also get a preloaded blast radius.

The prompt deltas are one sentence each and read like operating instructions rather than characterisation. Coder: “Inspect code, patch narrowly, run verification, and avoid broad rewrites.” ComputerOperator: “Use CUA only when files, shell, browser, or APIs cannot solve the task directly.” Verifier: “Challenge completion claims and require authoritative acceptance evidence.” Each delta is concatenated into the context packet’s system string alongside a fixed suffix that ends: “… and do not finish without verification evidence.”

Which profile a run starts in

infer_profile_from_goal reads the goal text when the caller has not passed one. A goal mentioning verification or testing routes to Verifier; other keyword families route elsewhere; the fallback is Orchestrator. If the inferred profile is not Orchestrator, the loop emits a ProfileChanged { from: "Orchestrator", to: … } event before the first model call, so the trace records the inference as an explicit transition rather than an initial condition.

05 · Beyond the registryMCP as a fallthrough, not a front door

Configured MCP servers extend the tool surface without entering the registry. The mechanism is a fallthrough in execute_capability_step: native dispatch runs first, and only if it fails with an “unknown loaded tool” error — detected by is_unknown_tool_error — does the harness try an MCP server.

Routing is by configuration and mirrors the /tools/call gateway exactly. A name of the form <server>/<tool> selects a named server; a bare name falls back to the first configured one. A server with a url is reached over the HTTP JSON-RPC client; a server with a command is spawned over stdio with its configured env injected. Both use a 30-second timeout, and stdio calls are pushed onto spawn_blocking so a slow server does not stall the async runtime.

// Native miss (unknown name) + a configured MCP server -> MCP fallthrough.
let result = match native {
    Err(err) if is_unknown_tool_error(&err) => {
        match dispatch_step_mcp(mcp, tool_name, tool_args).await {
            Some(Ok((summary, success))) => Ok(McpOrNative::Mcp { summary, success }),
            Some(Err(mcp_err)) => Err(mcp_err),
            None => Err(err),
        }
    }
    Ok(result) => Ok(McpOrNative::Native(result)),
    Err(err) => Err(err),
};

Note the None arm. When no MCP server is configured, dispatch_step_mcp returns None rather than an error, and the harness surfaces the original native error. A model that misspelled fs.read gets told about fs.read, not about a missing MCP server it never asked for.

The goal loop passes &BTreeMap::new(), disabling the fallthrough entirely — the doc comment records this as deliberate: “the goal loop does this to stay native-only until it opts in.” The conversational chat loop passes the configured map. Same executor, different policy, expressed as an argument rather than a branch.

There is also a mcp capability in the registry, exposing mcp.call(command, tool, args?, arguments?). That is the explicit path: the model names a server command and a tool directly. The fallthrough is the implicit path, for tools the operator has already wired into config. Both end up in the same JSON-RPC client.