Session, Capability-Agent Mapping and Capability Listing

[afsalthaj]

Session management is pointed out here even if it may have been handled as part of Task 2, which is server plus handshake.

However, we need to ensure session management is properly done even if its built in. In POC we used LocalSessionManager. Whether this this enough for us in production is something to be determined. If session is derived from constructor parameters, may be we can just get away with LocalSessionManager. Please note the following assumption is true

Two separate MCP clients can/may end up talking to the same agent instance, and I don’t think AI have any issue with shared session ID. This is expected

Note that Along with Session we need to finally agent methods to tools or resources. Here is some pseudo code

#[derive(Clone)]
pub enum McpAgentCapability {
    Tool(AgentMcpTool),
    Resource(AgentMcpResource),
}



impl McpAgentCapability {
    // something like this 
    pub fn from(method: AgentMethod) -> Self {
        // Based on mapping rules
        todo!()
    }
}

// the implementation of get_capabilities is mapping explained below

Mapping Rule

• Any agent methods with 1 or more parameters are tools.
• If a method doesn’t take any parameters, it would be mostly used by clients as a resource - hence resource.
• Available prompts will be all agent methods with “prompt” annotation. i.e, we export a prompt too for an agent method while a tool corresponding to the same method is also exported
• These functions should always return something (bare minimum tools). Why? Because, this interface functionalities is invoked only during session creation which is either part of spinning up MCP server for that agent type or during the first communication to MCP server a session is created.
• This task shouldn’t do anything about transport or message handlers.The input request will hold the agent-type information most probably in the URL (yet to plan that out). This implies regardless of how we implement Task3 (Transport exposing, and transport layer, the above components will remain unchanged!
• Session doesn’t need to be persisted (just yet) because it is only about listing tools, prompts and resources. The PR shouldn’t include any persistence for the same reason.

Once we have agent-capability mapping, we can wire in the actual capability listing. Refer POC for implementation on how to integrate this with rmcp https://github.com/afsalthaj/simple-mcp-server/blob/master/src/mcp_adaptor/agent_mcp_server.rs#L34.

[afsalthaj]

This is mostly done in the integration PR. #2833

The schema and value mappings are handled separately and there are tasks for it. Basically this task was split properly (but forgot to close this one)