The open engine.
And every surface that reaches it.

Product portfolio for NovoMCP — the open computational chemistry engine, open-sourced July 2026 under Apache-2.0 and shipped through v1.4.0. Clone it and it boots with zero external services — no auth, no account, no API key. One engine (MCP + REST, 68 tools), one 11-stage discovery funnel, and the surfaces that reach it: chat, code, desktop, browser, editor, and the bundled dashboard that ships with the engine itself. Each case below is a product decision: where it lives, who it's for, what trade-off it pays. The problem, the call, the build, the outcome.

Apache-2.0 license 68 tools in the engine 0 external services to boot 11 autonomous funnel stages 1 engine underneath
Every surface is a door into the same engine, not a separate product. Start in Claude, continue in the browser, batch from the API, keep an eye on it from the bundled dashboard — one engine underneath, whichever door you use.
01 · MCP connector · AI assistants

Novo & Novo Compute. The chat surface.

Live

Add Novo to Claude, ChatGPT, Gemini, or Cursor and run the full discovery funnel in chat, with human-in-the-loop confirmation at each stage.

The Problem

Chemists already live in Claude and ChatGPT. Asking them to leave their assistant for a separate product is adoption death. But "an MCP server" is also not a product, it's a protocol. The product call is what you ship through it.

The Decision

Two MCP servers, not one. Novo exposes core tools and is available on every tier including the free preview; Novo Compute exposes paid GPU/quantum tools and is paid-only. Different API key prefixes (nmcp_ vs ncmcp_) so a leaked core key cannot burn GPU budget.

Same Docker image, one env flag (NOVO_SERVER_MODE) toggles the tool catalog, zero duplicated code, separate governance surface.

The Build

FastAPI MCP server, OAuth + RFC 8693 token exchange (separate novomcp-auth service), Redis-cached key validation with 5-min TTL and an in-memory fallback so dashboard outages don't take MCP down.

Funnel stages use MCP elicitation so the assistant prompts the user at each gate, never silent autonomy on someone else's compounds.

The Outcome

Live on Claude AI, Claude Code, Cursor, ChatGPT (Plus / Pro / Business), and Gemini. 68 tools exposed across the two-server split, ADMET, docking, MD, QM, structure prediction, materials, plus the hosted FAVES certified compliance API for regulated pipelines.

Self-hosted engines expose MCP at http://localhost:8018/mcp by default; cloud deployments run on a per-org subdomain (e.g. yourorg.novomcp.com).

Proof · Production MCP at scale
An MCP server is easy. Running one in production, across every major client, is the actual work.

