MCP

Point an AI assistant at the workbench's tools and let it run them.

What it doesCopy Anchor Link

The Model Context Protocol is how an AI assistant is given tools it can actually run. Pointing a client at /mcp hands the model the workbench's whole catalogue: it can compute a melting temperature, find restriction sites, design primers, digest a plasmid or check an assembly, and read the real result back, instead of estimating an answer from memory.

The tools it gets are the tools the workbench has. There is no separate, simplified set for models, and no tool that exists only here: the same declarations generate the panels, the workflow builder, the HTTP endpoints and this.

Why an engine, and not a model's memoryCopy Anchor Link

A model with a terminal can run code, but it still answers a scientific question from what it remembers unless something it calls is correct by construction. That is the difference this server makes: the model does the reasoning, the engine does the science.

Every tool that computes is checked against the reference implementation of its field, on that implementation's own data, before it ships. Its result says how it was reached: the method and the inputs it used. The tools that look things up instead (sequence databases, literature) say which authority answered. So an assistant can tell you why a number is what it is, and you can check it without trusting the assistant.

The cheapest way to see it is a case where a plausible answer is wrong. Ask for EcoRI sites on the circular sequence AATTCTTAGGATCCG: the only site spans the point where the circle closes, so an answer that reads the sequence as a straight line finds none. The tool finds it, and with circular: false it correctly finds nothing. Ask for an enzyme that does not exist and it refuses by name, rather than returning an empty list that reads as "no sites".

ConnectingCopy Anchor Link

Most clients take a URL. Give them:

https://<host>/mcp

/api/mcp is the same server and keeps working, so a client already configured with it needs no change. /mcp is simply the address to hand someone new.

No key, no header, no account. The server is stateless, so a client can reconnect freely and nothing is carried between calls except what the model sends.

Each tool arrives with its full input schema, so the model sees every parameter, its bounds and units, and the published options a parameter selects between with what each one is. That is what lets a model choose the SantaLucia 2004 table over Breslauer 1986 deliberately, rather than guessing at a parameter name.

Filling in a connector dialog, field by fieldCopy Anchor Link

Most dialogs ask for more fields than this server needs. Every one of them but the URL is left empty:

For a client that is configured by file rather than by dialog, the whole entry is two lines:

{
  "mcpServers": {
    "jane": {
      "type": "http",
      "url": "https://<host>/mcp"
    }
  }
}

Some clients spell the same two lines "transport": "http", and some take the URL alone. Nothing else belongs in the entry: no headers, no env, no command.

If your client can only run a local command and cannot take a URL, it needs a stdio-to-HTTP bridge of its own; this server offers no local process to launch, and configuring one as though it did is the most common way a working endpoint ends up looking broken.

Checking the address before you fill anything inCopy Anchor Link

Open the URL in a browser, or run:

curl -s https://<host>/mcp

A working endpoint answers with the JSON card below. "authentication": "none" is the server stating, in its own words, that there is nothing to authenticate:

curl -sS https://<host>/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

That is the exact request a client makes. If it returns a tool listing, the address is right and any remaining trouble is in the client's settings, not the server.

What the failures look like, and which is which:

Connecting from ClaudeCopy Anchor Link

In Claude, open Settings → Connectors → Add custom connector, and give it your deployment's address with /mcp on the end:

https://<your-domain>/mcp

There is no key, no header and no OAuth step. If the connector asks for authentication, leave it empty.

If the setup step cannot detect the server, configure it manually as no-auth — the endpoint is fine. A client checking the address may report something like "set up as not requiring sign-in, but the server asked for sign-in when checked (status 405)". That 405 is not a sign-in demand. The Model Context Protocol lets a server decline to open a server-initiated event stream, and declining is answered with 405; this server has nothing to push, so a client that asks for that stream gets exactly that, while the POST a client actually speaks over answers normally. The refusal now says so in its own body, and the addresses a client checks for sign-in requirements (/.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server) answer that nothing here authenticates. Continue past the detection step and finish the connector by hand.

The quickest way to check the address before you connect: open it in a browser. A working endpoint answers a plain visit with a short JSON card describing itself — the transport, the fact that it wants no authentication, the narrowed addresses below, and the exact request that lists the tools:

