We Wrote About MCP’s Risks. Then We Built a Server.

Companies and public sector agencies already use Lemma to run workflows that mix fixed rules with AI judgment. Building one has usually required a developer, so plenty of good ideas stayed on the to-do list. With the MCP server, developers spend less time on each workflow, and other teams can build from the coding agents they already use.

Opening Lemma to coding agents also meant revisiting what we wrote about MCP last year. In Fast, Secure Integration, we looked at it from the client side and argued that one standard for tool use would make integrations simpler and faster. We were just as clear about the risks: a tool description can carry hidden instructions; an agent with broad access to internal data can leak it; and when an agent chains a dozen tool calls, it can be hard to trace why it made each call, or on whose authority.

A protocol alone can’t address those risks. MCP gives your agent a way into Lemma, and Lemma decides what the agent can do and keeps a record of what it did. We designed every tool in our server with that in mind, then tested how well agents could use them. The result is a server that lets your agent build and run workflows as you, with the same permissions you have in Lemma and nothing more.

What your agent can do

Workers are how teams build and run workflows in Lemma. Each Worker is a series of steps that can call your systems, run AI agents, and hand off to a person for review. With the MCP server, you describe the Worker you want, and your agent writes it in the format Lemma expects and checks it for errors. From there, your agent can publish the Worker, run it, and review the results.

The server exposes 35 tools. Here are the main ones, grouped by the job they do.

• Find and read Workers

  List the Workers you can see. Read the published version, the draft in progress, and past versions.

  list_workersget_workerget_worker_revisionlist_worker_revisionsget_worker_draft

• Build and change Workers

  Create a Worker, edit its draft, validate it, publish it.

  create_workercreate_worker_draftupdate_worker_draftvalidate_workflow_definitionpublish_worker_draft

• Run and monitor Workers

  Start runs, wait for them to finish, or cancel them, and read the data each step recorded. A failed run can be retried from the step where it stopped, thanks to Lemma’s durable execution.

  start_runwait_for_runget_runget_run_contextcancel_runretry_run

• Look up Functions and rules

  Search the Functions a Worker can call, look up the rules for each kind of step, and list credentials by name only. A Function lookup returns just that one operation, not an API document that can run past a million characters.

  search_functionsget_functionget_state_schemalist_credentials

• Connect Workers to data

  Connect a Worker to a data source, start a sync, and see which runs that sync started, so an agent can set Workers up, not just debug them.

  list_connectionscreate_bindingtrigger_syncquery_run_deliveries

The risks we named last year, and what we did about them

An agent that can publish Workers and start runs has real reach into production, which raises the risks we named last year and adds a few new ones. The Lemma MCP server limits that reach in two ways: the agent acts only as the person who signed in, and every action is checked and recorded.

Identity comes first, because everything else depends on it. There’s no API key to create or paste, and the server holds no credential of its own. When an agent connects, the server tells it where to sign in, using the OAuth protected-resource metadata standard (RFC 9728). You sign in through your browser, and every tool call after that carries your token to Lemma.

Built for agents, and measured

A safe server is only useful if agents can get work done with it, so we measured performance before changing anything. Our evaluation gave an agent only the MCP server and 8 Worker-building tasks, with 3 attempts at each. Each task tested different building blocks, such as routing by amount, running two branches in parallel, or calling a Function with a credential the agent had to find.

We didn’t rely on the agent’s own report of success. We checked each Worker’s definition, which lays out its steps and how they connect, and ran each published Worker on test inputs the agent had never seen.

Our first trial run of the evaluation surprised us. The agent learned how to build a Worker by reading other Workers in the account, including the one another test agent was building for the same task at the same time. Agents use anything they can reach.

For the real evaluation, we hid existing Workers. The tasks called for simple Workers of one to four steps, like a greeting or a two-way route. Without examples to copy, agents still struggled: the median build took 93 tool calls, and only half succeeded. In 7 of the 12 failed builds, the agent never worked out the basic shape of a Worker definition. It guessed instead, sending one validation call after another: 798 calls in all, 85% of them invalid. Agents even left notes asking for “an example Worker definition with a working call state.”

Providing the agents with an example was the obvious fix. The less obvious question was where to put it. Our guidance had lived in the server’s general instructions. But agents can only hold so much text at once, and some save room for the task by capping how much of any server’s instructions they read. In our testing, one agent received only part of ours. A tool’s description is different because the agent needs it to call the tool, and every agent receives it. So we put a minimal, complete, valid example Worker into the description of the tool that agents use to save a draft. And to stop the guessing, we rewrote validation errors to say how to fix the problem, not only what’s wrong.

With the example in place, every build passed, and the median build took 18 tool calls instead of 93. For customers, that means fewer tokens spent on each Worker, and agents that get it right instead of going in circles.

To check the agent was learning the format rather than copying the example, we added four tasks structured differently from it: a loop driven by a counter, a decision inside a loop, a parallel step where one branch is itself a loop of calls, and two calls where the second uses the first one’s result. All 12 attempts passed.

Setup: Claude Sonnet, 3 attempts per task, October 2026. The agent couldn’t read existing Workers, which makes the “before” numbers harsher than a real account with examples to copy.

What we learned building the Lemma MCP server

What we left out, and why

We built the server one tool at a time, and our first working version had 6 tools, not the 17 we had sketched. Every tool had to run entirely as the signed-in person, through every service it touches. That bar matters more for an agent than for a person, because someone in the console only touches what they think to reach for, while an agent can list everything it’s allowed to touch in seconds.

We also cut a tool we realized wasn’t needed. We had built one for reading a failed run’s error log, on the reasonable theory that agents debugging failures would want it. The evaluation showed agents did just as well without it, at the same cost. When a run failed, the tools they already had were enough: they could read what the run recorded at each step and trace the problem from there. A tool that doesn’t help still costs something. Its description loads into the agent’s context in every session, spending tokens before any work starts, and it’s one more option the agent has to weigh at every step.

Two things are still left out on purpose. An agent can’t ask you for a password or key in the middle of a chat. The server keeps no session state, and secrets don’t belong in a chat transcript. And only agents we’ve approved can sign in, so there’s no open registration for unknown agents to put themselves on the list.

What we built, and what’s next

The Lemma MCP server brings Worker-building into the coding agents your team already uses, so the people who know a process best can automate it without waiting on a developer. The risks we named last year shaped its design: every action is tied to a person, under the same permissions, in the same record as the rest of Lemma, so platform and security teams stay in control of production.

Support for more MCP-capable agents is in progress. What we learned building this server is already shaping our next major release, an AI assistant built directly into Lemma. Lemma customers can add the server to their agent today from the Developer Access section of Lemma’s Settings. If you’re new to Lemma, reach out to our team to see it in action.