Explainer8 min readJuly 15, 2026

Tool Calling vs Fine-Tuning for Scientific AI

Tool calling vs fine tuning in science: why a purpose-built model plus an LLM caller beats a fine-tuned LLM on determinism, applicability domain and audit.

Oliver Kraft

CovaSyn

Tool Calling vs Fine-Tuning for Scientific AI

You have an LLM, a pile of internal assay data, and a request from management to "make the AI understand our chemistry". Two roads lead out of that meeting: fine-tune the language model on your data, or keep the language model as an interface and let it call a purpose-built scientific model. The choice looks like a modelling decision. It is really a decision about determinism, audit and what happens on compounds you have never seen.

Here is how we think about it, with the numbers we can defend.

The two architectures, stated plainly

Fine-tuning.

You take a general LLM and continue training it on your data, so property prediction happens inside the weights. Input: text. Output: text that contains a number.

Tool calling.

The LLM stays a language model. It parses the request, picks a function, passes structured arguments, and reports back what the function returned. The number is produced by a regression or classification model that was trained, validated and versioned for exactly that endpoint. This is what an MCP server does.

Both can answer "how soluble is aspirin in water". Only one of them can tell you the answer is the same tomorrow.

Determinism: the property nobody asks about until audit

We called covasolve_predict twice on aspirin (CC(=O)Oc1ccccc1C(=O)O) in water at 298.15 K, back to back, live:

call 1: log_s_mol_l = -1.5360633667079602   confidence 0.9997810146692852
call 2: log_s_mol_l = -1.5360633667079602   confidence 0.9997810146692852

Identical to the last digit. The 95% confidence interval came back as [-1.5386, -1.5335] both times, and the only field that changed between the two returns was the audit timestamp. That is not a nice-to-have. It means a prediction cited in a development report can be reproduced by someone else, on a different day, and defended.

A sampled LLM does not give you that. You can set temperature to zero and still see drift across model versions, prompt formatting and serving stacks. If the number lives in the weights, you cannot pin it without pinning the entire model, and you cannot explain to a reviewer why it moved.

Caveat that belongs next to that number:

the tight confidence interval is the ensemble's internal agreement, not a measurement uncertainty. The real error bar for CovaSolv is the held-out RMSE below, roughly 0.69 log units.

Accuracy: measure it on a split you can name

A purpose-built model can be benchmarked. That is the whole point.

CovaSolv (deployed ensemble_v7) on its own held-out scaffold split, aqueous subset, n_test = 4,193 rows with molecular cores absent from training:

The point is not the win, it is that both rows name a split and a test-set size. A fine-tuned LLM cannot produce this table without becoming a benchmarked property model first. Source: CovaSolv (deployed ensemble_v7) held-out scaffold split, aqueous subset, n_test = 4,193 rows with cores absent from training; ESOL values as reported in Delaney, J. Chem. Inf. Model. 2004, 44, 1000 (n = 528).

Model	RMSE (log S)	MAE	R2	Within 0.5 log
CovaSolv, held-out aqueous (n = 4,193)	0.689	0.402	0.914	76.4%
ESOL (Delaney 2004), as published (n = 528)	0.96	0.83	0.55	not reported

Caveats, stated once and meant: these are different test sets. The ESOL numbers are the ones reported in the original paper (Delaney, *J. Chem. Inf. Model.* 2004, 44, 1000), not a re-run on our data. And CovaSolv predicts apparent aqueous solubility, the quantity in its BigSolDB/OChem training data, not intrinsic S0 of the neutral species. For ionizable drugs those differ by 1 to 3 log units.

The point for this article is narrower: this table exists, and the split that produced it is named. You cannot write the equivalent table for a fine-tuned LLM without the same effort, and if you do that effort you have built a benchmarked property model anyway.

The honest version of a head-to-head

CovaTox publishes a same-split comparison against the TDC ADMET leaderboard. The methodology matters more than the numbers: for each mapped dataset we retrain the standard CovaTox pipeline (Mordred + ToxPrint features, Optuna-tuned XGBoost/LightGBM) on TDC's official train split only, 5 seeds, and score with TDC's own evaluator. The deployed models trained on the full datasets, whose rows overlap TDC's test set, so using them here would be leakage.

