Use the Inductive Bio connector for ADMET predictions

This connector runs property predictions on molecules you supply as SMILES strings. It has two tools: one lists the models available to you, the other runs chosen models on chosen molecules. Your job is to get the model IDs right, send well-formed and sensibly sized batches, and present the numbers as model estimates for ranking and triage, not as measured facts.

1. Confirm access and sign-in

The connector uses sign-in, so the first call may fail if the user has not connected yet. If a call returns an authorisation error, stop and tell the user to complete the sign-in from Settings > Connectors (or follow the connect step in the Inductive Bio docs), then retry. Do not try to work around it or ask for credentials in the chat.

2. Discover models before predicting

Never guess a model ID. Call list_available_models first and read each model's ID, assay name and units. Pick the model whose assay matches the question. Available models may differ by customer, so if the user names a property you cannot find, say it is not in the returned list rather than substituting a different assay.

Map the user's wording to the assay carefully:

• "lipophilicity" or "logD" is a distribution measure at a stated pH; check the pH and units in the list.
• "pKa" can be acidic or basic; return both when the model provides them and label them.

3. Prepare SMILES before sending

• Check each SMILES is a single, parseable structure. Stereochemistry in the string (@, @@) is meaningful; keep it as given.
• Remove salts and counterions unless the user wants the salt form predicted. A stray .Cl or .Na can change the result.
• Keep names and SMILES paired. When the user gives drug names, state which SMILES you used, and if you wrote one yourself from a name, say it is your transcription and ask them to confirm.
• Batch sensibly: group molecules into a single predict_properties call where the same models apply, and split very large lists into several calls rather than sending hundreds at once. Keep each call's list readable.

4. Run predictions and check the output

Call predict_properties with the SMILES and the model IDs from step 2. Then check the response before interpreting it:

• Every submitted molecule should have a result. A missing molecule or an empty value means it was not predicted, and must be reported as such.
• An invalid-structure error usually means one SMILES is malformed. Identify which one, fix or ask for the correct string, and resubmit only that one.
• Keep the molecule labels aligned with the returned values. Mismatched order is a common source of wrong comparisons.

5. Interpret LogD and pKa with restraint

• LogD is lipophilicity at a given pH. Higher values generally mean more membrane permeability and less aqueous solubility, but there is a range beyond which other problems dominate. Compare values across candidates measured by the same model; do not read a single value as an absolute guarantee.
• pKa tells you the ionisation state at a given pH. An acid with pKa well below the physiological pH is mostly ionised, which tends to limit passive permeation; a base with pKa well above it is mostly protonated. Reason about the balance between the acidic and basic centres when both are present, because zwitterions behave differently from either alone.
• Use the predictions for ranking and hypothesis generation. A change that moves LogD or pKa in the expected direction supports a design idea; it does not prove the drug will be absorbed or reach a target tissue. Brain penetration and absorption depend on transporters, binding and metabolism that these two properties alone do not capture.

6. Report comparisons clearly

When comparing a parent molecule with designed analogues, put the parent first, give the predicted values for each model, and state the difference. Say which candidate you would prioritise and why, and name the assumption behind it.

Common patterns and traps

• Guessing model IDs from assay names leads to wrong or failed calls. Always read them from list_available_models.
• Trusting a number to two decimals. Predictions carry model uncertainty; quote them as estimates and avoid false precision in rankings with near-identical values.
• Treating the acidic and basic pKa as one value. Ask which group each number refers to.
• Forgetting the pH when comparing LogD values from different sources.
• Silently dropping a molecule that failed to parse. Always report which structures were not predicted.
• Mixing a salt form with the free base in one comparison and attributing the difference to structure.
• Overclaiming absorption or brain penetration from LogD and pKa alone.

Output

Models used: <model ID — assay — units>
Molecules: <n submitted, n predicted, n not predicted (with reason)>

| Molecule | SMILES used | <assay 1> | <assay 2> |
|---|---|---|---|
| ... | ... | ... | ... |

Reading: <what the values suggest, stated as model estimates>
Priority: <which candidate and why, or "no clear winner">
Caveats: <pH assumptions, salt handling, transporter or metabolism not covered>
Not established: <what these predictions cannot tell you>

Rules

• Do not guess a model ID; use only IDs returned by list_available_models.
• Never present predicted values as measured or experimental results.
• Do not submit a molecule's structure to the tools without the user having asked for that prediction.
• Do not store, repeat or share the user's proprietary structures beyond the current answer; the server retains no structures after a request, and the user should not expect more than that.
• predict_properties runs a computation on the user's chosen molecules. Running a prediction is not a change to their data, so you do not need approval for it, but list the molecules and models you are about to run if the batch is large.
• Do not switch or re-authenticate accounts on the user's behalf; if sign-in must change, wait for the user's explicit yes before doing it.
• Do not invent a pH, pKa or LogD value to fill a gap; report it as not predicted.

Done when

• The model IDs used came from list_available_models, and each is named in the answer with its units.
• Every submitted molecule is either reported with values or explicitly listed as not predicted, with a reason.
• The interpretation is framed as model estimates, and the "Not established" line says what the predictions cannot show.