Back to blog
MCP servers you use in several steps: iterative mode
Integrations3 min read

MCP servers you use in several steps: iterative mode

The problem

MCP (Model Context Protocol) is an open standard for plugging external tool servers into an assistant: a GitHub account, a database, a drawing tool. In LIA, you add your own in the settings, and their tools join LIA's.

Many of these tools are simple: one search, one answer. Others are used in several steps. On a database, you first have to list the tables before querying the right one. A drawing server sometimes asks you to read its documentation before creating anything. Yet in Pipeline mode, the planner sets all the parameters before the first call. Faced with these servers, it would be reduced to guessing.

What I wanted

Each server’s form lets you choose how it is driven: use its tools directly, give it a dedicated agent in Pipeline only, or keep that agent in both modes. Direct tools suit independent calls. A dedicated agent suits a service whose documentation and results must be read before the next call. The form’s behavior summary explains the consequences for both execution modes.

How it works

You ask: “how many orders are pending in my database?”. The dedicated assistant reads the documentation the server offers, lists the tables, spots the one for orders, queries it, then reads the result. If a call fails, for example because a parameter is missing, it reads the error message and corrects its call. All of it fits within a limited number of steps and a limited time. When the budget runs out, a final pass writes up what it has already got. Its result then comes back into the main plan, and LIA writes you the answer.

  • Two models. Servers that display interactive widgets use a more capable model, the others a faster, cheaper one. The administrator sets both in the model configuration.
  • In ReAct mode, you can let LIA use the tools directly or retain the dedicated agent. Servers with interactive widgets keep their agent.

The safeguards

  • Your confirmations. Account, server and tool choices determine whether LIA asks. A dedicated agent is approved once before its task when any of its tools would ask, then completes that task. “Never ask” is your explicit standing choice for one tool; a changed declaration suspends it. A routine needs advance approval in its form for servers whose calls would otherwise stop.
  • Each tool keeps its origin. Your personal servers and the administrator's stay separate. A tool remains attached to the server and the account that offer it, and a lookalike name can't pass one server's tool off as another's.
  • A controlled connection. A personal server is reached over HTTPS, and LIA checks the destination address before connecting to it. Your credentials are encrypted before being saved.
  • A visible cost. The assistant's model calls are added to the cost of your request, counted like the rest.

When to turn it on, and its limits

Choose direct tools for independent calls, and a dedicated agent when the documentation or an earlier result determines the next call. Keeping that agent in ReAct is optional except for widget servers. It makes several model calls, costs more and cannot guarantee success; the administrator can disable dedicated agents for the instance.

Read more: Plugging your own tools into LIA with MCP; Pipeline or ReAct: two ways for LIA to handle your request.

#mcp#react-agent#iterative#sub-agent#tool-server#extensibility