{
  "server": "jane-engine",
  "protocol": "Model Context Protocol",
  "transport": "streamable-http",
  "endpoint": "https://<your-domain>/mcp",
  "authentication": "none",
  "scienceTools": 172,
  "call": { "method": "POST", "body": { "jsonrpc": "2.0", "id": 1, "method": "tools/list" } }
}

If instead you get the app's own interface, a not found, or a sign-in screen, the address is wrong or that deployment does not carry the API yet — which is a different problem from authentication, and no connector setting fixes it.

The card is for people and for probes; it is not part of the protocol. A real client opening the event stream still gets the 405 the specification asks for, because it says so in its request.

A first task to check it works. Once connected, ask Claude:

Using the melting temperature tool, what is the Tm of the primer GTAAAACGACGGCCAGT under the unified 2004 nearest-neighbour model, and again with 5% DMSO using the Cullen and Bick coefficient? Show me the per-step derivation.

You should get 57.883 °C and 55.383 °C, with a DMSO step of −2.5 °C attributed to Cullen and Bick (1976). If those are the numbers, the connector is wired to the real engine and not to the model's recollection.

A second one, to see a refusal work:

Find the BamHI sites in ATGGGATCCAAA, and then try again with an enzyme called NotAnEnzyme.

The first returns one site; the second is refused by name rather than answered with an empty list.

Narrowing the catalogue, and why you probably shouldCopy Anchor Link

A model shown a hundred plausible tools picks a plausible one. Handing over the entire catalogue costs both accuracy and prompt space, so the same server is offered pre-narrowed:

https://<host>/mcp/cloning

Two kinds of scope are available, and they answer different questions.

By capability, which is what a tool is:

By deliverable, which is what a job needs. These are derived by following the connections between tools out from the job, so a task spanning three capabilities comes back whole:

Narrowing is opt-in. An unscoped client still gets every tool, and no scope is applied by default.

An unknown scope is refused, never quietly widened. Asking for a scope that does not exist returns an error rather than the full catalogue, because a client that believes it narrowed and did not is worse off than one told it was wrong.

What a model gets backCopy Anchor Link

The same JSON the HTTP API returns, as structured tool output. That matters more for a model than for a person: a result that carries its model name, its per-step derivation and its citations lets an assistant tell you how a number was reached, and a refusal that names its reason lets it correct itself instead of inventing a plausible number.

Figures arrive as pictures. A tool that draws (a plasmid map, a gel, a phylogenetic tree, an alignment block, a Sanger chromatogram) returns its figure twice: as a lossless SVG and as a PNG, so a client that does not render SVG still shows the PNG. The same goes for plots: a hydropathy or membrane profile, a GC window, a FoldIndex disorder profile, a melt curve and its HRM trace, a predicted amplification curve, a lineages-through-time curve, per-base Sanger quality, and the heatmaps of a distance matrix, a primer cross-dimer ΔG grid and a codon-usage chart. The model is shown the picture once; the SVG is for you.

And in a client that supports MCP Apps, the result opens as a view inside the chat. At the extension's launch those were Claude, ChatGPT, VS Code Insiders and Goose. The figure comes first, then a sortable table for every list of rows (cut sites, primers, guides, hits), then the readouts. A figure can be shown at actual size and downloaded as SVG. The view shows the same result the model reads, and a client without MCP Apps simply gets the text.

A molecule can be named rather than pasted. _subject takes an archive accession, a bundled sample or a file, exactly as the HTTP API does (see Naming a record instead of pasting it on the HTTP page), so an assistant can say "the pEGFP-N1 sample" or "U55762" and the record arrives with its annotations and topology.

Limits worth knowingCopy Anchor Link

• It computes, it does not remember. These tools hold no project and no history. A model can melt an oligo or digest a sequence you give it; it cannot open your saved work.
• Sequences you send leave your machine. The workbench computes locally in your browser; this is a server. For unpublished constructs, prefer the editor.
• Free and unmetered today, and shared. No key and no quota, but finite capacity. API keys and rate limits will arrive later.