ImmunoGraph MCP

detect_binding_pockets

Read-onlyIdempotent

Run fpocket on supplied PDB coordinates to identify geometric binding pockets or replay a fixture for pocket exploration after structure validation.

Instructions

Run fpocket on supplied PDB coordinates to identify geometric binding pockets, or replay an exact fixture. Use after structure validation for pocket exploration; use run_docking to score a prepared receptor-ligand pair. Live mode needs the fpocket binary and PDB bytes; pocket scores are computational descriptors.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`method`	Yes	Algorithm or provider method selected for this operation; inspect allowed schema values.
`structureId`	Yes	Stable identifier of the supplied or retrieved structure.
`structurePdbBase64`	No	Base64-encoded protein PDB coordinate bytes for direct computation.
`structureArtifactRef`	Yes	Reference identifying the supplied structure-coordinate artifact.

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.

Changed6 schema fields changedv0.2.1Oct 31, 2026

addedInput schema / properties / method / description

Added value: +"Algorithm or provider method selected for this operation; inspect allowed schema values."

addedInput schema / properties / runId / description

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

addedInput schema / properties / structureArtifactRef / description

Added value: +"Reference identifying the supplied structure-coordinate artifact."

addedInput schema / properties / structureId / description

Added value: +"Stable identifier of the supplied or retrieved structure."

addedInput schema / properties / structurePdbBase64 / description

Added value: +"Base64-encoded protein PDB coordinate bytes for direct computation."

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

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered; the description adds the genuinely non-obvious operational requirement that live mode needs the fpocket binary installed plus PDB bytes, and warns that pocket scores are computational descriptors rather than validated affinities. It does not describe failure behavior when the binary is absent or what a fixture replay returns, which keeps it below a 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?

Three short sentences, front-loaded with purpose, then sequencing/alternative, then operational caveat. No filler and no restatement of the tool name or title.

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?

With an output schema present, return values needn't be explained, and the description covers the two modes, the prerequisite step, the runtime dependency, and the interpretive caveat on scores. It leaves minor gaps around which mode is default and how artifact refs behave, but nothing that would cause a mis-call.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by implying conditional parameter needs: 'Live mode needs the fpocket binary and PDB bytes' effectively ties method=fpocket to structurePdbBase64, a dependency the schema does not state. It stops short of naming the parameters or spelling out what the fixture method requires.

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 ('Run fpocket on supplied PDB coordinates to identify geometric binding pockets') and explicitly covers the second operating mode ('replay an exact fixture'). It is clearly distinguishable from the closest sibling, run_docking, which it names by role.

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 sequencing rule ('Use after structure validation for pocket exploration') and an explicit alternative with its selection condition ('use run_docking to score a prepared receptor-ligand pair'). An agent knows both when to pick this tool and when not to.

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

Deploy Server