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, the number of tools behind them, and that no account is needed. 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, unmetered, and what that means todayCopy Anchor Link

There is no API key, no quota and no account. That is a deliberate choice rather than an oversight: these endpoints hold nothing and read nothing about you. You send a molecule and some parameters, and a computation comes back. Nothing is stored, nothing is associated with you, and there is nothing here that would need protecting.

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. Be reasonable, batch your work into workflow graphs rather than thousands of single calls where you can, and expect that API keys and rate limits will arrive later once usage justifies them.

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.

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.