Publicar un servidor MCP

ADK-Rust consume servidores MCP a través de McpToolset, pero no envuelve todas las API del SDK del lado del servidor. Los autores de servidores usan el SDK oficial de rmcp reexportado por adk_tool::mcp::rmcp para que los tipos de protocolo de cliente y servidor permanezcan alineados.

Para un crate de servidor independiente, depender directamente de la misma versión de rmcp también es apropiado:

[dependencies]
rmcp = { version = "2.2", features = ["transport-io", "schemars"] }
serde = { version = "1", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

Servidor stdio mínimo

use rmcp::{
    ServerHandler,
    handler::server::{router::tool::ToolRouter, wrapper::Parameters},
    model::{ServerCapabilities, ServerInfo},
    schemars, tool, tool_handler, tool_router,
};
use serde::Deserialize;

#[derive(Debug, Deserialize, schemars::JsonSchema)]
struct LookupInput {
    order_id: String,
}

#[derive(Debug, Clone)]
struct OrderServer {
    tool_router: ToolRouter<Self>,
}

#[tool_router]
impl OrderServer {
    #[tool(description = "Read one order by its public order ID")]
    async fn read_order(
        &self,
        Parameters(input): Parameters<LookupInput>,
    ) -> String {
        format!("Order {} is ready for investigation", input.order_id)
    }
}

#[tool_handler]
impl ServerHandler for OrderServer {
    fn get_info(&self) -> ServerInfo {
        ServerInfo::new(ServerCapabilities::builder().enable_tools().build())
            .with_instructions("Read-only order investigation tools")
    }
}

let service = rmcp::ServiceExt::serve(
    OrderServer { tool_router: OrderServer::tool_router() },
    rmcp::transport::io::stdio(),
).await?;
service.waiting().await?;

El fixture determinista examples/mcp_manager utiliza esta forma de servidor y es compilado y ejecutado por las puertas de verificación MCP.

Publicar capacidades honestas

Solo anuncia una capacidad cuando el manejador la implementa. Un cliente usa la respuesta de inicialización para decidir si puede llamar a recursos, prompts, completado, elicitación, suscripciones o tareas.

Para herramientas capaces de tareas, declara el soporte de tareas de la herramienta y anuncia tasks.requests.tools.call. El cliente puede rechazar una herramienta de tarea requerida cuando el servidor no negoció el soporte de tareas.

Las herramientas son límites de seguridad

Las descripciones y el esquema JSON ayudan al modelo a formar una llamada; no son validación de entrada ni autorización. Un servidor debe:

• validar cada entrada independientemente del modelo;
• resolver la identidad y el alcance del inquilino en el límite del servidor;
• autorizar la acción y el recurso específicos;
• separar las operaciones de lectura de las escrituras consecuentes;
• evitar devolver secretos o datos ilimitados;
• hacer explícitas las reintentos y la idempotencia para los efectos secundarios; y
• registrar suficiente evidencia para explicar el resultado.

Elegir un transporte

Utilice stdio cuando el cliente sea propietario del proceso hijo local. Utilice Streamable HTTP cuando el servidor sea un servicio implementado de forma independiente. Las implementaciones remotas también necesitan autenticación, límites de solicitudes, política de sesión, observabilidad y una sonda de salud a nivel de aplicación.

Consulte la documentación oficial de rmcp para enrutadores de servidor, recursos, prompts, manejadores personalizados, transportes, autorización y APIs de extensión.