ImmunoGraph MCP

remove_duplicate_candidates

Read-onlyIdempotent

Groups candidates with identical positional identity, selects canonical records, and returns duplicate relationships before constraint-rule application without altering source evidence.

Instructions

Group candidates with identical positional identity and choose canonical records. Use before apply_constraint_rules to remove true duplicates; identical peptide strings at different coordinates remain separate. Returns canonical and duplicate relationships without changing source evidence.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`candidates`	Yes	Caller-supplied candidate records; required nested fields depend on this operation.
`proteinHash`	Yes	SHA-256 identity of the protein sequence associated with these candidates.

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

Added value: +"Caller-supplied candidate records; required nested fields depend on this operation."

addedInput schema / properties / candidates / items / properties / candidateType / description
```
Added value: +"MHC class or candidate category this operation applies to."
```

addedInput schema / properties / proteinHash / description

Added value: +"SHA-256 identity of the protein sequence associated with these candidates."

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.3/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 reinforces them with "without changing source evidence" plus the fact that results are returned as canonical/duplicate relationships rather than applied. The disjointness rule (same peptide, different coordinates stays separate) is real behavioral information not derivable from annotations. It doesn't warn about any scale or ordering caveats, so not 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: what it does, when to use it and the key exclusion, then what it returns and does not mutate. Front-loaded with the core action and zero filler.

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?

Read-only/idempotent annotations cover the safety profile, the output schema covers return values, and the schema fully documents all three parameters. The description supplies the remaining gaps an agent actually needs: the dedup key, the sequencing relative to apply_constraint_rules, and the non-mutation guarantee.

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 runId, proteinHash and candidates are already documented in the schema, and baseline is 3. The phrase "positional identity" hints that start/end coordinates are the grouping key and "identical peptide strings" ties to the peptide field, but no parameter is named or clarified beyond that.

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 pair (group and choose canonical) on a specific resource (candidates) with the deduplication key named: identical positional identity. That key distinguishes it from the sibling deduplicate_compounds and from the broader apply_constraint_rules without either schema being opened.

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?

"Use before apply_constraint_rules" gives explicit ordering and names the downstream sibling, and "identical peptide strings at different coordinates remain separate" defines a scope exclusion so the agent won't over-deduplicate. It stops short of naming a competing dedup alternative or stating failure conditions, so it is strong context rather than a complete when/when-not guide.

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

Deploy Server