ImmunoGraph MCP

apply_constraint_rules

Read-onlyIdempotent

Applies base, duplicate, and overlap rules to an immutable candidate snapshot, returning final outcomes bound to the snapshot hash for provenance-aware epitope decisions.

Instructions

Apply base, duplicate, and overlap rules to one immutable candidate snapshot and return final rule outcomes. Use after validate_thresholds, remove_duplicate_candidates, and detect_overlapping_epitopes when their inputs are ready. The snapshot hash binds the decision to supplied evidence; this tool does not fetch new evidence.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`snapshotHash`	Yes	SHA-256 identity of the immutable evidence snapshot.
`baseConstraints`	Yes	Previously evaluated base rule inputs for final constraint application.
`overlapThreshold`	Yes	Minimum overlap fraction used by the final overlap rule.
`overlapCandidates`	Yes	Candidate records whose positional overlaps enter final constraint rules.
`ruleProfileVersion`	Yes	Version of the biological constraint rule profile.
`duplicateCandidates`	Yes	Candidate records to evaluate for exact positional duplication.

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.

Changed14 schema fields changedv0.2.1Oct 31, 2026

addedInput schema / properties / baseConstraints / description

Added value: +"Previously evaluated base rule inputs for final constraint application."

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

addedInput schema / properties / duplicateCandidates / description

Added value: +"Candidate records to evaluate for exact positional duplication."

addedInput schema / properties / duplicateCandidates / items / properties / candidateType / description
```
Added value: +"MHC class or candidate category this operation applies to."
```
addedInput schema / properties / duplicateCandidates / items / properties / proteinHash / description
```
Added value: +"SHA-256 identity of the protein sequence associated with these candidates."
```

addedInput schema / properties / overlapCandidates / description

Added value: +"Candidate records whose positional overlaps enter final constraint rules."

addedInput schema / properties / overlapCandidates / items / properties / candidateKey / description
```
Added value: +"Stable key identifying one epitope candidate across evidence stages."
```
addedInput schema / properties / overlapCandidates / items / properties / candidateType / description
```
Added value: +"MHC class or candidate category this operation applies to."
```
addedInput schema / properties / overlapCandidates / items / properties / proteinHash / description
```
Added value: +"SHA-256 identity of the protein sequence associated with these candidates."
```

addedInput schema / properties / overlapThreshold / description

Added value: +"Minimum overlap fraction used by the final overlap rule."

addedInput schema / properties / ruleProfileVersion / description

Added value: +"Version of the biological constraint rule profile."

addedInput schema / properties / runId / description

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

addedInput schema / properties / snapshotHash / description

Added value: +"SHA-256 identity of the immutable evidence snapshot."

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.4/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/idempotency profile is covered. The description adds real context beyond that: the snapshot hash binds the decision to supplied evidence and the tool performs no data fetching, clarifying that this is a pure deterministic evaluation over provided inputs.

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 sentences, each earning its place: purpose, prerequisites/ordering, and a scope/immutability constraint. The key information (what it does) is front-loaded with no filler.

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 need not be explained, and the schema is fully documented. The description supplies the pipeline context and immutability/no-fetch semantics needed to call it correctly; only edge behavior on rule failure is unmentioned.

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 description coverage is 100%, so the schema already documents all seven parameters and baseline is 3. The description goes beyond it by explaining the semantic role of snapshotHash (binding the decision to supplied evidence) and by framing the three candidate arrays as the rule inputs for a single snapshot.

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 (apply), the exact rule set (base, duplicate, overlap), and the scope (one immutable candidate snapshot returning final rule outcomes). It is clearly distinguishable from the three sibling tools it consumes, since this is the terminal aggregation step rather than a detection/validation step.

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?

Explicitly states the prerequisite tool sequence: use after validate_thresholds, remove_duplicate_candidates, and detect_overlapping_epitopes when their inputs are ready. It also sets a negative scope boundary ('does not fetch new evidence'), though it doesn't say what to do if prerequisites are unmet.

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

Deploy Server