Expand description
Handler traits for bidirectional communication in MCP client
This module provides handler traits and registration mechanisms for processing server-initiated requests. The MCP protocol is bidirectional, meaning servers can also send requests to clients for various purposes like elicitation, logging, and resource updates.
§Handler Types
- ElicitationHandler: Handle user input requests from servers
- LogHandler: Route server log messages to client logging systems
- ResourceUpdateHandler: Handle notifications when resources change
§Usage
use turbomcp_client::handlers::{ElicitationHandler, ElicitationRequest, ElicitationResponse, ElicitationAction, HandlerError};
use async_trait::async_trait;
// Implement elicitation handler
#[derive(Debug)]
struct MyElicitationHandler;
#[async_trait]
impl ElicitationHandler for MyElicitationHandler {
async fn handle_elicitation(
&self,
request: ElicitationRequest,
) -> Result<ElicitationResponse, HandlerError> {
// Display the prompt to the user
eprintln!("\n{}", request.message());
eprintln!("---");
// Access the typed schema (not serde_json::Value!)
let mut content = std::collections::HashMap::new();
for (field_name, field_def) in &request.schema().properties {
eprint!("{}: ", field_name);
let mut input = String::new();
std::io::stdin().read_line(&mut input)
.map_err(|e| HandlerError::Generic {
message: e.to_string()
})?;
let input = input.trim();
// Parse input based on field type (from typed schema!)
use turbomcp_protocol::types::PrimitiveSchemaDefinition;
let value: serde_json::Value = match field_def {
PrimitiveSchemaDefinition::Boolean { .. } => {
serde_json::json!(input == "true" || input == "yes" || input == "1")
}
PrimitiveSchemaDefinition::Number { .. } | PrimitiveSchemaDefinition::Integer { .. } => {
input.parse::<f64>()
.map(|n| serde_json::json!(n))
.unwrap_or_else(|_| serde_json::json!(input))
}
_ => serde_json::json!(input),
};
content.insert(field_name.clone(), value);
}
Ok(ElicitationResponse::accept(content))
}
}Structs§
- Cancelled
Notification - Cancellation notification
- Decline
Elicitation Handler - Default elicitation handler that declines all requests
- Elicitation
Request - Ergonomic wrapper around protocol ElicitRequest with request ID
- Elicitation
Response - Elicitation response builder
- Handler
Registry - Registry for managing client-side handlers
- Logging
Cancellation Handler - Default cancellation handler that logs cancellation notifications
- Logging
Notification - Logging notification
- Logging
Prompt List Changed Handler - Default prompt list changed handler that logs changes
- Logging
Resource List Changed Handler - Default resource list changed handler that logs changes
- Logging
Resource Update Handler - Default resource update handler that logs changes
- Logging
Tool List Changed Handler - Default tool list changed handler that logs changes
- Resource
Updated Notification - Resource updated notification
- Tracing
LogHandler - Default log handler that routes server logs to tracing
Enums§
- Elicitation
Action - Elicitation action taken by user
- Handler
Error - Errors that can occur during handler operations
Traits§
- Cancellation
Handler - Cancellation handler for processing cancellation notifications
- Elicitation
Handler - Handler for server-initiated elicitation requests
- LogHandler
- Handler for server log messages
- Prompt
List Changed Handler - Handler for prompt list changes
- Resource
List Changed Handler - Handler for resource list changes
- Resource
Update Handler - Handler for resource update notifications
- Roots
Handler - Roots handler for responding to server requests for filesystem roots
- Tool
List Changed Handler - Handler for tool list changes