Architecture discussion: multiple agent tool calls vs. a dedicated TexeraMCP server for exposing Texera functionality to the agent

[aicam]

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?

[aicam]

My take: inline tools should be the default for Texera-native actions; MCP is for third-party systems.

MCP earns its overhead when you integrate a system you don't own — e.g. a stock-market feed in a finance app — where you consume someone else's server instead of writing tools yourself. But our agent tools are thin adapters over our own REST endpoints. Putting an MCP boundary between our agent and our own API just adds a hop and a service to maintain, with no ownership line to justify it.

Proposal: make the endpoints themselves agent-ready, so adding a tool is zero extra effort. Instead of hand-writing a tool wrapper in agent-service per endpoint, annotate the endpoint with the metadata an agent needs (description + which params matter), and auto-register it as a tool.

// 1) Endpoint declares its agent metadata next to the JAX-RS annotations.
@AgentTool(
  name        = "list_datasets",
  description = "List datasets the current user can access. Use before wiring data into a workflow."
)
@GET @Path("/list")
@Produces(Array(MediaType.APPLICATION_JSON))
def listDatasets(
  @AgentParam("Filter by visibility: all | public | private", required = false)
  @QueryParam("visibility") visibility: String = "all",
  @Auth user: SessionUser          // injected context — NOT exposed to the agent
): List[DashboardDataset]

A registry scans these at startup and serves a manifest at GET /api/agent-tools; agent-service turns each entry into a tool with one generic adapter:

// 2) One adapter registers every annotated endpoint — no per-tool file.
for (const t of await fetchAgentToolManifest()) {
  tools[t.name] = tool({
    description: t.description,
    inputSchema: jsonSchema(t.inputSchema),
    execute: (args, { abortSignal }) =>
      callBackend(t.http, args, { token: userToken, abortSignal }),
  });
}

Net effect: a new agent capability = an endpoint + two annotations. No new TS file, no hand-synced schema, descriptions live with the code, and auth/context params are filtered out automatically.

(Sketch to frame the idea, not a finished design — open to iterating on the annotation surface and how read-only vs. side-effecting tools get gated.)
@bobbai00 what you think?

[sshiv012]

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.

[chenlica]

@aicam To help the discussion, please add related visual diagrams.

[aicam]

@bobbai00 what is your idea?

[chenlica]

@bobbai00 Please chime in.

[bobbai00]

After looking into this topic, I support @aicam 's proposal of "inline tools should be the default for Texera-native actions; MCP is for third-party systems." for its simplicity on the software architecture and code implementation. MCP indeed serves as a different purpose