ImmunoGraph MCP

prepare_ligand

Read-onlyIdempotent

Generates 3D SDF and Meeko PDBQT files from a SMILES string for docking, or returns an exact fixture reference when live preparation is unavailable.

Instructions

Generate a 3D SDF and Meeko PDBQT from supplied SMILES using configured RDKit and Meeko, or return an exact fixture reference. Use before run_docking for a ligand; calculate_molecular_descriptors does not produce docking coordinates. Live preparation returns artifact bytes and hashes and fails if a required runtime is absent.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`smiles`	Yes	Chemical structure encoded as a SMILES string.
`compoundId`	Yes	Stable identifier for the supplied compound within this run.
`preparationMethod`	Yes	Preparation backend, such as configured Meeko or exact fixture mode.

Output Schema

Name	Required	Description
`ok`	Yes	Whether execution completed successfully.
`data`	No	Tool-specific result fields on success.
`meta`	Yes	Run identifiers, timings, and input/output hashes.
`error`	No	Structured failure on unsuccessful execution.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.1Oct 31, 2026

addedInput schema / properties / compoundId / description

Added value: +"Stable identifier for the supplied compound within this run."

addedInput schema / properties / preparationMethod / description

Added value: +"Preparation backend, such as configured Meeko or exact fixture mode."

addedInput schema / properties / runId / description

Added value: +"Caller-chosen identifier linking this call to one research run."

addedInput schema / properties / smiles / description

Added value: +"Chemical structure encoded as a SMILES string."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "data": {
+      "additionalProperties": {},
+      "description": "Tool-specific result fields on success.",
+      "properties": {},
+      "type": "object"
+    },
+    "error": {
+      "additionalProperties": false,
+      "description": "Structured failure on unsuccessful execution.",
+      "properties": {
+        "category": {
+          "type": "string"
+        },
+        "code": {
+          "type": "string"
+        },
+        "details": {
+          "additionalProperties": {},
+          "properties": {},
+          "type": "object"
+        },
+        "message": {
+          "type": "string"
+        },
+        "retryable": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "code",
+        "category",
+        "message",
+        "retryable"
+      ],
+      "type": "object"
+    },
+    "meta": {
+      "additionalProperties": {},
+      "description": "Run identifiers, timings, and input/output hashes.",
+      "properties": {
+        "completedAt": {
+          "type": "string"
+        },
+        "durationMs": {
+          "type": "number"
+        },
+        "inputHash": {
+          "type": "string"
+        },
+        "outputHash": {
+          "type": "string"
+        },
+        "requestId": {
+          "type": "string"
+        },
+        "runId": {
+          "type": "string"
+        },
+        "startedAt": {
+          "type": "string"
+        },
+        "toolName": {
+          "type": "string"
+        },
+        "toolVersion": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "requestId",
+        "runId",
+        "toolName",
+        "toolVersion",
+        "startedAt",
+        "inputHash"
+      ],
+      "type": "object"
+    },
+    "ok": {
+      "description": "Whether execution completed successfully.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok",
+    "meta"
+  ],
+  "type": "object"
+}

First observedv0.2.0Oct 31, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, yet the description still adds real behavior: live preparation returns artifact bytes plus hashes, and it fails when a required runtime is absent. It also discloses the fixture-mode branch that returns a reference instead of computing. It stops short of describing pagination/size limits or how fixture mode is chosen.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: the primary action comes first, then downstream ordering, then failure and return characteristics. Every clause carries information an agent needs and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 spelled out, and the description still flags artifact bytes/hashes and the missing-runtime failure. What remains thin is how the fixture-mode path is selected and whether repeated calls reuse cached artifacts, despite the idempotent hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the preparationMethod backend. The description adds only the input-to-output relationship (SMILES in, SDF/PDBQT out) rather than new meaning for individual parameters, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and concrete resource: generate a 3D SDF and Meeko PDBQT from a SMILES, with a named alternate mode (exact fixture reference). It also differentiates from siblings by naming calculate_molecular_descriptors and run_docking in the same breath.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit ordering rule ("Use before run_docking for a ligand") and explicitly excludes the near-miss sibling ("calculate_molecular_descriptors does not produce docking coordinates"). The agent knows both when to pick this tool and when a plausible alternative is wrong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server