Skip to main content

Tool

Trait Tool 

Source
pub trait Tool: Send + Sync {
    // Required methods
    fn definition(&self) -> &ToolDefinition;
    fn call<'a>(&'a self, args: Value, ctx: &'a CallContext) -> CallFuture<'a>;

    // Provided methods
    fn supports_pagination(&self) -> bool { ... }
    fn call_paginated<'a>(
        &'a self,
        args: Value,
        ctx: &'a CallContext,
        _cursor: Option<&'a str>,
    ) -> PaginatedCallFuture<'a> { ... }
}
Expand description

A tool. One impl Tool for MyTool per tool; registered once at startup. Tools MUST NOT panic; they return Err(ToolCallError) instead.

call returns a boxed future so the trait is dyn-compatible without requiring the async_trait macro.

Required Methods§

Source

fn definition(&self) -> &ToolDefinition

Stable borrow of the tool’s definition. Registry calls this once at registration time (for summaries/schema lookup) — implementers typically store a single ToolDefinition in the struct.

Source

fn call<'a>(&'a self, args: Value, ctx: &'a CallContext) -> CallFuture<'a>

Invoke the tool. Args are the deserialized JSON from the wire.

Provided Methods§

Source

fn supports_pagination(&self) -> bool

SP-pagination-v1 §4.4 — whether this tool’s call_paginated impl produces meaningful pages (cursors emitted on first page, cursors consumed on continuations). Default false: dispatch routes the tool through Binding::call unchanged (preserving CLI / future MCP / REST binding semantics). Tools that override call_paginated must also override this to return true.

v1 constraint: paginated tools execute through native (in-process) semantics, bypassing the Binding abstraction — pagination state doesn’t survive subprocess boundaries. CLI-backed tools that need pagination would require an out-of-band stateful protocol, deferred to a future SP.

Source

fn call_paginated<'a>( &'a self, args: Value, ctx: &'a CallContext, _cursor: Option<&'a str>, ) -> PaginatedCallFuture<'a>

SP-pagination-v1 §4.4 — paginated variant. Default impl wraps call and returns next_cursor: None, so existing tools work unchanged. Tools that want to paginate override this method AND supports_pagination.

cursor:

  • None on the initial Request::RunTool — produce page 1.
  • Some(s) on Request::RunToolContinue — the cursor’s payload has already been HMAC-verified by dispatch; the tool decodes the opaque_state (or its own scheme) to resume.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§