What shipped, and what it does not do.

An MCP server is already a typed tool catalogue, which is most of what the build agent otherwise reconstructs by hand from an API reference. What it does not carry is the part this platform gates on. MCP gives a tool a name, a description and an input schema. It supplies no effect, no risk tier and no reversal — the three properties the promotion gate and the policy dispatcher need before a call is allowed to leave the platform.

What it offers instead is optional annotations, readOnlyHint and destructiveHint among them, and the MCP specification itself says a client must not rely on those for security decisions, because the server supplies them. So Boundlane classifies and the server does not. Every MCP tool starts as a write at high risk, which means it is simulated in shadow and does not execute at any stage that forbids high-risk writes. The server’s own annotations are recorded verbatim next to the classification, as an unverified claim a reviewer reads rather than as an input to the decision. An automation may narrow that by declaring an effect and a risk in its own package, and the gate refuses a bound MCP tool that nobody classified. Silence never means read.

Drift is the other half. An MCP server may change its tool list whenever it likes and merely send a notification, and a connector must not change underneath an automation that was already promoted on evidence. So the binding pins a digest over the tool names and their input schemas. The runtime refuses a mismatch before it dispatches anything, and the promotion gate refuses one computed from the server’s live list. Descriptions sit outside the pin deliberately: they are third-party prose that never reaches a decision, and pinning them would make a copy edit look like an attack.

Two limits, stated rather than discovered. Remote Streamable HTTP only — a stdio server means running a tenant-controlled subprocess on shared infrastructure, which is a different product. And there is no MCP SDK in the dependency tree: the client is JSON-RPC over the same guarded fetch every other connector uses, because a library carrying its own fetch would go around the egress allowlist. Like every connector here, it is tested against realistic responses and has not yet met a live third-party server.

Boundlane AG is the contracting entity for the hosted service. The package scope, the environment variables, the build agent’s own prompts and the documentation were renamed together with the product surface, so there is one name in the code and the same name on the page.

Three surfaces over one versioned package. Boundlane Studio builds an automation and proves it. Boundlane Control runs it under policy. Boundlane Exchange is where a published one is found and installed. The package that passes the gate is the package that executes — pinned by hash, and refused at runtime if the bytes changed.

Nothing about the product changed with the name: the same package contract, the same policy dispatcher, the same hash-chained audit. A rename is a convenient moment to claim a new capability alongside it. This is not that.

The platform ships thirteen connectors. A company’s process always also runs through something else: a warehouse system written in 2009, an internal approvals service, a regional bank portal, a vertical SaaS with four hundred customers. An automation that stops at the edge of the systems we happened to build hands off to a person, and that handoff is the thing the product exists to remove.

The obvious answer is to generate a request builder, and it is the wrong one. Generated code is bytes nobody audited running against a live system, and every promise made about connectors — the egress allowlist applies, credentials come from the vault, a write declares its risk and its reversal — becomes a property of whatever the model wrote that afternoon. A declaration is data instead. It passes through the same validator that checks the first-party catalogue, the same guarded fetch, the same policy dispatcher and the same promotion gate, because the same driver executes it.

Four things follow, and they are the whole reason to do it this way. It cannot choose what it may reach: the base URL’s host must be on the binding’s egress allowlist. It cannot carry a credential: the reference is a vault pointer and never a literal. It cannot declare a write without stating that write’s risk and its reversal, and it cannot declare anything that moves money, because the forbidden verbs are checked here too. And it cannot change under an already-promoted automation: the binding records the definition version it was promoted against, and the gate refuses one that does not match.

Two decisions inside the authoring loop are worth arguing with rather than skimming. A probe is a GET and never a POST — there is no phrasing of “just testing” that undoes an exploratory call which created a record in a customer’s production system. And a probe response is redacted before it reaches the model, because the first thing an unknown API returns is usually a page of real customer records, and the agent needs the field names and the value shapes, not the third customer’s email address.

An automation that reads an ERP and writes a ledger still stops short of the work. A purchase request is approved in ServiceNow, an exception becomes a Jira issue, the customer hears about it through Zendesk, and the commercial terms sit in a CRM that is not always Salesforce. Boundlane connects Salesforce, Oracle Fusion, NetSuite, QuickBooks, SAP, Snowflake, ServiceNow, Jira, Zendesk and HubSpot, with generic REST, GraphQL and SQL for whatever else a process touches.

The more useful half is the action catalogue. A connector that dispatches get, query, create and update against an object can read a schema and write a record, and it cannot reach a single operation an enterprise process is actually about: submit an invoice for approval, post a journal, release a hold, assign a ticket, close a case. Without those the build agent works around them by setting a status field and hoping the far system treats that as the verb — which skips the vendor’s approval routing, its ledger entry, its notification and its own audit record, and looks like it worked.

So the verbs are declared. 58 of them, each carrying the request that performs it and the risk tier the policy dispatcher gates on. Every one is a write — reading is what a schema is for, and a verb is the thing that changes something. A verb nobody can dispatch cannot be added to the file, which is what keeps a catalogue from turning into a wish list.

Most of them cannot be automatically reversed, and the honest form of that is an empty field rather than a reversal that does not work. One is listed only where the vendor has an absolute inverse needing nothing the original call did not already carry: assign and unassign, hold and release, solve and reopen. Setting a priority has none, because undoing it needs the value that was there before and the platform does not record one — a reversal that set the same value again and reported success would be worse than admitting there is none. The promotion gate then refuses an irreversible write inside a package that asked for reversible ones, which is the gate doing its job rather than a limitation.

Every entry says where it came from. Documented means published vendor documentation and nothing more: no account has confirmed it, and every catalogue hit the build agent receives carries that on its face. First contact with a real tenant instance will find discrepancies. The platform says so in advance rather than letting an operator find out during a run.

Shadow mode answers “what would this do” honestly and at the speed of the business: put the automation beside the real process, wait a fortnight, read the runs. That is the right mechanism and it is why nothing here reaches production on day one. But it only answers forward. The cases that would settle the argument fastest are already sitting in the run history, each with its exact payload and its exact tool responses attached.

A backtest is that history replayed. Every past run becomes a scenario, the candidate version executes against it using the responses recorded at the time, and the report lists in full every case where the candidate reached a different outcome than the run actually did. Nothing leaves the platform while it runs: the tool responses come from the recording rather than from the system, so no write executes.

It emits no score. “Ninety-four per cent agreement” invites promoting on a number, and the six per cent is the entire content — a version that agrees with history everywhere is either correct or has learned to reproduce the same mistake, and only the disagreements tell those apart. So the report leads with the disagreements, lists every case it could not replay together with the reason it could not, and names the versions the history came from, because more than one means the baseline being compared against is not a single behaviour.

And it does not replace shadow. A replay cannot discover that the upstream system now answers differently, and it cannot observe a case that has never happened. That limit travels inside the report as data rather than sitting in documentation, so no surface can render a backtest without it.