[FEATURE] Simplify `Tool` by Adopting `rig-core`/`mcp-core` Implementations

[takasaki404]

🐛 Problem

Our current [Tool] type has grown unwieldy: implementing it requires manually defining the parameters schema, and implementing async tool calls require nesting multiple move blocks. This complexity makes it hard to onboard new contributors and leads to subtle inconsistencies across tools.

💡 Proposed Solution

Replace our homemade Tool definition with the Tool implementations provided by either:

• [rig-core] – an ergonomics-focused Rust library for building LLM applications ([Crates][1])
• [mcp-core] – the core types/traits crate used by Rig, already listed as an optional dependency in Cargo.toml ([Docs.rs][2])

By re-exporting their #[tool] macro and supporting types, we can eliminate most of our custom boilerplate while benefiting from a well-maintained, documented implementation ([Docs.rs][3]).

🔍 Considerations

• Dependency weight: rig-core brings in crates like reqwest, serde, and optional features for vector stores. If these prove too large or pull in native dependencies, it could break WASM targets.
• WASM compatibility: Validate that neither crate’s default feature set pulls in unsupported code (e.g., threads, file I/O). If they do, we may need to maintain a slim fallback implementation within our repo.

📝 Example Usage

#[tool(
    name = "Add",
    description = "Adds two numbers together.",
    params(a = "The first number to add", b = "The second number to add"),
    annotations(
        title = "Add",
        readOnlyHint = false,
        destructiveHint = false,
        idempotentHint = false,
        openWorldHint = false
    )
)]
async fn add_tool(a: f64, b: f64) -> Result<ToolResponseContent> {
    Ok(tool_text_content!((a + b).to_string()))
}

By swapping out our ToolBuilder for rig-core’s (or mcp-core’s) #[tool] macro, we gain:

• Built-in parameter validation
• Automatic JSON schema generation
• Uniform annotation handling