A lot of teams now ship "an MCP server." What's been harder, and what NovoMCP runs daily: a two-server governance model on Anthropic's protocol with OAuth 2.1 + RFC 8693 token exchange for the paid tier, scoped Bearer keys with Redis-cached validation (5-minute TTL plus an in-memory fallback so the dashboard going down doesn't take MCP down with it), MCP elicitation driving a 11-stage human-in-the-loop funnel, and a separate identity service (novomcp-auth) that issues the exchange tokens.

Live across every major MCP client: Claude AI (web + desktop), Claude Code, Cursor, ChatGPT (Plus / Pro / Business), Gemini. One backend, one tool catalog, one billing path behind all of them.

2MCP servers, scoped
68tools served
5+clients in production
Apache-2.0license underneath
Live → The engine (product page) Novo Compute Repo
02 · REST API · your own code

api.novomcp.com. Bring your own model.

Live

Call any of the 68 tools from your own code, or wire them into your own agent. Single REST surface, OpenAPI 3.1 as source of truth.

The Problem

Some teams already have their own AI agent, their own automation, their own pipeline. They don't want OAuth flows, they don't want MCP, they want a Bearer key and a JSON body.

The Decision

One endpoint shape, not 69 of them. Every tool is POST /v1/tools/{name} with a Bearer key, no bespoke per-tool routes to design, document, or version. The tool catalog is the OpenAPI 3.1 spec, served live; there are no separate docs to drift.

Same backend (quanta-mcp) serves MCP and REST, zero code duplicated for the second surface.

The Build

FastAPI proxy at api.novomcp.com, OpenAPI 3.1 generated from the tool registry, Bearer-key auth shared with MCP (same key validates either surface). Rate limits and credit accounting share the same Aurora-backed billing path.

The Outcome

Live. Engineers who don't want to talk to a chat assistant can curl their way to ADMET in one command. The OpenAPI spec also feeds custom GPTs, agent frameworks, and Postman collections, same engine, no maintenance.

Live → API overview API docs
03 · Workstation · NovoWorkbench

The workbench. On your machine.

Design-partner preview

The molecule canvas, 3D viewers, and discovery funnel as a native desktop for macOS and Windows. Local RDKit, offline alert screening, bring-your-own-LLM chat. Currently in design-partner preview; ships as OSS in v1.5.x.

The Problem

Plenty of researchers don't have API skills, don't use Claude, and don't want a chat to do their job. They want an app. Some live in regulated/offline environments where local-first is non-negotiable. The chat surface + REST surface don't reach them.

The Decision

Ship the engine as a native desktop workbench, not a browser SPA behind a dashboard. Local RDKit and alert screening (PAINS + Lipinski + controlled-substance flags) run without a network; bring-your-own-LLM chat routes to the provider you configure. The cloud runtime was retired with the OSS launch; the desktop rebuild ships as OSS in v1.5.x.

The Build

Tauri (Rust + system webview), Python sidecar bundled with the binary so the RDKit/chem stack ships inside the app. Apple Developer ID notarized (team 8N9K9B7Y69), Gatekeeper-accepted. The v1.5.x rebuild routes engine calls to a configurable engine URL (self-hosted or cloud deployment) — no hosted-dashboard dependency.

The Outcome

Design-partner preview live for macOS and Windows. Ships as OSS in v1.5.x per the product roadmap. Access is via /sales-inquiry until the OSS release.

Live → Product page Talk to us about early access Roadmap →
04 · Browser · Chrome extension

Hover any SMILES. Get the profile.

Live

Profile cards on PubChem, ChEMBL, and preprints. ADMET, FAVES compliance, similarity search across 100M+ molecules, without leaving the page you're already on.

The Problem

Pharma and academic chemists live on PubChem / ChEMBL / DrugBank / preprint sites for half their day. Every "go open the workbench, paste this in" is friction. The value has to come to the page they're already on.

The Decision

Show value before asking for a login. Hover-card profiling runs against the free tier of the engine, no account required for the basic ADMET / compliance read. The upgrade path is the side-panel "advanced compute" tab and a "Continue in AI" deep-link.

Whitelisted hosts only (no opportunistic SMILES detection across the open web), a privacy and safety call, not a technical one.

The Build

Manifest V3, content scripts on whitelisted molecular databases + preprint servers, side-panel UI, "Continue in AI" deep-links the current SMILES into any MCP-connected assistant via a session handoff.

The Outcome

Published on the Chrome Web Store. Funnels to the dashboard for users who want an account and to the MCP surface for users who want to keep working in their assistant.

Live → Install from Chrome Web Store Extensions page
05 · Editor · Word add-in

Profile SMILES where you write.

Private beta

Manuscripts, protocols, grants, regulatory writeups. SMILES detected anywhere in the document, profile cards in the task pane, ADMET + FAVES tables inserted as formatted Word tables, without leaving the editor.

The Problem

The pharma writeup happens in Word, grants, IND sections, protocols, manuscripts. Compounds get pasted in early and never get profiled until much later, often after review. By then the wrong number is everywhere.

The Decision

Inline, but private-beta first. The hard part isn't detecting SMILES in Word, it's the UX of an inline AI assistant that doesn't get in the way. Shipping via AppStore-style review locks in a UX before validation; sideload during beta keeps the iteration loop fast.

Insert-as-table (not just preview) so the screening result becomes part of the document, not a sidebar fact.

The Build

Office.js add-in. Manifest hosted statically at addin.novomcp.com (S3 + CloudFront + ACM, SSE-KMS-encrypted bucket with an explicit CloudFront kms:Decrypt grant on the CMK, a real gotcha that 403s the manifest silently if missed).

The Outcome

Private beta. Sideload manifest at addin.novomcp.com/manifest.xml. AppSource submission gated on UX validation with the beta cohort.

Beta → Request beta access Extensions page
06 · Control room · Bundled dashboard

The bundled dashboard. Ships with the engine.

Live

A minimal Next.js dashboard that ships bundled with the open engine — auth, API keys, usage, and pipeline job monitoring. Runs on localhost when you self-host; on your dedicated subdomain in cloud deployments. Minimal today, growing with each release.

The Problem

Every surface needs the same answers to the same questions: who is this key, what can it call, what has it called, what pipeline jobs are outstanding. Built per-surface, that's every surface reimplementing identity and observability. Built as a hosted-only product, it disappears when the hosted product disappears — as it did when the AWS shutdown consolidated the platform down to the open engine.

The Decision

Bundle the dashboard with the engine itself. No separate hosted product. The dashboard ships inside the OSS repo (frontend-nextjs/), starts alongside the engine, points at localhost by default, and grows with the engine on the same release train. Self-hosted operators get identity + audit + jobs UI out of the box; cloud deployments get the same dashboard on the per-org subdomain.

The Build

Next.js 15 frontend shipped in the OSS repo at frontend-nextjs/. Reads from the engine's REST surface (same base URL as the tool catalog). Cloud deployments use Aurora PostgreSQL for identity / audit / async-jobs behind the same UI; self-hosted operators can point it at SQLite / Postgres / whatever the auth service backs.

The Outcome

Minimal today, growing with each release. Ships alongside the engine so a fresh git clone gives you the engine + a UI to watch it, with no separate install. Cloud deployments get the same UI on their dedicated subdomain, no divergent build. New surfaces plug into the same identity + audit path the dashboard already speaks.

Live → Source: frontend-nextjs/ Install the engine
Also shipping · Open source
Apache-2.0 · The engine's open core · Library + MCP

novomcp-lite. NovoMCP's cheminformatics, standalone — the lightweight version.

The lighter way to use NovoMCP's cheminformatics without standing up the whole engine. Eight zero-config tools — RDKit properties, profiling, synthetic-accessibility, PAINS/BRENK alerts, library screening, plus ChEMBL / ClinicalTrials.gov / bioRxiv search — as a two-dependency package. No keys, no account, no services. Prompted by a researcher who wired NovoMCP up to his own agent and asked for a lighter, wrappers-only build.

Python library
pip install novomcp-lite
from novomcp_tools import compute_properties — call the tools directly, two dependencies.
MCP server
pip install "novomcp-lite[mcp]"
Point Claude, or any agent, at the same eight tools. Same code either way.

The design call: one implementation, no drift. novomcp-lite isn't a fork of the engine — the full NovoMCP platform imports the exact same code. So the numbers from the two-dependency library are, to the decimal, the numbers from the full engine. The open core isn't a marketing cut-down; it's what the product runs on.

Open source → GitHub repo PyPI package
MIT · Local-first · MCP + CLI + Library + REST

NovoMD. Same multi-surface idea, smaller scope, fully open.

Turns a SMILES string into 32+ molecular descriptors from a 3D conformer, geometry, energy, electrostatics, surface, volume. Runs on your own machine, no account, no API key. The same one-engine-many-surfaces pattern as NovoMCP, applied at library scale, in the open.

Python library
pip install novomd
calculate_properties("CCO"), RDKit, NumPy, SciPy install automatically.
CLI
novomd props "CCO"
batch, explain, report subcommands. CSV / TSV / JSON / HTML out.
MCP (Hugging Face)
quantnexusai-novomd.hf.space
Live on HF Spaces as a Gradio MCP endpoint. Add to Claude as a custom connector; works in any MCP client.
REST (Docker)
ghcr.io/ariharrisonlab/novomd
FastAPI behind the same core. X-API-Key auth, /health open.

The design call: scope discipline. NovoMD computes descriptors and stops there, no ADMET, no pKa, no binding affinity, no solubility predictions. That boundary is documented in the README and shipped as an agent skill so AI assistants are told explicitly where the tool's authority ends. Determinism guarantee on top: same SMILES, identical descriptors, any machine.

Open source → GitHub repo PyPI package Hugging Face Space MCP endpoint
Cross-cutting decisions

Engine-first language

"Computational chemistry engine", not platform, OS, substrate, operating layer, or orchestration. Those nouns collide with every competitor in the category. The diagnostic test on every public line: could a competitor put this exact sentence on their homepage unchanged? If yes, replace the noun.

Drives copy across nav, marketing, sales scripts, and the assistant's elicitation prompts, same word in every surface.

Scale-to-zero by default

Every compute service ships with min_replicas=0 (Fargate min_capacity=0, EKS GPU nodegroup → 0 nodes). Only the public-path surfaces (the engine gateway, the bundled dashboard) keep min=1.

Carries the Azure cold-start posture forward to AWS, keeps unit economics honest on day one, and avoids retrofit. Pre-warm is opt-in for cloud deployments, not a default cost.

Azure → AWS migration

Full inventory: Aurora (replacing Azure SQL), EKS (replacing Container Apps), S3 + CloudFront (replacing Blob), Secrets Manager, Bedrock-adjacent + NVIDIA credits. ~30 services, ~12 weeks. Reconciliation layer (row parity, schema parity, NULL audit, value fidelity) baked into every cutover.

Customer surfaces, download links, auto-update manifest, MCP endpoints, moved without version regression for existing users.

Private-endpoint-only infra

EKS API, Aurora, Redis, and internal ALBs are all private. GitHub-hosted runners can't reach them, every kubectl apply / psql times out from CI. Locked design: build on GH runners, deploy via GH OIDC → SSM → bastion.

Applied uniformly to every NovoServices repo so the pattern doesn't re-litigate per port. Bastion is pre-wired with kubectl, psql, EKS + Aurora + Secrets perms.

Pricing model: self-hosted or cloud, no middle

The prior model had a Free Trial / Core / Scale / Enterprise credit-tier ladder. Killed all of it at the OSS launch. Self-hosted, free forever (Apache-2.0, run it yourself) or cloud deployment, contact for pricing (per-org subdomain, SAML SSO, GPU pool, certified FAVES). No self-serve middle tier.

Trade-off: no self-serve upgrade path from free to paid. In exchange: two real buyers, two paths, no billing complexity in between.

Human-in-the-loop, not autonomous

The discovery funnel is 11 stages in the open engine (FEP was extracted per the cleave; available as a paid Novo Compute service). It runs as an MCP server inside the user's assistant, every stage prompts the user via MCP elicitation. Not a standalone autonomous agent running on someone else's compounds.

The audit trail records every gate, every decision, every tool call. Pipeline audits are the quality gates; the funnel is what's audited.

The pluggable spine: local ↔ hosted, one codebase

Auth, metering, and audit are three swappable implementations behind stable protocols, chosen by env flag (NOVO_AUTH / NOVO_METER / NOVO_AUDIT = local · hosted · custom). A fresh clone runs the local spine — no auth, no credit accounting, audit to ~/.novo/audit.jsonl. The hosted deployment runs the same engine code with the hosted spine wired in.

No OSS-vs-enterprise fork. The open engine is the product; auth / metering / audit is a runtime boundary, not a feature gate. Set the flags to custom and drop in your own implementations against the three protocols.

Wrap open compute, add an accelerated axis

The engine wraps established open tools — RDKit, GROMACS, AutoDock-GPU, OpenFold, Boltz, Gnina, xTB, ANI-2x, AIMNet2, MACE — rather than reimplementing them. That's what "open computational chemistry engine" means: the orchestration and governance are the work, not the physics. NovoMCP's own GPU service wrappers ship as standalone open repos too — gromacs-md (MD), novomcp-nnp (neural-network potentials), novomcp-qm (quantum chemistry) — each deployable on its own.

As of v1.3.0, geometry, single-point energy, and conformer-search tools take an engine axis (ase ↔ alchemi, crest ↔ alchemi): the same tool call runs the open reference path or an ALCHEMI-accelerated GPU path, chosen per call. Acceleration is a pluggable axis, not a rewrite. As of v1.4.0, the engine's in-process cheminformatics is sourced from the open novomcp-lite package — the exact code the two-dependency library ships, so the platform and the library never diverge.

Selectively open to research and product conversations.

X / Twitter LinkedIn NovoMCP Back to home
© 2026 Ari Harrison. Selectively open to research conversations.