Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@thermophysical-curator Please validate these molecules and curate their thermophysical records."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for auditable thermophysical data curation using five supplied JR-MPNN checkpoints and selected UManSysProp group-contribution methods.
inspect_molecule: validate and canonicalize a SMILES string and report domain flags.
predict_jrmpnn: predict Tm, Tb, Tc, Pc, and Vc with Joback baselines.
assess_jrmpnn_training_similarity: compare a query with the 10 nearest
property-specific JR-MPNN training embeddings without returning private records.
estimate_umansysprop: estimate boiling point, critical properties, density, and vapor pressure.
curate_thermophysical_records: normalize, deduplicate, score, and triage records with an audit trail.
server_capabilities: report available models, methods, and scientific limitations.
Predictions are diagnostic cross-checks. They do not replace accepted experimental measurements, and the server never silently deletes submitted records.
Related MCP server: GNNPCSAFT MCP Server
Python 3.11 or newer is required. Installation may take several minutes because PyTorch, PyTorch Geometric, RDKit, and the scientific dependencies are substantial.
git clone https://github.com/frankmtetwa/thermophysical-curator.git
cd thermophysical-curator
python -m venv .venvActivate the environment:
# Windows PowerShell
.\.venv\Scripts\Activate.ps1# macOS/Linux
source .venv/bin/activateThen install and test:
python -m pip install --upgrade pip
python -m pip install .
python -m unittest discover -s tests -vRun the stdio MCP server with:
thermophysical-curatorThe process waits for an MCP client on standard input. That behavior is expected.
The repository does not contain proprietary training compounds or generated embedding indices. On each computer where similarity assessment is required, create a private reference directory containing these five files:
private_reference/
|-- Tm_train_smiles.csv
|-- Tb_train_smiles.csv
|-- Tc_train_smiles.csv
|-- Pc_train_smiles.csv
`-- Vc_train_smiles.csvEach CSV must contain a smiles column. A compound_id column is optional:
compound_id,smilesPrivacy-safe header-only examples are available in reference_templates/. Copy
them to private_reference/, then populate them locally with the SMILES used to
train the corresponding property model. Do not combine calibration or test
compounds with the training set.
Build the private embedding indices after installing the project:
python -m curation_agent.similarity buildThe default location is private_reference/ in the repository root. To keep the
files elsewhere, set THERMOPHYSICAL_REFERENCE_DIR to an absolute directory
before building the indices and before launching the MCP server. Restart the MCP
client after building so it refreshes the available tool state.
The reported training-similarity percentile is an applicability-domain diagnostic, not a calibrated uncertainty interval or a guarantee of prediction accuracy.
This repository contains an experimental cross-platform UV manifest. Install the MCPB CLI and build the extension from the repository root:
npm install -g @anthropic-ai/mcpb
mcpb validate manifest.json
mcpb pack . dist/thermophysical-curator-0.1.0.mcpbIn Claude Desktop, open Settings > Extensions > Advanced settings > Install
Extension and select the generated .mcpb file. The UV runtime downloads the
Python dependencies on first launch, so the initial startup can be slow. When
Claude asks for the Private JR-MPNN reference directory, select the
private_reference directory containing both the five CSV files and the generated
embeddings/ directory. The private files remain outside the extension bundle.
Users who prefer a pre-created virtual environment can add this to Claude Desktop's MCP configuration, replacing the command with the absolute path to their environment:
{
"mcpServers": {
"thermophysical-curator": {
"command": "C:\\path\\to\\repo\\.venv\\Scripts\\python.exe",
"args": ["-m", "curation_agent.server"]
}
}
}On macOS/Linux, use /path/to/repo/.venv/bin/python instead.
After installing the project, register the server using the environment's Python:
codex mcp add thermophysical-curator -- /absolute/path/to/python -m curation_agent.server{
"smiles": "CCO",
"property": "normal_boiling_point",
"value": 78.37,
"unit": "C",
"source": "literature citation",
"doi": "10.xxxx/example",
"experimental": true,
"method": "ebulliometry",
"uncertainty": 0.1
}The package contains model weights but no training, calibration, or proprietary experimental records. Inputs are processed locally by the MCP server. The host AI application may still receive tool arguments and results, subject to that application's privacy policy.
Before making the repository public, verify that you have permission to redistribute
the five JR-MPNN .pth checkpoint files. They are required for model predictions but
their redistribution terms were not present in the supplied source directory.
UManSysProp-derived files retain their original copyright notices and GPL terms. See THIRD_PARTY_NOTICES.md and LICENSE.
GPL-3.0-or-later, subject to the third-party notices and checkpoint redistribution rights described above.
Assess similarity to a property's private JR-MPNN training embeddings.
Uses mean Euclidean distance to the 10 nearest graph embeddings. Private Training SMILES, embeddings, and reference identifiers are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| property_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: the similarity metric (mean Euclidean distance to the 10 nearest graph embeddings) and the privacy guarantee that private SMILES, embeddings, and reference identifiers are never returned. It omits permissions, cost, and output interpretation, but the algorithmic and privacy disclosure is notably richer than most.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs that are front-loaded with the core purpose, followed by the method and privacy note. Efficient and free of filler, though the line break splits a single idea across paragraphs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and the description usefully covers the method and privacy posture. However, with zero parameter documentation and no annotations, it leaves the agent without guidance on what property_name accepts or what the similarity score means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with two required parameters, so the description must compensate and largely does not. 'property_name' is only weakly implied via 'a property's ... training embeddings,' and 'smiles' receives no explanation at all, leaving validation and format details undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Assess similarity to a property's private JR-MPNN training embeddings.' An agent can distinguish this as a similarity-assessment tool rather than a prediction tool, though it never names or contrasts the sibling predict_jrmpnn. Clear, but no explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no when-to-use guidance, no prerequisites, and no comparison to alternatives like predict_jrmpnn or estimate_umansysprop. The agent must infer the appropriate context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize, deduplicate, score, and triage records with a full audit trail.
Each record should contain smiles, property, value, and unit. Strongly recommended provenance fields are source or doi, experimental, method, and uncertainty. The tool never silently removes a record.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | ||
| model_check | No | ||
| relative_deviation_threshold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose two meaningful traits: a full audit trail and the guarantee that it 'never silently removes a record.' That non-destructive policy is exactly the kind of context annotations would normally supply. It still omits what 'triage' actually produces (flags? quarantine?) and any permission or performance notes, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action list before the field guidance; every sentence carries information. Slightly list-like in the middle but no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the record format is well covered. But for a 3-parameter, 0%-coverage, annotation-free tool the description is silent on the two optional parameters, the scoring criteria, and what triage emits, leaving real gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does document the record payload well (smiles, property, value, unit, plus strongly recommended provenance fields). However, model_check and relative_deviation_threshold are left entirely unexplained, including what the 0.25 default tolerance governs, so two of three parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names four specific operations (normalize, deduplicate, score, triage) on a concrete resource (thermophysical records), plus the audit-trail outcome. No sibling tool (inspect_molecule, predict_jrmpnn, estimate_umansysprop) overlaps with curation, so the function is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: it is clear this is the pipeline step for cleaning raw records, and it tells the agent what a well-formed record looks like, but it never says when to reach for this tool versus the prediction siblings or what prerequisites (e.g., valid SMILES) must hold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run UManSysProp group-contribution estimates without its legacy web UI.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| temperature_k | No | ||
| critical_method | No | nannoolal | |
| boiling_point_method | No | nannoolal |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Run ... estimates' implies a computation rather than a mutation, but the description does not state side effects, permissions, determinism, error behavior, or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and avoids filler, but it is too terse for a four-parameter scientific estimation tool. The description is under-specified rather than efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, with no annotations and 0% schema parameter coverage, the description omits essential input semantics and usage context needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters. It does not explain SMILES input, temperature, or method selection, leaving parameter meaning entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Run') and a specific resource ('UManSysProp group-contribution estimates'), making the tool's core function clear. It distinguishes the tool from the legacy web UI, but does not distinguish it from sibling prediction tools such as predict_jrmpnn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor when not to use it. The phrase 'without its legacy web UI' implies a replacement for a web interface, but gives no sibling-tool routing or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and canonicalize a SMILES string and report model-domain flags.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state what happens with an invalid or non-canonicalizable SMILES, whether errors are raised or flagged, or what the flags mean, leaving the mutation/validation behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no wasted words; the core action and the output signal are both present immediately. It is terse enough to be efficient but leaves several behavior questions unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one input, output schema present) so return values need not be explained, but the description omits error/failure semantics and the meaning of 'model-domain flags', which an agent would need for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 0% schema description coverage, the description must compensate, and it does identify the input as a SMILES string. However it adds no format constraints, length limits, or examples beyond that basic identification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names specific verbs and a resource: validate and canonicalize a SMILES string, plus report model-domain flags. This is clearly distinguishable from prediction-oriented siblings like predict_jrmpnn and estimate_umansysprop, though it never explicitly names an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when not to, or which sibling to prefer. The 'model-domain flags' phrasing weakly implies a pre-prediction check, but the agent must infer that entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict Tm, Tb, Tc, Pc, and/or Vc with the supplied JR-MPNN checkpoints.
Property symbols are Tm, Tb, Tc, Pc, and Vc. Returned intervals are clearly marked as uncalibrated because the paper's k-NN calibration artifacts are not present in this workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | ||
| properties | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, and it does disclose one real trait: returned intervals are uncalibrated because k-NN calibration artifacts are absent. However, it omits other important behavior — where 'supplied' checkpoints come from, failure modes for invalid SMILES, and whether every requested property is always returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and target. It wastes a little space restating the property symbols that the first sentence already named, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, and the description does flag the calibration caveat. Still missing are sibling differentiation, checkpoint sourcing, and any parameter-level detail for `smiles`, leaving meaningful gaps for a tool with zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters, so the description must compensate. Enumerating the valid property symbols partially documents the `properties` argument, but the required `smiles` parameter is never explained (format, accepted inputs), and the array/default semantics remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Predict') and a concrete set of resources (Tm, Tb, Tc, Pc, Vc) tied to a named model (JR-MPNN checkpoints). It is clear what the tool does, but it never distinguishes itself from the sibling estimate_umansysprop, which appears to predict the same class of thermophysical properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool rather than estimate_umansysprop, nor any prerequisite (e.g., which checkpoints must exist, whether a workspace setup is needed). 'and/or' hints that the property subset is user-selectable, but that is inference rather than guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe supported properties, methods, and important scientific limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It names the categories of information returned (properties, methods, limits), which is meaningful for a zero-parameter introspection tool, but says nothing about whether results are static, cached, or versioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with a clear verb and no filler. It is appropriately sized for a simple introspection call, though 'important' is a mildly subjective qualifier that adds no operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return values, and with zero input parameters the surface is small. The description covers purpose and scope adequately, leaving only the when-to-call guidance as a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4. The description correctly does not invent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Describe') and enumerates the resource: supported properties, methods, and scientific limits. This distinguishes it from the prediction/inspection siblings, which all act on molecules or records rather than describing server-side capability. It is clear but somewhat generic in phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance, no mention of calling it before the predict/estimate/inspect siblings, and no exclusions. The intended 'discovery first' usage is only inferable from the name and the nature of a capabilities endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1assess_jrmpnn_training_similaritycurate_thermophysical_recordsestimate_umansyspropinspect_moleculepredict_jrmpnnserver_capabilitiesScored across 6 tools
Each tool has a distinct role: SMILES validation, JR-MPNN prediction, training-similarity/applicability-domain assessment, UManSysProp estimation, record curation, and a capabilities meta-tool. The two property-prediction tools (predict_jrmpnn and estimate_umansysprop) overlap in output but are clearly separated by method, so mild confusion is possible but descriptions resolve it.
Names are uniformly snake_case with clear verb_noun structure (inspect_molecule, predict_jrmpnn, assess_jrmpnn_training_similarity, estimate_umansysprop, curate_thermophysical_records). The lone noun-only server_capabilities is a minor deviation from the verb-led pattern.
Six tools is well-scoped for a thermophysical prediction-and-curation server, with each tool covering a coherent responsibility. No tool feels redundant or missing at the count level.
The surface covers the core lifecycle: molecule validation, two prediction paths, applicability-domain assessment, curation with audit trail, and a capabilities descriptor. Batch prediction/curation or result-export operations are not exposed, but the primary workflows are covered without obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Link compounds to protein targets, rank bioactivity, and look up drug mechanisms and indications.
Knowledge graph ingestion, entity search, ontology analysis, and CoPass scoring.
AI orchestration for computational chemistry and HPC workflows.
Machine-readable entity discovery with provenance, trust and verified source evidence.
