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

[armorer-labs]

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.