ImmunoGraph MCP

run_agentic_workflow

Read-onlyIdempotent

Execute caller-supplied approved typed tool calls in bounded stage order, or return a plan when no calls are provided. Approval gates pause the workflow until the caller approves.

Instructions

Execute caller-supplied approved typed toolCalls in bounded stage order, or return a plan if no calls are supplied. Use when the client has already selected inputs and allowed tools; describe_agentic_workflow only inspects the manifest. The tool does not autonomously invent calls, and approval gates pause rather than self-approve.

Input Schema

Name	Required	Description
`runId`	Yes	Caller-chosen identifier linking this call to one research run.
`agentMode`	Yes	Choose deterministic policy execution or an enabled LLM-assisted mode.
`objective`	Yes	Research objective supplied by the caller to label the bounded workflow.
`toolCalls`	No	Typed, caller-selected tool invocations to execute in stage order.
`approvedToolNames`	Yes	Exact tool names the caller permits this workflow to invoke.
`requireHumanApproval`	Yes	Pause at gated workflow stages until the caller supplies approval.

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

Added value: +"Choose deterministic policy execution or an enabled LLM-assisted mode."

addedInput schema / properties / approvedToolNames / description

Added value: +"Exact tool names the caller permits this workflow to invoke."

addedInput schema / properties / objective / description

Added value: +"Research objective supplied by the caller to label the bounded workflow."

addedInput schema / properties / requireHumanApproval / description

Added value: +"Pause at gated workflow stages until the caller supplies approval."

addedInput schema / properties / runId / description

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

addedInput schema / properties / toolCalls / description

Added value: +"Typed, caller-selected tool invocations to execute in stage order."

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

A3.9/5.0

Behavior4/5

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

Adds substantive behavior beyond the annotations: no autonomous tool invention, approval gates pause instead of self-approving, and a plan-only outcome when toolCalls is empty. That is real operational context. Residual gap: with readOnlyHint=true declared, the description never clarifies whether delegated toolCalls (e.g. export/generate siblings) produce side effects, which is the risk an agent most needs resolved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler, with the core execute-or-plan behavior front-loaded and the sibling differentiation last. Dense but readable; a short gloss on "bounded stage order" would have made it tighter still.

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?

Output schema exists, so return values need not be explained, and the description covers modes, gating, and non-autonomy for a 6-parameter orchestrator. What remains thin is failure behavior and the exact meaning of stage bounding, plus the unresolved side-effect question raised by readOnlyHint.

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%, so every parameter is already described in the schema, making 3 the baseline. The description does add one genuinely useful semantic — an empty toolCalls array yields a plan rather than execution — but says nothing about agentMode, approvedToolNames enforcement, or the 46-item call cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ("Execute caller-supplied approved typed toolCalls in bounded stage order") and adds the fallback mode ("or return a plan if no calls are supplied"), so the dual behavior is unambiguous. It also contrasts itself with describe_agentic_workflow, which only inspects the manifest. The only softness is jargon ("bounded stage order") that isn't unpacked.

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 when the client has already selected inputs and allowed tools" gives an explicit precondition, and the next clause routes the agent to the correct sibling for manifest inspection. No explicit wrong-case exclusion beyond that, but the gating condition is clear enough to select between the two orchestration tools.

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

Deploy Server