Inductive

View saved version →

---
name: compare-analogs
description: Compare molecular-property predictions across analogs with Inductive Bio using matched models, explicit deltas, and cautious interpretation. Use for analog ranking, property trends, or reference-relative comparisons.
---

# Compare molecular analogs

Follow the shared requirements in the `index` skill. Do not use this skill without applying those requirements.

## Inputs

Collect:

- At least two compounds with distinct labels and exact SMILES.
- Requested properties.
- A reference compound when deltas are requested.
- A direction or target range for each ranking criterion.
- Any project pH, diversity constraint, or maximum shortlist size relevant to the decision.

If the user asks for the best compound without defining the desired direction or range, ask for the decision criterion. Do not assume that higher or lower is universally better.

If any structure is identified as confidential, obtain explicit confirmation before sending the structures to the connector.

## Workflow

1. Call `list_available_models` and resolve the requested properties to live model identifiers.
2. Call `predict_properties` with the same selected model set for every analog, using the exact live MCP schema.
3. Preserve the returned values and units. Do not compare values across different model identifiers or incompatible units as if they were directly equivalent.
4. Build a comparison table containing label, exact SMILES, model identifier, property or assay, prediction, units, and status.
5. When a reference is defined, compute signed deltas as `analog prediction - reference prediction` within each matched model and unit. State that convention.
6. Rank only against criteria supplied by the user. Show ties and missing values explicitly, and do not rank failed or missing predictions as though they were numeric.
7. Separate the result into returned predictions, derived deltas or rankings, and scientific interpretation.

## Compound-series analysis

- **Triage:** state the exact rules before applying them. If the user gives a qualitative rule such as "moderate LogD," translate it into a clearly labeled provisional criterion or ask for a project-specific range when the distinction could change the decision. Keep every input compound and failed prediction visible.
- **Shortlisting:** use only completed, comparable results; honor the requested maximum; preserve structural diversity when the structures support that assessment; and explain that the shortlist is assistant-side reasoning rather than an additional Inductive Bio prediction.
- **Relationship and grouping analysis:** include only matched, nonmissing values in each comparison, report the number of compounds used, and identify apparent trends or clusters as descriptive. Do not claim mechanistic causality or statistical significance without an appropriate analysis.
- **Results handoff:** organize completed results with compound ID, input SMILES, model name or property, model ID, predicted value, units, and status. Add assumptions, failures, and open questions separately. Do not claim a native export endpoint.

## Interpretation boundary

Describe observed model trends without assigning causality to a structural change unless the comparison supports it and relevant confounders are acknowledged. Do not treat a favorable LogD, pKa, or other isolated prediction as proof of permeability, absorption, safety, efficacy, brain penetration, or candidate quality. If a user asks which analog has the "best chance" of brain exposure or improved absorption from LogD or pKa alone, report the single-property ranking they requested but explicitly decline the broader conclusion and list the missing evidence.

Referenced files: 1

View saved version →

---
name: index
description: Route Inductive Bio molecular-property requests to model discovery, prediction, or analog comparison. Use when a user asks generally about the Inductive Bio connector or wants help choosing the appropriate workflow.
---

# Inductive Bio

Use the Inductive Bio MCP connector for molecular-property prediction from exact SMILES.

## Route the request

- Use `predict-properties` for one or more independent property predictions, named-compound panels, fragment-level prediction, or cautious interpretation of LogD and pKa.
- Use `compare-analogs` when the user wants matched comparisons, reference-relative deltas, ranking, triage, shortlisting, or relationship and grouping analysis across two or more compounds.
- For a connector or model-availability question, call `list_available_models` and report the returned model identifiers, property or assay names, and units without making a prediction.
- For privacy preflight or packaging of already completed results, handle the request here. Do not make another prediction call unless a required result is missing.

## Shared operating rules