Selected results (protocol run 2026-05-23, 5 seeds; leaderboard #1 accessed 2026-05-23):

TDC dataset	Metric	n_test	CovaTox (mean +- sd)	Leaderboard #1
CYP3A4 inhibition (Veith)	AUPRC	2,467	0.874 +- 0.002	0.916 (MapLight+GNN)
CYP2C9 inhibition (Veith)	AUPRC	2,419	0.780 +- 0.006	0.859 (MapLight+GNN)
Ames	AUROC	1,457	0.847 +- 0.013	0.871 (ZairaChem)
LD50 (Zhu)	MAE	1,478	0.622 +- 0.007	0.552 (BaseBoosting)
BBB (Martins)	AUROC	406	0.892 +- 0.011	0.924 (MiniMol)

We are behind the leaderboard #1 on every one of these. We publish it anyway, because that is the number a same-split protocol produces and because it tells you what the gap actually is: a few points of AUROC, not a category difference. Reference: Huang et al., *Nat Chem Biol* 18, 1033 (2022) plus the live TDC ADMET leaderboard.

Notice what you can do with this table that you cannot do with a chat transcript. You can see the test-set size. You can see the seed-to-seed spread. You can rerun it.

Applicability domain: the answer a fine-tuned model will not give you

An LLM will answer any question you ask, including about a scaffold nothing in its training data resembles. It has no mechanism to decline. A property model does.

Live covatox_check_domain calls against the Ames endpoint:

p-toluidine (Cc1ccc(N)cc1): in_domain: true, tanimoto_ok: true, feature_coverage: 0.9327, confidence_modifier: 0.9658. A classic aromatic amine, well inside the training chemistry.
aspirin (CC(=O)Oc1ccccc1C(=O)O): in_domain: false, tanimoto_ok: false against a Tanimoto threshold of 0.3, feature_coverage: 0.9814, confidence_modifier: 0.1.

The second result is the interesting one. Aspirin's descriptors sit inside the training ranges (coverage 0.98), but the nearest-neighbour check found nothing similar enough in the Ames reference set, so the tool downgrades its own confidence rather than answering with a straight face. In CovaTox, an out-of-domain prediction is additionally demoted to experimental tier and the risk level is set to uncertain. That is a fail-loud design. Read nearest_similarity as "no near neighbour in the reference set", not as a chemistry statement about the molecule.

Aspirin sits inside the training descriptor ranges but has no near neighbour in the Ames reference set, so the tool downgrades itself to 0.1 confidence. A fine-tuned LLM has no mechanism to decline. Read the failed Tanimoto check as no near neighbour in the reference set, not as a chemistry claim about aspirin. Source: Live covatox_check_domain calls against the CovaTox Ames endpoint, Tanimoto threshold 0.3.

Cost, latency and the practical stuff

Cost per prediction. A covasolve_predict or covatox_check_domain call is billed per prediction, and both return in well under a second on CPU. Fine-tuning a frontier model on proprietary chemistry, then re-tuning it every time the base model is deprecated, is a recurring project, not a call.
Update path. Retraining a gradient-boosted model on new assay data is hours on CPU. Re-fine-tuning an LLM is a training run plus a full revalidation of everything the model touches, because the weights that changed also carry the language behaviour.
Data residency. Tool calling keeps the numeric model behind your boundary. The LLM sees the request and the returned JSON, not the training set. Fine-tuning puts your assay data into model weights, which is a much harder thing to un-ship.
Where the LLM genuinely wins. Reading the request, chaining five tools in the right order, and writing the paragraph that explains the result. That is language work, and it is exactly what tool calling leaves it doing.

When fine-tuning is the right call

Not never. Fine-tune when the task is language: extracting structured fields from batch records, classifying deviation reports, normalising in-house nomenclature, matching your writing conventions in a report. Fine-tune when there is no numeric ground truth to regress against. And fine-tune when you want the model to reliably choose the right tool from 200 of them, which is a formatting and routing skill, not a chemistry one.

The failure mode is using fine-tuning to teach an LLM a number it could have looked up from a model that was validated to produce it.

What this does not tell you

Tool calling does not make the underlying model correct. CovaSolv is 0.914 R2 on novel scaffolds and roughly a factor of three in concentration for three quarters of predictions. That is triage, not an analytical result.
The comparison above is architectural, not a benchmark of any specific LLM on solubility. We did not run one, so we do not quote one.
The LLM can still call the wrong tool with the wrong arguments. Determinism of the tool does not buy correctness of the routing.
None of this replaces wet-lab confirmation or supports a regulatory filing on its own. It changes which experiments you run first.

Frequently asked questions

Is tool calling more accurate than fine-tuning for chemical property prediction?

For numeric property prediction, a purpose-built model called as a tool is the defensible choice because its accuracy can be stated with a named split and test-set size. CovaSolv reports R2 0.914 and RMSE 0.689 log on 4,193 held-out novel-scaffold rows. A fine-tuned LLM can be evaluated the same way, but doing so means building and validating a property model anyway.

Why does determinism matter for scientific AI?

Because a number in a development report has to be reproducible by someone else on a different day. Two consecutive covasolve_predict calls on aspirin in water returned log S -1.5360633667079602 both times, identical to the last digit, with only the audit timestamp differing. A sampled language model gives no such guarantee, and version changes can move the answer without explanation.

What is an applicability domain and why can't an LLM have one?

An applicability domain check tests whether a query compound is close enough to the training chemistry for the prediction to mean anything. covatox_check_domain returned in_domain: true for p-toluidine on the Ames endpoint and in_domain: false for aspirin, against a Tanimoto threshold of 0.3. A language model has no equivalent nearest-neighbour reference set, so it answers with the same fluency in-domain and out.

When should I fine-tune an LLM on my own scientific data?

When the task is language rather than numbers: extracting fields from batch records, classifying deviations, normalising internal nomenclature, or teaching reliable tool selection among many tools. Fine-tuning is a poor substitute for a regression model when a numeric ground truth exists, because it discards the ability to report a benchmarked accuracy on a named split.

How does CovaSyn benchmark against public leaderboards?

CovaTox retrains its standard pipeline on the TDC ADMET official train split only, 5 seeds, scored by TDC's own evaluator. On CYP3A4 inhibition (n_test 2,467) it reaches AUPRC 0.874 +- 0.002 against a leaderboard #1 of 0.916; on Ames (n_test 1,457) AUROC 0.847 +- 0.013 against 0.871. We are behind the top entries and publish it, because a same-split number is the only comparable one.

Does tool calling protect proprietary data better than fine-tuning?

Yes, structurally. With tool calling, the numeric model and its training data stay behind your boundary, and the language model only sees the request and the returned JSON. Fine-tuning writes your data into model weights, which cannot be selectively removed later and travels with every copy of the model.