GitHub user aicam created a discussion: Architecture discussion: multiple agent tool calls vs. a dedicated TexeraMCP server for exposing Texera functionality to the agent
## Background Texera's `agent-service` lets an LLM agent operate Texera on the user's behalf — building/editing workflows, discovering datasets, and executing operators. Today these capabilities are exposed as **inline function-calling tools** defined inside the agent-service, plus a growing set of **remote MCP tools** (BioMCP). As we add more capabilities, we should decide deliberately: do we keep growing the inline tool set, or do we factor Texera's own actions into a dedicated **`TexeraMCP` server**? This discussion lays out the current implementation and the tradeoffs so the community can weigh in. ## Current implementation `agent-service` (TypeScript / Bun, Elysia HTTP server) drives an agent loop via the Vercel AI SDK (`generateText`, temperature 0.2, bounded ReAct steps). Tools are registered in `createTools()` and dispatched automatically by the SDK. The tool set today: **Operator metadata** - `list_operator_types` — list available operator types - `get_operator_definition` — schema for a given operator type **Workflow CRUD (in-memory DAG)** - `addOperator`, `modifyOperator`, `deleteOperator` **Execution** - `executeOperator` — compile the logical plan (workflow-compiling-service) → run on a computing unit (workflow-execution-service) → return results **Dataset discovery** - `listDatasets`, `listDatasetVersions`, `listDatasetFiles` (file-service) **Remote MCP tools (already in use)** - BioMCP server (`bio-mcp-service/`) exposes ~11 biomedical tools (PubMed, variant/gene lookup, UniProt, etc.) over Streamable HTTP, registered dynamically into the same tool namespace via `@modelcontextprotocol/sdk`. So the codebase is already **hybrid**: inline function-calling tools for Texera's own actions, plus an MCP client for external/shared capabilities. The open question is whether Texera's *own* actions (datasets, workflow CRUD, execution, metadata) should also move behind an MCP server (`TexeraMCP`). Under the hood, every inline tool ultimately calls a Texera backend REST endpoint (dashboard-service, file-service, workflow-compiling-service, workflow-execution-service). The agent-service is effectively an LLM-facing adapter over those REST APIs. ## The two options ### Option A — Keep inline function-calling tools Tools defined in agent-service, dispatched in-process by the AI SDK. - **Pros:** lowest latency (no extra network/process hop); simplest to prototype and iterate; tools can share in-memory state (e.g. the working-copy DAG in `WorkflowState`) and the user's request context directly; no extra service to deploy/operate. - **Cons:** tools are coupled to the agent-service and the SDK's tool format; not reusable by other clients (IDE plugins, other agents, third parties); every tool schema is sent on every request, so prompt size grows with tool count; no natural choke point for auth / rate-limiting / audit of agent actions. ### Option B — Dedicated `TexeraMCP` server Factor Texera's actions (datasets, workflow CRUD, execution, operator metadata) into a standalone MCP server, consumed by agent-service the same way BioMCP already is. - **Pros:** provider-agnostic and reusable — any MCP-compatible client (Claude Desktop, IDEs, other agents) could drive Texera; clean governance choke point (auth, rate limiting, audit: "which agent called which tool with what args, when"); decouples capability evolution from the agent loop; consistent with the BioMCP pattern already in the repo; tools can be loaded on demand rather than all schemas every request. - **Cons:** extra network/process hop (latency); harder to share in-process agent state like the live DAG — execution/CRUD tools currently rely on mutating an in-memory `WorkflowState`, which an out-of-process MCP server can't touch without an explicit session/state protocol; another service to deploy, version, and secure; statefulness (per-user JWT, per-session workflow) is awkward over a stateless tool protocol. ## Key questions / discussion points 1. **Statefulness.** The workflow CRUD + execution tools mutate an in-memory working-copy DAG per agent session. MCP tools are designed to be stateless request/response. How would a `TexeraMCP` server own or reference that session state — pass the full DAG each call, hold server-side sessions, or keep CRUD inline and only externalize stateless read tools (dataset/metadata discovery)? 2. **Granularity.** Is "one tool per REST endpoint" the right design, or should `TexeraMCP` expose coarser, intent-level operations (e.g. "find a dataset and wire it into the workflow") that reduce round trips and token usage? 3. **Reuse value.** Is there real demand for non-agent-service clients to drive Texera over MCP (e.g. users in Claude Desktop / Cursor)? That's the strongest argument for Option B; if not, the extra hop may not pay for itself. 4. **Hybrid split.** A pragmatic middle ground: keep stateful, latency-sensitive tools (workflow CRUD, execution) inline, and move stateless, shareable read tools (dataset discovery, operator metadata) — plus external integrations like BioMCP — behind MCP. Where should the line be? 5. **Auth & governance.** Today each tool forwards the user's JWT to backend REST. Does centralizing through `TexeraMCP` improve auditability / security enough to justify it? 6. **Token / scaling cost.** As the tool count grows, do we hit prompt-bloat from always-on inline schemas, and does MCP's on-demand loading meaningfully help? ## A note from the literature Industry guidance is converging on **"use both"**: inline function calling for app-specific, stateful, latency-sensitive tools; MCP for shared, reusable, or externally-consumed capabilities — graduating a tool to MCP once it proves valuable to multiple clients. Texera is already on this path (inline Texera tools + remote BioMCP). The question is where to draw the line for Texera's *own* actions. We'd love input — especially on the statefulness problem (#1) and whether there's genuine demand for external MCP clients (#3). GitHub link: https://github.com/apache/texera/discussions/5610 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