1. Call `list_available_models` before every prediction workflow. Treat its live response as authoritative and do not hardcode model identifiers or assume a property is available.
2. If OAuth authorization is required, tell the user it must be completed before any connector tool call — model discovery or prediction — can succeed.
3. Use only the live MCP tool schema. Do not invent REST endpoints, request fields, batching limits, or undocumented properties.
4. Require an exact SMILES for every submitted compound. Preserve user labels separately from SMILES. If the user supplies only a chemical name, obtain an exact structure from an authoritative source when one is available; show the resolved SMILES and any stereochemistry, protonation, or salt-form assumption. Ask the user when the intended structure is ambiguous rather than silently choosing one.
5. If the user identifies any structure as confidential, proprietary, or undisclosed, explain that the structure will be sent to an external service and obtain explicit confirmation before calling a prediction tool.
6. For large inputs, read the per-call SMILES and model-id limits from the live `predict-properties` tool schema/description and split the request into batches that fit those limits. Do not hardcode specific limit values, since they are set server-side and may change.
7. Report the exact submitted SMILES, model identifier, property or assay name, value, and units. Preserve missing values and tool errors rather than filling or guessing.
8. Label predictions as model outputs. Separate returned values from interpretation and from any user-provided experimental measurements.
9. Do not infer efficacy, permeability, absorption, safety, brain penetration, or overall candidate quality from LogD, pKa, or any single modeled property alone.
10. If the requested property is unavailable, say so and show the available properties. Do not silently substitute a related property.
11. If the user asks for every available property, select only the models returned by the current `list_available_models` response. Do not expand that request to undocumented ADMET or PK endpoints.
12. Reuse completed predictions already present in the conversation for downstream sorting, grouping, shortlisting, or packaging. Make clear which content is returned by Inductive Bio and which content is assistant-side analysis.
13. Do not imply that the connector has a native export, download, structure-resolution, fragment-generation, correlation, or ranking tool unless live discovery shows one.

## Privacy context

Inductive Bio does not retain submitted chemical structures after a request completes, and the MCP server does not collect user prompts, inputs, or queries. Inductive Bio does not use submitted structures or predictions to train, tune, or improve its models. Access logs are retained only as long as necessary for security, compliance, and internal analytics. Client-side handling by Codex or other software is separate from this policy.

## Scientific interpretation rules

- For pKa-based charge-state discussion, state the pH being considered and keep the conclusion qualitative unless the required assumptions are explicit.
- For brain-exposure discussion, frame LogD as one physicochemical input and identify missing evidence such as size, polarity, ionization, permeability, transporter effects, protein binding, and clearance.
- For passive-absorption discussion, identify missing evidence such as solubility, dissolution, permeability, transporter effects, and metabolic stability.
- For fragment analysis, label the proposed fragments as assistant-generated and do not treat fragment LogD values as additive contributions to whole-molecule LogD.
- For correlations or groupings, report the compounds and properties included, preserve missing results, and describe associations without claiming mechanism or statistical significance that was not evaluated.

Referenced files: 1

View saved version →

---
name: predict-properties
description: Predict currently available molecular properties for one or more exact SMILES with Inductive Bio. Use when the user requests property values for compounds rather than a ranked analog comparison.
---

# Predict molecular properties

Follow the shared requirements in the `index` skill. Do not use this skill without applying those requirements.

## Inputs

Collect:

- A user label and exact SMILES for each compound.
- The requested properties, or permission to show the currently available choices.
- The relevant pH when the user asks about charge state, ionization, absorption, or permeability.

If a structure is identified as confidential, obtain explicit confirmation before sending it to the connector.

If the user supplies compound names without SMILES, resolve each structure from an authoritative source, show the exact SMILES used, and flag stereochemistry, protonation, or salt-form ambiguity. Do not attribute name-to-structure resolution to Inductive Bio's connector.

## Workflow

1. Call `list_available_models`.
2. Match the requested properties to the returned model identifiers, property or assay names, and units. If the request is ambiguous, present the matching choices before predicting.
3. Call `predict_properties` using the exact live MCP schema, the exact submitted SMILES, and only selected model identifiers returned by model discovery.
4. Read the per-call SMILES and model-id limits from the live `predict-properties` tool schema/description and split large inputs into batches that fit those limits, preserving input order and labels. Do not hardcode specific limit values, since they are set server-side and may change.
5. Return a compact table with one row per compound and property. Include label, exact SMILES, model identifier, property or assay, predicted value, units, and status.
6. Add a short interpretation section only when useful. Keep predictions distinct from experimental data and state material limitations.

## Supported analysis patterns

- **Named compound sets:** use the same selected model for every structure, preserve the input order and labels, then sort only when the user requests it. Show the exact resolved SMILES in the output.
- **Charge state from pKa:** report acidic and basic predictions separately, identify likely ionizable groups as assistant interpretation, state the pH under discussion, and keep the charge-state conclusion qualitative.
- **LogD-informed brain exposure:** identify the compounds most compatible with the requested single-property heuristic, but explicitly decline to call LogD a brain-permeability prediction. Name the additional evidence required.
- **pKa-informed passive absorption:** discuss how ionization could affect passive absorption at the stated pH while making clear that pKa alone does not predict oral absorption or bioavailability.
- **Combined LogD and pKa:** place the returned properties side by side, describe tensions or hypotheses, and list missing assays rather than issuing a development recommendation.
- **Fragment-level LogD:** propose chemically intelligible fragment SMILES, label them as assistant-generated, predict the parent and fragments with the same live model, and explain that fragment values are not additive and cannot uniquely assign the parent property's cause.

Referenced files: 1