Struct ToolRouter 

pub struct ToolRouter { /* private fields */ }

Which client reaches which server.

Why a plane needs one at all

A ToolId carries a server because two servers may both offer transfer and they are not the same tool. Nothing enforced that: a plane held exactly one ToolClient and handed it every id, so a deployment could grant tool://ledger/read and wire a client connected to a different server — which then answered, because a transport that never reads the server component cannot tell the difference. The realistic shape is two servers with a tool of the same name, where the wrong one runs and reports success.

One client per server, resolved by name, makes that unspellable. A server nobody registered is ToolError::Unreachable — the honest answer, since there is no transport that could carry the call.

It is also what lets a plane use more than one kind of tool at once: a ToolBox of typed in-process tools and an MCP server are two transports, and a plane routes to both by the server a reference names.

Implementations

impl ToolRouter

pub fn new() -> Self

pub fn server( self, name: impl Into<String>, client: Arc<dyn ToolClient>, ) -> Self

Route one server’s tools to one client.

Panics

If the server is already routed. Silently replacing would make registration order decide which transport carries a call, which is the same defect this type exists to remove.

pub fn toolbox(self, tools: &Arc<ToolBox>) -> Self

Route every server the box implements to the box.

A typed tool names its own server, so the box already knows which ones it answers for; asking a caller to repeat them would be one decision written twice.

pub fn servers(&self) -> impl Iterator<Item = &str>

The servers this router can reach.

Trait Implementations

impl Debug for ToolRouter

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

Formats the value using the given formatter.

impl Default for ToolRouter

fn default() -> Self

Returns the “default value” for a type.

impl ToolClient for ToolRouter

fn destination(&self, tool: &ToolId) -> Destination

Whatever the routed transport says.

An unrouted server answers Destination::Local rather than refusing: there is no transport, so there is no destination to grant, and the call is about to fail as ToolError::Unreachable with the honest reason. Reporting an egress refusal for a server nobody wired would name the wrong problem.

fn call<'life0, 'life1, 'life2, 'life3, 'async_trait>( &'life0 self, tool: &'life1 ToolId, arguments: &'life2 Value, provenance: Option<&'life3 Provenance>, ) -> Pin<Box<dyn Future<Output = Result<Value, ToolError>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait, 'life3: 'async_trait,

Invoke a tool and return its result.