GitHub user armorer-labs closed the discussion with a comment: Architecture discussion: multiple agent tool calls vs. a dedicated TexeraMCP server for exposing Texera functionality to the agent
I would avoid making the split purely "owned system = inline, third-party system = MCP." Ownership matters, but the more useful boundary is whether the capability needs to be reused, governed, audited, or executed outside one agent conversation. For Texera, I would keep the truly live working-copy operations inline at first. If the agent is doing speculative graph editing against an in-memory DAG, inline tools have a real advantage: lower latency, direct access to conversation-local state, and fewer protocol questions about who owns a draft workflow that may never be saved. The pieces I would move toward an MCP-shaped boundary are the durable or shareable ones: - dataset and operator discovery - workflow validation - execution submission - execution status, logs, and artifacts - saved workflow lookup by explicit `workflowId` / `executionId` handles That gives other MCP clients something useful without forcing the MCP server to become the owner of transient conversation state. I would also be careful with "one REST endpoint = one MCP tool." That usually mirrors the backend too closely and makes the model spend tokens rediscovering product workflow. A better split is by operational intent and audit boundary: read catalog metadata, propose or validate a workflow change, start execution, fetch execution evidence. Side-effecting tools should be especially explicit about resource handle, action class, idempotency key, and the receipt they return. On auth and governance, centralizing through `TexeraMCP` only pays off if it produces a better control point than JWT forwarding. The useful receipt is something like: which user, which agent/client, which workflow/execution handle, which tool, normalized args hash, approval/policy decision if any, and resulting artifact or execution id. If the MCP server can emit that consistently, it becomes more than an adapter layer. So my bias would be a hybrid path: keep draft graph mutation inline, expose durable read/execution surfaces through MCP, and make every state transition return handles that the agent must pass explicitly. That preserves the simple path while leaving a clean surface for IDEs, Claude Desktop/Cursor-style clients, and future policy/audit integrations. Disclosure: I work on Armorer Labs. GitHub link: https://github.com/apache/texera/discussions/5610#discussioncomment-17430970 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
