ImmunoGraph MCP

validate_docking_box

Read-onlyIdempotent

Validates the center, edge lengths, and volume of a proposed docking search box before docking so invalid geometry is caught and downstream runs avoid failure.

Instructions

Validate the center and size of a proposed docking search box and calculate its volume. Use before run_docking to catch invalid box geometry; this does not run Vina or establish a binding site. Returns validated dimensions or a structured validation failure.

Input Schema

Name	Required	Description
`size`	Yes	Docking-box edge lengths x, y, and z in angstroms.
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`center`	Yes	Docking-box center coordinates x, y, and z in angstroms.
`dockingBoxId`	Yes	Caller-chosen identifier for the validated docking search box.

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 / center / description

Added value: +"Docking-box center coordinates x, y, and z in angstroms."

addedInput schema / properties / dockingBoxId / description

Added value: +"Caller-chosen identifier for the validated docking search box."

addedInput schema / properties / runId / description

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

addedInput schema / properties / size / description

Added value: +"Docking-box edge lengths x, y, and z in angstroms."

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.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds real context on top: it is a pre-flight check, it does not invoke Vina or claim a binding site, and it returns either validated dimensions or a structured validation failure. It stops short of describing failure semantics in detail, which keeps it at 4 rather than 5.

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?

Two sentences, no filler, with the primary action front-loaded and the boundary condition second. Every clause carries decision-relevant information.

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

Completeness5/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 structure need not be spelled out, and the description still signals validated dimensions vs. structured failure. For a 4-param read-only validator, nothing an agent needs in order to call it correctly is missing.

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% and nested center/size objects are documented with units in angstroms, so the schema carries parameter meaning. The description references center and size but says nothing about runId or dockingBoxId, so it adds no semantics beyond the schema; 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 resource (validate the center and size of a docking search box) plus a secondary output (volume). It explicitly distinguishes itself from run_docking, so an agent can separate it from the heavy docking sibling without opening either schema.

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 when ('before run_docking to catch invalid box geometry') and an explicit what-it-is-not ('does not run Vina or establish a binding site'), which names the sibling it must not be confused with and rules out the main misuse.

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

Deploy Server