GitHub user sshiv012 added a comment to the discussion: Architecture discussion: multiple agent tool calls vs. a dedicated TexeraMCP server for exposing Texera functionality to the agent
Hello new to the discussions here, I’d be cautious with server-side MCP sessions. SEP-2567 removes Mcp-Session-Id and pushes MCP toward explicit handles returned by tools and passed back as arguments. For Texera, that maps naturally: workflows already live in the backend under workflowId, so tools can take workflowId/computingUnitId handles instead of relying on MCP session state. The MCP server should expose those handles clearly, while the agent or AI consumer layer should be responsible for threading them through subsequent calls. This is similar to the pattern we are using in AsterixDB (MCP) async query API: return a handle, let the client use it later, and keep the protocol layer stateless so follow-up requests don’t depend on sticky routing or a shared session store. One nuance I’d add is that we should separate workflow state from conversation state. Texera should remain the source of truth for durable workflow/execution state through handles like workflowId, computingUnitId, and possibly executionId; the agent/client layer should be responsible for remembering and passing those handles through later calls. That keeps the MCP server (if we decide to go this direction) stateless without making the agent’s context implicit or hidden. GitHub link: https://github.com/apache/texera/discussions/5610#discussioncomment-17257136 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
