API & MCP

Every tool in the workbench, callable over HTTP or spoken as MCP, with no editor involved.

Opening /api in a browser is the quickest way to tell a working deployment from a wrong address. It returns the doors by name and the number of tools behind them. If you get the workbench's own interface or a not found instead, the host you are asking does not carry the API.

What this isCopy Anchor Link

The workbench is a user interface over a set of scientific engines. Those engines do not need the interface: the same restriction digest, the same melting-temperature model, the same primer design that a panel runs is reachable as an ordinary HTTP call, and as a Model Context Protocol endpoint that an AI assistant can be pointed at directly.

There is no reduced "API version" of a tool. A panel and an API call reach the same computation through the same parameters and return the same numbers, because there is only one declaration of each tool and every surface is generated from it. If a knob exists in a panel, it has a name you can send; if a result appears in a panel, it appears in the JSON.

The three doorsCopy Anchor Link

• One tool at a time. POST /api/tools/<name> runs a single operation and returns its result. This is the door most callers want. See The HTTP API.
• A whole graph. POST /api/workflows/run runs several tools wired together, including conditional steps and for-each loops, in one request. A pipeline that would be several round trips is one call. See Workflows over HTTP.
• Model Context Protocol. POST /api/mcp exposes the same catalogue to an AI assistant, so a model can run a digest or design a primer as a tool call. See MCP.

All three read the same catalogue. A tool is not written three times.

Free, and what that means todayCopy Anchor Link

There is no price and no quota. The lab is invitation only, so running a tool takes a personal key: open /connect, sign in with Google or enter the invitation code the page shows, and make one. Send it as Authorization: Bearer bi_…, or as ?key=bi_… on the address. Listing what exists needs no key. The lab counts accounts and calls, never what you send: you send a molecule and some parameters, a computation comes back, and neither is stored.

What it does mean is that capacity is finite and shared. The service is limited by what one server can compute, so heavy or automated use may be slow at busy times. One address may make 120 calls a minute across the tool, workflow and MCP doors; the next call is answered 429 with a Retry-After header saying how many seconds to wait, and nothing you sent before it is lost. A workflow graph counts as one call however many steps it runs, so batching is the way to do more. Each archive accession a call names counts as one more, since each is a fetch from that archive. One tool call may run for 60 seconds. A call still computing then is stopped and answered 422 with the reason; a shorter sequence or a narrower region usually fits, and the workbench, which computes in your browser, has no such limit.

Your data leaves your machine when you call this. The workbench itself is local-first and computes in your browser; the API is a server, so a sequence you send is a sequence you have sent. For unpublished constructs, the editor is the private option.

Conventions that apply everywhereCopy Anchor Link

• JSON in, JSON out. Send content-type: application/json.
• The molecule is _subject. Tools that act on a sequence take it in a _subject object rather than as a loose parameter, so the same body shape works for every tool.
• Every result says which model produced it. Where a computation has alternatives (melting models, confidence intervals, dot-plot algorithms), the answer names the one used and cites the paper it comes from. A number without its model is not a result.
• A refusal is a result too. An input a tool cannot compute on comes back as a stated reason, never as a silent zero or an empty list.

Versions and breaking changesCopy Anchor Link

The API carries one version number, reported by /api, by the reference at /api/openapi and by the MCP handshake. What you code against is each tool's name, the names, types and allowed values of its parameters, which parameters are required, and the names and types of its outputs. Within one major version none of that is taken away: a tool, parameter or output is not removed or renamed, a type does not change, an allowed value is not withdrawn and an optional parameter does not become required. New tools, new optional parameters, new allowed values and new outputs can arrive at any time, so read results by name and ignore keys you do not know. A change that would break a caller ships only as a new major version, and every release is checked against the published contract before it merges. Descriptions and the wording of explanations are not part of the contract and may improve within a version. Neither are defaults: send a value explicitly when your result must not move with one.

Trying it without writing any codeCopy Anchor Link

Open /api/openapi in a browser. It is a full interactive reference, generated from the same tool declarations the workbench uses: every endpoint, every parameter with its bounds and units, every published option with its citation, and a form that sends a real request and shows you the real response. It is the fastest way to see what a tool accepts before you write a line against it.

The raw specification is at /api/openapi/json if you would rather generate a client from it.