ImmunoGraph MCP

generate_report

Read-onlyIdempotent

Renders an approved report snapshot into JSON or CSV artifacts after evidence review, returning inline file bytes with lengths and SHA-256 hashes for provenance-aware reporting.

Instructions

Render the supplied approved report snapshot into requested JSON, Markdown, or CSV artifacts. Use after evidence review when a report is needed; export_candidates is for candidate rows and export_research_package is for a ZIP. Returns inline file bytes with lengths and SHA-256 hashes; it does not independently fetch evidence.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`outputFormats`	Yes	File formats to render from the supplied report snapshot.
`idempotencyKey`	Yes	Caller-supplied stable key for repeatable export identity.
`reportSnapshot`	No	Caller-supplied approved report data to render; no evidence retrieval occurs.
`templateVersion`	Yes	Version of the report layout used to render artifacts.

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.

Changed7 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 / outputFormats / description

Added value: +"File formats to render from the supplied report snapshot."

addedInput schema / properties / reportSnapshot / description

Added value: +"Caller-supplied approved report data to render; no evidence retrieval occurs."

addedInput schema / properties / reportSnapshot / properties / candidates / description

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

addedInput schema / properties / runId / description

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

addedInput schema / properties / templateVersion / description

Added value: +"Version of the report layout used to render artifacts."

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 safety is covered; the description adds genuinely new behavior: bytes are returned inline with lengths and SHA-256 hashes, and the tool does not independently fetch evidence. It stops short of mentioning payload size limits or what happens on an idempotency key conflict, 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 sentences, front-loaded with the action, then usage routing, then return behavior. No filler and each sentence carries distinct information.

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 annotations, a full output schema, and 100% schema coverage, the description only needs to add routing and scope, which it does, including the explicit "no evidence retrieval" boundary. The incomplete story is the format list disagreeing with the enum, leaving a small correctness gap.

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 baseline is 3, and the description adds little parameter-level detail beyond naming output formats. The one added detail is wrong: the description advertises Markdown while outputFormats only allows JSON and CSV, which could lead an agent to request an invalid format.

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 (render) and resource (approved report snapshot) plus the resulting artifact types, and explicitly distinguishes itself from export_candidates and export_research_package by what those return. An agent can pick the right export tool without opening any schema.

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

Usage Guidelines5/5

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

"Use after evidence review when a report is needed" gives an explicit precondition and trigger, and the sentence names both alternatives with their distinguishing outputs (candidate rows vs. ZIP). That is the when-to-use/when-not/alternatives triad in two clauses.

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

Deploy Server