Struct ToolRoster 

pub struct ToolRoster(/* private fields */);

Which tools the model is offered, for WorkspaceBuilder::with_tool_roster.

A thin wrapper over mentra’s ToolProfile rather than a re-export of it: ToolRoster::default is the one construction this crate has an opinion about (today’s exact hidden set), and wrapping it is what lets that default live beside the constant it is built from instead of at every call site that wants “basis’s usual roster, plus…”.

Implementations

impl ToolRoster

pub fn hide(names: impl IntoIterator<Item = impl Into<String>>) -> Self

ToolRoster::default’s set, plus names.

Extends rather than replaces, so narrowing a roster is additive: a caller hiding one more tool never has to restate spawn’s replaced doors or the unsurfaced intrinsics to keep them hidden too. Call only for a denylist built from nothing instead of from basis’s own.

pub fn only(names: impl IntoIterator<Item = impl Into<String>>) -> Self

Offers exactly names, mapped straight to mentra’s own ToolProfile::only — an allow-list rather than hide’s denylist, and basis states no opinion of its own on top of it.

Three honest caveats, each pinned by a test beside this one:

• Cannot itself un-register the file tools — that is a runtime decision, not a roster one. A roster is per-workspace; which file tools a runtime carries at all is fixed once, per-runtime, at RuntimeBuilder::with_file_tools — basis’s own default of Split, or a host’s Batched, Both, or None. only cannot reach across and change that from a workspace. What it can do, and does, is stop offering whatever the runtime carries: a set that names none of read/ls/grep/glob/write/edit makes ToolProfile::allows refuse every one of them for this workspace’s agents, exactly as it refuses any other name left out — see only_hides_the_file_tools_but_cannot_reach_the_runtimes_profile. A host that wants the tools gone from the registry too — so a sibling workspace sharing this runtime, or mentra’s own APIs reached through Runtime::mentra_runtime, cannot find them either — builds that runtime with with_file_tools(FileToolProfile::None) in the first place; there is no way to reach the same effect from a roster alone.
• Does not imply spawn. A set that omits crate::tools::SPAWN is a legitimate roster — a knowledge agent with no delegation and no command door is a real shape — but it is also a model with no route to a subagent or a shell command at all. Name it if the agent needs either.
• Does not imply load_skill. Skills are basis’s own on-demand convention; a set that omits it is a model that cannot load one, no matter how many are registered.

Trait Implementations

impl Clone for ToolRoster

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ToolRoster

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for ToolRoster

fn default() -> Self

What every workspace has offered before this type existed: spawn’s two replaced doors (REPLACED_TOOLS) and the intrinsics basis has never deliberately surfaced (UNSURFACED_TOOLS), hidden; everything else mentra’s runtime registers — the file tools, load_skill, compact, and whatever a host’s own tools or an MCP server add — offered.

Pinned by the_default_roster_is_exactly_this and its neighbors in workspace::builder::tests: this has to keep producing that exact set for those tests to mean anything.

impl Eq for ToolRoster

impl PartialEq for ToolRoster

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for ToolRoster