ImmunoGraph MCP

export_workflow_trace

Read-onlyIdempotent

Serialize ordered workflow events into a redacted JSON trace for post-run audit or reproducibility, returning inline bytes and SHA-256 metadata while omitting secrets and private reasoning.

Instructions

Serialize supplied ordered workflow events into a redacted JSON trace artifact. Use for audit or reproducibility after a workflow; generate_report is for the scientific summary. Returns inline bytes and SHA-256 metadata while omitting secrets and private reasoning.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`traceEvents`	No	Ordered caller-supplied events to serialize after redaction.
`idempotencyKey`	Yes	Caller-supplied stable key for repeatable export identity.
`redactionProfile`	Yes	Named policy for omitting private trace content from export.

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

Added value: +"Caller-supplied stable key for repeatable export identity."

addedInput schema / properties / redactionProfile / description

Added value: +"Named policy for omitting private trace content from export."

addedInput schema / properties / runId / description

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

addedInput schema / properties / traceEvents / description

Added value: +"Ordered caller-supplied events to serialize after redaction."

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, and the description adds genuinely new behavioral facts: the artifact contains inline bytes plus SHA-256 metadata, and secrets/private reasoning are omitted. It does not state size limits or what happens when traceEvents is empty/omitted, but the redaction and identity behavior are real added value.

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 tight sentences: purpose first, routing second, return/redaction behavior last. No filler and nothing repeated from the schema verbatim.

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 need not be explained, and the safety profile is covered by annotations; the description still adds the redaction and digest guarantees an agent needs to trust the artifact. Minor gaps like handling of an empty or omitted traceEvents are the only omissions.

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 coverage is 100% and every parameter carries its own description, so the schema does the heavy lifting. The description reinforces the 'supplied ordered' nature of traceEvents and the redaction intent behind redactionProfile, but adds no format or constraint detail beyond the schema.

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 artifact ('Serialize ... into a redacted JSON trace artifact') plus the input resource (ordered workflow events). It explicitly contrasts with generate_report, so an agent can distinguish the two without reading 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?

'Use for audit or reproducibility after a workflow' gives a clear triggering context and the alternative 'generate_report is for the scientific summary' routes the agent away from the wrong sibling. It stops short of naming other nearby siblings such as export_research_package or export_candidates.

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

Deploy Server