ImmunoGraph MCP

deduplicate_compounds

Read-onlyIdempotent

Collapse duplicate chemical identities by comparing supplied compounds via RDKit canonical SMILES and InChIKey, returning canonical groups. Use after validation; not for epitope-position duplicates.

Instructions

Compare supplied compounds by RDKit canonical isomeric SMILES and InChIKey when live chemistry is requested. Use after validate_compound to collapse chemical identity duplicates; this is distinct from remove_duplicate_candidates, which handles epitope positions. Returns canonical groups and preserves input provenance.

Input Schema

Name	Required	Description	Default
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`compounds`	Yes	Compound records to compare by canonical chemical identity.

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

Added value: +"Compound records to compare by canonical chemical identity."

addedInput schema / properties / compounds / items / properties / compoundId / description
```
Added value: +"Stable identifier for the supplied compound within this run."
```
addedInput schema / properties / compounds / items / properties / smiles / description
```
Added value: +"Chemical structure encoded as a SMILES string."
```
addedInput schema / properties / compounds / items / properties / sourceStatus / description
```
Added value: +"Provenance label for the supplied structure or compound."
```

addedInput schema / properties / runId / description

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

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

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered; the description adds real value by disclosing the comparison keys, that output is canonical groups, and that input provenance is preserved. It also flags a dependency on live chemistry, which is behavioral context not present in annotations. It doesn't state what happens if the live chemistry call fails, leaving a small gap.

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 compact clauses with zero filler: the mechanism, the ordering/alternative guidance, and the return/provenance behavior. The distinguishing information against the sibling is front-loaded rather than buried.

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 needn't be explained, and the description nonetheless signals canonical groups plus provenance preservation. For a two-parameter read-only tool this is nearly sufficient; only the failure/fallback behavior of the live-chemistry path is left implicit.

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 both runId and compounds (including sourceStatus and smiles) are already documented. The description's mention of preserving input provenance lightly reinforces sourceStatus and canonicalization, but adds no syntax, format, or constraint detail 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 (compare/collapse duplicates) plus resource (compounds) and names the matching criteria (RDKit canonical isomeric SMILES and InChIKey). It explicitly names the sibling it is not — remove_duplicate_candidates, which handles epitope positions — so the agent can disambiguate without opening schemas.

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?

Gives an explicit sequencing instruction ("Use after validate_compound") and a condition ("when live chemistry is requested"), plus a clear boundary against remove_duplicate_candidates. It stops short of saying what to do when live chemistry is unavailable or when inputs are already known-unique, so it is strong but not fully exhaustive.

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

Deploy Server