MCP server for molecule property prediction including ADMET, Pharmacokinetics, and ToxScan analysis
Server defines 3 tools with basic structure but lacks critical refinements for production. All tools have descriptions (good baseline), but naming lacks action verbs, parameter descriptions are minimal, and output schemas are not formally documented in the visible code. Tool descriptions are between 94-150 chars (within acceptable 10-1024 range but on the lower end). Input schemas are present and typed, but lack detail in parameter descriptions. No error handling guidance, no security considerations documented, and no explanation of when/why to use each tool. The server provides molecule prediction services with proper Pydantic model definitions, but the MCP tool interface itself needs strengthening.
Predict the ADMET properties of a molecule. Absorption, Distribution, Metabolism, Excretion and Toxicity Prediction for Molecules
Predict the Pharmacokinetics properties of a molecule. Pharmacokinetic Metabolism Curve Prediction, Prediction of Drug Concentration Changes over Time.
Predict the ToxScan properties of a molecule. Safety Evaluation of Drugs, Chemicals or Environmental Pollutants.
Tool names lack action verbs. 'ADMET_Service', 'Pharmacokinetics_Service', and 'ToxScan_predict' do not start with clear verbs like 'predict_', 'calculate_', or 'get_'. Names should reflect the action: 'predict_admet_properties', 'predict_pharmacokinetics', 'predict_toxicity'. Naming influences LLM tool selection, vague names lead to selection errors.
Parameter descriptions are missing or trivial. The 'data' parameter in all three tools is documented only by its nested structure (e.g., 'smiles' → 'SMILES string representation of the molecule'). Parent parameter 'data' itself has no description explaining its role or when it's required. Parameter descriptions should explain: what does it control, what values are valid, what happens if omitted. Without descriptions, LLMs cannot infer parameter semantics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Output schemas are not documented. The Pydantic models (RES[AdmetInnerData], RES[PKResult], RES[ToxResult]) are defined in tools/base.py but not visible in the main.py excerpt. Without seeing the return type structure, the LLM cannot plan downstream reasoning. Tool descriptions must state: 'Returns an object with fields: [list key fields].' This enables the agent to extract and chain data.
Tool descriptions lack context for selection. E.g., 'Predict the ADMET properties of a molecule. Absorption, Distribution, Metabolism, Excretion and Toxicity Prediction for Molecules' (94 chars) tells what it does but not when to call it vs. the pharmacokinetics or toxicity tools, or what inputs it requires (SMILES string). Descriptions should answer: What does it do? When should I call it? What prerequisites exist?
No error handling or recovery guidance. The server provides no documented error responses. What happens if an invalid SMILES string is passed? If the inference service is unavailable? If dose is out of range? Tools should return actionable errors: 'Invalid SMILES format. Expected OpenSMILES string, got: <value>.'
Parameter validation constraints not documented. Pharmacokinetics_Service accepts 'dose' (number, default 1) and 'route' (enum: p.o., i.v., default p.o.). The description for 'dose' should state expected range: 'Dose in mg/kg (typical range: 0.1 - 100). Defaults to 1 if omitted.' Without range, LLMs may pass physically unrealistic values (e.g., dose: 1000000).
No documentation of prerequisites or dependencies. The tools expect SMILES strings but do not document that SMILES must be valid chemical notation. Users in chat say 'predict for aspirin', not 'predict for CC(=O)Oc1ccccc1C(=O)O'. The tool should guide: 'Call this with a SMILES string (e.g., valid OpenSMILES notation). If you only have a chemical name, use an external lookup first.'