ImmunoGraph MCP

create_molstar_view

Read-onlyIdempotent

Package protein and optional ligand PDB coordinates into an interactive Mol* HTML viewer for 3D visualization after structure or docking work; returns HTML bytes loading Mol* from a CDN.

Instructions

Package supplied protein and optional ligand PDB coordinates into an interactive Mol* HTML viewer, or return an exact fixture reference. Use when a client needs a 3D visualization after structure or docking work; this does not calculate a new pose. Returns HTML bytes whose viewer loads its library from a CDN.

Input Schema

Name	Required	Description
`mode`	Yes	Execution or visualization mode; inspect enum choices and required inputs for each.
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`viewId`	Yes	Caller-chosen identifier for the generated Mol* view.
`ligandPdbBase64`	No	Base64-encoded ligand PDB coordinates to embed in a 3D view.
`ligandArtifactRef`	No	Reference identifying the ligand coordinate artifact represented in the view.
`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.

Changed8 schema fields changedv0.2.1Oct 31, 2026

addedInput schema / properties / ligandArtifactRef / description

Added value: +"Reference identifying the ligand coordinate artifact represented in the view."

addedInput schema / properties / ligandPdbBase64 / description

Added value: +"Base64-encoded ligand PDB coordinates to embed in a 3D view."

addedInput schema / properties / mode / description

Added value: +"Execution or visualization mode; inspect enum choices and required inputs for each."

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

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

addedInput schema / properties / viewId / description

Added value: +"Caller-chosen identifier for the generated Mol* view."

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.0

Behavior4/5

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

With readOnlyHint and idempotentHint already set, the description adds meaningful context: output is HTML bytes and the viewer loads its library from a CDN, a network dependency. It also notes the optional ligand and fixture-reference alternative, though it does not explain when that alternative is returned.

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 front-loaded sentences with no filler; the scope and exclusion are stated up front. The fixture-reference phrase is slightly opaque but does not bloat the description.

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 and annotations cover the side-effect profile, so the description need not explain return values in detail. However, the unexplained 'fixture reference' fallback leaves a behavioral branch underspecified for an otherwise complete definition.

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 the schema already documents all seven parameters and the mode enum. The description only restates protein/ligand coordinates and does not clarify artifactRef versus base64 inputs or mode-specific requirements.

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

Purpose4/5

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

The description states a specific verb ('Package') and resource ('protein and optional ligand PDB coordinates into an interactive Mol* HTML viewer') and explicitly excludes pose calculation. It does not name or contrast the closest visualisation sibling, visualize_results, so sibling differentiation is incomplete.

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

Usage Guidelines4/5

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

It gives a clear usage context ('after structure or docking work') and an exclusion ('this does not calculate a new pose'). It stops short of naming alternatives or prerequisites such as the required runId and viewId, so it is not a 5.

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

Deploy Server