What can you do with this server?

Use it as a proof-gated, evidence-sealing decision authority for evaluating defensive mutations against a sealed attack scenario. * Adjudicate defensive-mutation episodes by supplying a scenario, baseline replay, and candidates; returns a verdict, winning candidate, gate evidence, sealed scenario hash, Merkle evidence root, and lineage entry. * Verify episode evidence by recomputing the Merkle root to detect any modification to sealed evidence. * Export the session's hash-linked immune lineage with verdict counts and an integrity flag. * Verify an exported lineage link by link, optionally anchoring to an independently retained expected head hash. * Describe the current policy: protocol versions, hash algorithm, gate defaults, input limits, rejection reasons, and the declared absence of side effects. * Reset the session lineage while leaving previously exported reports independently verifiable. * Operate strictly over supplied observations in memory; it does not execute candidates, read files, open sockets, spawn processes, or read environment variables.

How do I use Counterfactual Immune Forge?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Counterfactual Immune Forge adjudicate this defense mutation against the sealed attack scenario" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Counterfactual Immune Forge

by SweetKenneth

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Counterfactual Immune Forge

Proof-gated defense evolution for AI agents and security automation.

When an agent, guardrail, or detection rule is defeated, the tempting next step is to patch it and move on. The Counterfactual Immune Forge refuses to accept a patch from an incomplete observation record. It seals the supplied attack scenario, requires the reported baseline replay to show the current defense failing it, adjudicates each proposed change against that same sealed scenario record, forces every change through a regression gate, requires a positive, policy-defined reported improvement, and then seals the whole decision — including each candidate's identity hashes, observed gate evidence, and any rejection reason — as a SHA-256 Merkle evidence root that anyone can recompute later.

It is a decision authority, not an actuator. It promotes nothing by itself, executes no candidate, reads no files, opens no network sockets, spawns no subprocesses, and reads no environment variables. Its stdio transport necessarily uses the host process's stdin/stdout.

Why a practitioner would install this

Defense changes stop being undocumented trust-me changes. Every PROMOTED verdict carries recomputable evidence of what the caller reported: baseline reproduction, candidate neutralization, protected-behaviour regression status, and score improvement.
Rejection evidence is preserved, not discarded. Candidate IDs/hashes, observed gate results, and rejection reasons remain in the sealed episode — including the "fixed the attack, broke legitimate traffic" case. Keep the original candidate artifact if you need to resolve a mutation/defense hash back to its full body.
The scenario identity cannot move inside the Forge. The scenario is canonicalized and hashed before any candidate is considered. Data-driven baseline and candidate replay observations must claim that same sealed hash; direct adapters receive the same sealed scenario object for every replay.
The audit trail is hash-linked. Every adjudicated episode is appended to an immune lineage whose links are verifiable independently of this server's memory.
Nothing about it is model-dependent. Reasoning about what to try can come from an agent, a fuzzer, a human, or a rules engine. The gates and the sealing are plain deterministic code.

Related MCP server: mcp-nixreview

Protocol

CIF/0.3, in order:

Canonicalize and hash the triggering scenario (sealScenario).
Reproduce the baseline against it. Data-driven baseline evidence must carry the sealed scenario hash. The baseline must both reproduce and report the attack succeeding; otherwise → INCONCLUSIVE and no candidate is evaluated. This proof gate is mandatory in CIF/0.3.
Optionally record a diagnosis. Evidence only — it carries no promotion authority.
Screen each candidate for blast radius before it can earn replay credit.
Require each survivor's supplied replay observation to carry the hash of the same sealed scenario. A missing or mismatched binding fails the replay gate.
Reject any candidate whose own replay still reports the attack succeeding. This proof gate is mandatory in CIF/0.3; a high score cannot buy promotion for a change that did not stop the attack.
Apply the mandatory regression gate over protected behaviour.
Only after the baseline attack is proven, score the baseline and each candidate on the same caller-defined fitness scale, then require a finite candidate score strictly above the explicit baseline fitness plus the configured margin.
Record every candidate's cryptographic identity and gate evidence, including a machine-readable rejection reason when rejected.
Return PROMOTED for at most the single highest-scoring candidate that cleared every gate.
Seal the episode as a Merkle evidence root.
Run optional DREAM exploration after sealing, on the sealed evidence only. It cannot change the verdict or the root.

Rejection reasons: IMPACT_SCREEN_FAILED, SCENARIO_REPLAY_FAILED, ATTACK_NOT_NEUTRALIZED, REGRESSION_GATE_FAILED, NO_PROVEN_IMPROVEMENT. Verdicts: PROMOTED, REJECTED, INCONCLUSIVE.

The effective policy is sealed inside the evidence root. requiredFitnessMargin is configurable and non-negative; requireAttackReproduction and requireAttackNeutralized are recorded as true and cannot be disabled in CIF/0.3, so a reader can see exactly which invariants produced the verdict.

Full behavioural contract: SPEC.md.

Prerequisites

Node.js 20 or newer (node --version). Nothing else — zero runtime dependencies.
An MCP client that speaks stdio (Claude Code, Claude Desktop, Cursor), or direct library use from TypeScript.
No API key, account, network access, or Tenable product is required.

Install and run

git clone https://github.com/SweetKenneth/shpbl-immune-forge.git
cd shpbl-immune-forge
npm install      # devDependencies only: typescript, @types/node
npm run build    # compiles to dist/
npm test         # conformance, tamper, adversarial, and boundary tests
npm start        # starts the MCP server on stdio

MCP client configuration:

{
  "mcpServers": {
    "immune-forge": {
      "command": "node",
      "args": ["/absolute/path/to/shpbl-immune-forge/dist/src/mcp-server.js"]
    }
  }
}

Outputs

Every tool returns JSON text content. adjudicate_defensive_mutation returns the verdict (PROMOTED / REJECTED / INCONCLUSIVE), the winning candidate ID if any, each candidate's mutation/defense hashes and gate observations, machine-readable rejection reasons, the sealed scenario hash, the SHA-256 Merkle evidence root, and the appended lineage entry. verify_episode_evidence reports internal CIF/0.3 evidence semantic-and-hash consistency; verify_immune_lineage reports CIF-LINEAGE/0.1 entry-semantic and chain-hash consistency. Both can optionally compare against an independently retained expected evidence root / lineage head. export_immune_lineage_report returns the hash-linked lineage plus verdict counts, and describe_policy returns the versions, thresholds, input limits, and rejection-reason vocabulary in force. Nothing is written to disk and nothing is sent anywhere — the caller keeps whatever it chooses to keep.

MCP tools

Tool	What it does
`adjudicate_defensive_mutation`	Adjudicates one episode from recorded observations and returns sealed evidence plus a lineage entry.
`verify_episode_evidence`	Recomputes an episode's Merkle root; optionally anchors it to an independently retained expected root.
`export_immune_lineage_report`	Exports the hash-linked lineage of this session with verdict counts and an integrity flag.
`verify_immune_lineage`	Verifies lineage links and can optionally require an independently retained expected head hash.
`describe_policy`	Publishes protocol versions, hash algorithm, gate defaults, input limits, and the no-side-effect declaration.
`reset_state`	Clears session lineage. Previously exported reports stay independently verifiable.

The MCP surface is data-driven: your own harness runs the attack and the regression suite and reports what it observed. Both baseline and candidate replay observations must include the sealed scenario hash returned by sealScenario; this binds the reporter's claim to the episode but does not prove that an external harness was honest. The Forge enforces the gates over those observations. Missing evidence is always a failed gate, never a pass. Library users who want the Forge to drive their harness directly can implement ForgeAdapters and call CounterfactualImmuneForge.run().

Library use

import { adjudicateEpisode, sealScenario, verifyEvidenceRoot } from "shpbl-counterfactual-immune-forge";

const scenario = {
  kind: "prompt-injection",
  payload: { vector: "tool-arg" },
  expectedSecurityProperty: "refuse untrusted tool instruction",
};
const scenarioId = sealScenario(scenario).id!;

const evidence = await adjudicateEpisode({
  scenario,
  baseline: { id: "guard", version: "1.0.0" },
  baselineReplay: { scenarioId, reproduced: true, attackSucceeded: true, securityScore: 0.2 },
  baselineFitness: 0.2,
  candidates: [{
    mutation: { id: "quarantine", description: "quarantine tool-sourced instructions", patch: { rule: "quarantine" } },
    defense: { id: "guard", version: "1.1.0" },
    impact: { safe: true, reasons: [] },
    replay: { scenarioId, reproduced: true, attackSucceeded: false, securityScore: 0.95 },
    regression: { passed: true, failures: [] },
    fitnessScore: 0.95,
  }],
});

evidence.verdict;              // "PROMOTED"
verifyEvidenceRoot(evidence);  // true

Threat model and misuse boundary

Protects against silent defense regressions, unproven "fixes", moved goalposts, and post-hoc editing of what a promotion was based on.
Does not protect against an operator who ignores the verdict, or a harness that reports observations dishonestly. Garbage in is sealed as garbage — verifiably, and attributable to the reporter.
Refuses application-level filesystem reads/writes, network sockets, subprocess spawning, and environment-variable reads, so it cannot be repurposed as an offensive or surveillance tool. The stdio transport uses only stdin/stdout. It never generates exploits and never applies changes to a live system.
Input limits are published by describe_policy: 256 candidates per episode, 10,000 lineage entries per session/export/verification, 1 MiB per request, 32 levels of JSON nesting, and rejection of cyclic, non-finite, or unknown-verdict values. Duplicate observations of one mutation/defense pair and duplicate explicit mutation IDs are refused rather than collapsed, and requests are answered strictly in arrival order.

Honest limitations

It is not an autonomous security oracle. It adjudicates the evidence it is given; it does not decide what is worth defending.
A compromised evaluator — a rigged harness or a fitness function that rewards the wrong thing — produces sealed evidence of a bad decision. Sealing proves integrity, not wisdom.
Fitness semantics are yours. Once the baseline attack is proven, the data-driven API requires an explicit baselineFitness, and direct adapters provide baselineFitness(), so the baseline and candidate scores share the evaluator-defined scale. Inconclusive baselines never invoke or require fitness scoring. The Forge enforces only "strictly better than baseline, by at least the configured margin".
Session lineage is in memory. Persist exported reports yourself if you need durable history.
Evidence/lineage verification without an independently retained expected root/head proves internal protocol-and-hash consistency, not historical authenticity: someone who can replace both an artifact and its embedded hash can recompute a new self-consistent artifact. Supply expectedRoot / expectedHeadHash when you need an external anchor.
Verification never proves the reported observations were true.
Episode evidence stores candidate IDs plus mutation/defense hashes, not full candidate bodies. Retain the original candidate definitions if later review must inspect their exact patch/state content.

Provenance

Invented and specified by SHPBL (Kenneth E. Sweet Jr.). This repository is a clean-room implementation written from the public behavioural specification in SPEC.md; no proprietary SHPBL library bodies are included. The Forge composes ideas SHPBL had already proven separately — replay, sandboxed impact screening, regression authority, evolutionary scoring, evidence sealing, and post-proof exploration — into one gate chain where none of them can be skipped.

More SHPBL security tooling: https://shpbl.com/tenable-submissions

Tenable status

Submitted to the Tenable CyberAgents Exchange on September 12, 2026 and initially merged as pull request #169. Tenable later removed the listing in pull request #187 during its post-merge review. The listing is not currently published by the Exchange. Version 0.2.0 closed the original candidate-neutralization defect; version 0.2.1 added transport and submission-structure hardening; version 0.3.0 closes additional baseline-qualification, replay-binding, policy-margin, candidate-identity, immutability, lineage-state, and verification-anchor gaps found during adversarial review. Past or future listing status does not imply review, approval, certification, validation, or endorsement of this software by Tenable.

License

MIT — see LICENSE. Zero runtime dependencies; Node.js 20+.

Available Tools

6 tools

adjudicate_defensive_mutationA

Adjudicate one defensive-mutation episode from recorded observations: impact screen, same-scenario replay, mandatory regression gates and positive fitness delta, then seal the decision as a Merkle evidence root. Executes nothing and promotes nothing on its own.

ParametersJSON Schema

Name	Required	Description	Default
`policy`	No
`baseline`	Yes
`scenario`	Yes
`diagnosis`	No
`candidates`	No
`baselineReplay`	Yes
`baselineFitness`	No

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the internal evaluation stages—impact screen, same-scenario replay, mandatory regression gates, positive fitness delta—and explicitly states the tool 'Executes nothing and promotes nothing on its own.' It also reveals that a Merkle evidence root is produced. This is substantial transparency for a non-annotated tool.

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?

The description is a single dense sentence that front-loads the core action and then lists the evaluation criteria. It is appropriately sized and contains no filler, though the long colon-list structure makes it slightly heavy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations, an output schema, and any parameter-level documentation, this description is too incomplete for an agent to safely invoke the tool. It gives a good process overview but omits required-input semantics, expected outputs, and the meaning of key fields like policy, diagnosis, and baselineFitness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description does not explain any parameter names or required inputs. It references high-level concepts like 'impact' and 'replay,' which map loosely to schema fields such as impact, replay, and baselineReplay, but it does not clarify scenario, baseline, candidates, policy, fitnessScore, or baselineFitness. This is insufficient for a tool with seven nested parameters.

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?

The description opens with a specific verb and resource: 'Adjudicate one defensive-mutation episode from recorded observations.' It then enumerates the exact adjudication steps and distinguishes itself from siblings by noting it 'Executes nothing and promotes nothing on its own,' which clearly separates adjudication from execution and promotion.

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

Usage Guidelines3/5

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

The purpose is clear enough to imply when this tool should be used: when a defensive-mutation episode needs adjudication. However, it does not explicitly mention alternative tools such as verify_episode_evidence or explain when to prefer this over them, so usage guidance is left mostly to inference.

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

describe_policyA

Return the protocol versions, hash algorithm, default gate thresholds, input limits, rejection reasons and the declared absence of side effects.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool reports policy details including a "declared absence of side effects," which adds useful context, but it does not explicitly state whether the tool itself is read-only, what permissions are needed, or how the information is returned.

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?

The description is a single front-loaded sentence that enumerates the returned policy details without filler or redundancy. Every listed item appears intended to help an agent understand the tool's output.

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 no output schema and no annotations, the description is the primary specification. It lists the returned policy fields comprehensively enough for a no-argument informational tool, though it could specify format or scope more fully.

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?

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to explain. Per the baseline for zero-parameter tools, this dimension is appropriately scored 4.

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?

The description uses a specific verb, "Return," and enumerates the policy details returned: protocol versions, hash algorithm, gate thresholds, input limits, rejection reasons, and side-effect declaration. This clearly identifies an informational tool, though it does not explicitly differentiate from the verification/reset/export siblings beyond its read-only inventory purpose.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, when not to use it, or which alternatives exist. Usage is only weakly implied by the name and by the fact that it returns policy metadata.

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

export_immune_lineage_reportB

Export the hash-linked lineage of every episode adjudicated in this session, with verdict counts and an integrity flag.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations at all, the description carries the full behavioral burden. It usefully discloses scope (only episodes adjudicated in this session) and output contents (lineage, verdict counts, integrity flag), but omits export format, whether the operation is read-only/safe, required permissions, and any rate or size limits.

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?

A single tight sentence that front-loads the action and scope, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, no-output-schema export tool, the description partially compensates by naming the returned data (lineage, counts, integrity flag). It still leaves format, permissions, and failure/precondition behavior unspecified, so an agent lacks enough to call it confidently in edge cases.

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?

The tool takes zero parameters, so there are no parameter semantics to document; the baseline for a 0-param tool is 4. The description instead clarifies what the parameterless export returns, which is the only meaningful semantic context available.

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?

States a specific verb ("Export") and a well-scoped resource ("the hash-linked lineage of every episode adjudicated in this session"), and previews the payload (verdict counts, integrity flag). It is distinguishable from the sibling verify_immune_lineage, though it doesn't explicitly frame the contrast (export a report vs. verify lineage).

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

Usage Guidelines2/5

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

The "in this session" phrasing implies this is a post-adjudication reporting step, but there is no explicit when-to-use guidance, no prerequisites (e.g. must episodes be adjudicated first?), and no mention of alternatives such as verify_immune_lineage or describe_policy.

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

reset_stateB

Clear this session's lineage. Previously exported reports remain independently verifiable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description must carry the full burden. It usefully discloses that previously exported reports remain independently verifiable, which is a non-obvious side-effect guarantee. However, it does not state whether the reset is destructive, reversible, or permission-gated.

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?

Two short sentences, front-loaded with the action and followed by the key post-condition. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-resetting operation with no annotations and no output schema, the description should clarify destructiveness, reversibility, and required permissions. The exported-report note is valuable, but core behavioral details are missing.

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?

The tool takes zero parameters, so the baseline is 4. The schema is empty and fully covered, and there are no parameter semantics for the description to clarify.

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?

The description states a specific verb and resource: 'Clear this session's lineage.' It is clear enough to distinguish from export/verify siblings, but it does not explicitly name alternatives or scope the operation against them.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool vs. the sibling lineage tools, no prerequisites, and no exclusions. The description merely states the action without context for selecting it.

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

verify_episode_evidenceA

Recompute the Merkle evidence root of a sealed episode. Optionally compare it to an independently retained expected root; without one, verification proves internal consistency only.

ParametersJSON Schema

Name	Required	Description	Default
`evidence`	Yes
`expectedRoot`	No

TDQS

A4.1/5.0

Behavior4/5

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

The description discloses that verification without an expected root only proves internal consistency, which is a meaningful behavioral caveat. However, it does not mention side effects, performance implications, or whether the tool mutates state, though the name suggests a read-only verification.

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?

The description is concise and front-loaded, with the core action stated first and the optional behavior explained in a single follow-up sentence. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description carries the full burden. It explains the verification logic but does not describe the return value, error conditions, or the structure of the evidence object. An agent might call it correctly but not know what to expect in response.

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 0%, so the description must compensate. It explains the role of expectedRoot (independently retained expected root) but does not detail the evidence object structure or expectedRoot format. The description adds some meaning but leaves gaps.

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?

The description clearly states the tool's function: recomputing the Merkle evidence root of a sealed episode. It also distinguishes the optional comparison behavior, which helps an agent understand the core purpose beyond the name.

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?

The description explains when to use the tool and what happens without an expectedRoot, but it does not explicitly mention alternatives or when not to use it. The context is clear enough for an agent to infer appropriate use.

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

verify_immune_lineageB

Verify an exported lineage entry list link by link. Optionally compare the computed head to an independently retained expected head hash.

ParametersJSON Schema

Name	Required	Description	Default
`entries`	Yes
`expectedHeadHash`	No

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Verify') but does not disclose what verification entails (e.g., whether it mutates state, requires specific permissions, or what happens on failure). It also does not mention the return value or any side effects, which is a significant gap for a tool with zero annotation coverage.

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?

Two sentences, front-loaded with the main action, and no fluff. The optional comparison is stated concisely. Every word earns its place; it is appropriately sized for the tool's scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is incomplete. It does not explain what constitutes a successful verification, what the tool returns (e.g., boolean, report, error), or any constraints on the 'entries' array. An agent cannot fully infer the expected behavior or result, leaving critical gaps in operational understanding.

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 0%, so the description must compensate. It provides some meaning: 'entries' are the lineage entry list, and 'expectedHeadHash' is the 'independently retained expected head hash.' However, it does not elaborate on the structure of the entries (e.g., required fields, format) or the precise semantics of the hash beyond being a comparison target. It adds value but leaves important details undefined.

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?

The description clearly states a specific verb ('Verify') and resource ('exported lineage entry list'), with the mode of operation ('link by link') and an optional comparison to an expected head hash. This distinguishes it from sibling tools like verify_episode_evidence (which is about episodes) and export_immune_lineage_report (export vs verify), so an agent can tell them apart without opening schemas.

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

Usage Guidelines3/5

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

The description implies the tool is used when you have an exported lineage entry list to verify, and mentions the optional comparison to an expected head hash. However, it does not explicitly state when to use this tool versus alternatives (e.g., verify_episode_evidence) or provide exclusions or prerequisites. The context is clear enough to infer general usage, but explicit routing to siblings is absent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.2.1Sep 26, 2026

Changedadjudicate_defensive_mutation23 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / baseline / additionalProperties
```
Added value: +false
```
addedInput schema / properties / baseline / properties / id / maxLength
```
Added value: +4096
```
addedInput schema / properties / baseline / properties / id / minLength
```
Added value: +1
```
addedInput schema / properties / baseline / properties / version / maxLength
```
Added value: +4096
```
addedInput schema / properties / baseline / properties / version / minLength
```
Added value: +1
```
addedInput schema / properties / baselineFitness
```
Added value: +{
+  "type": "number"
+}
```
addedInput schema / properties / baselineReplay / additionalProperties
```
Added value: +false
```

addedInput schema / properties / baselineReplay / properties / scenarioId

Added value: +{
+  "maxLength": 4096,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / baselineReplay / required

Previous value: -[
-  "reproduced",
-  "attackSucceeded",
-  "securityScore"
-]New value: +[
+  "scenarioId",
+  "reproduced",
+  "attackSucceeded",
+  "securityScore"
+]

addedInput schema / properties / candidates / items / additionalProperties
```
Added value: +false
```

addedInput schema / properties / candidates / items / properties

Added value: +{
+  "defense": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      },
+      "state": {},
+      "version": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "version"
+    ],
+    "type": "object"
+  },
+  "fitnessScore": {
+    "type": "number"
+  },
+  "impact": {
+    "additionalProperties": false,
+    "properties": {
+      "reasons": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "riskScore": {
+        "type": "number"
+      },
+      "safe": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "safe",
+      "reasons"
+    ],
+    "type": "object"
+  },
+  "mutation": {
+    "additionalProperties": false,
+    "properties": {
+      "description": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      },
+      "id": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      },
+      "patch": {}
+    },
+    "required": [
+      "description",
+      "patch"
+    ],
+    "type": "object"
+  },
+  "regression": {
+    "additionalProperties": false,
+    "properties": {
+      "failures": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "passed": {
+        "type": "boolean"
+      },
+      "score": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "passed",
+      "failures"
+    ],
+    "type": "object"
+  },
+  "replay": {
+    "additionalProperties": false,
+    "properties": {
+      "attackSucceeded": {
+        "type": "boolean"
+      },
+      "reproduced": {
+        "type": "boolean"
+      },
+      "scenarioId": {
+        "maxLength": 4096,
+        "minLength": 1,
+        "type": "string"
+      },
+      "securityScore": {
+        "type": "number"
+      },
+      "state": {},
+      "trace": {}
+    },
+    "required": [
+      "scenarioId",
+      "reproduced",
+      "attackSucceeded",
+      "securityScore"
+    ],
+    "type": "object"
+  }
+}

addedInput schema / properties / candidates / items / required

Added value: +[
+  "mutation",
+  "defense",
+  "impact"
+]

addedInput schema / properties / candidates / maxItems
```
Added value: +256
```
addedInput schema / properties / policy / additionalProperties
```
Added value: +false
```
removedInput schema / properties / policy / properties / requireAttackReproduction
```
Removed value: -{
-  "type": "boolean"
-}
```
addedInput schema / properties / policy / properties / requiredFitnessMargin / minimum
```
Added value: +0
```
addedInput schema / properties / scenario / additionalProperties
```
Added value: +false
```
addedInput schema / properties / scenario / properties / expectedSecurityProperty / maxLength
```
Added value: +4096
```
addedInput schema / properties / scenario / properties / expectedSecurityProperty / minLength
```
Added value: +1
```
addedInput schema / properties / scenario / properties / kind / maxLength
```
Added value: +4096
```
addedInput schema / properties / scenario / properties / kind / minLength
```
Added value: +1
```

changedInput schema / properties / scenario / required

Previous value: -[
-  "kind",
-  "expectedSecurityProperty"
-]New value: +[
+  "kind",
+  "payload",
+  "expectedSecurityProperty"
+]

Changedverify_episode_evidence1 field changed
- addedInput schema / properties / expectedRoot
```
Added value: +{
+  "type": "string"
+}
```
Changedverify_immune_lineage1 field changed
- addedInput schema / properties / expectedHeadHash
```
Added value: +{
+  "type": "string"
+}
```

6 tool updatesv0.1.0Sep 12, 2026
- First observedadjudicate_defensive_mutation
- First observeddescribe_policy
- First observedexport_immune_lineage_report
- First observedreset_state
- First observedverify_episode_evidence
- First observedverify_immune_lineage

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-09-26 03:45 across 6 tools

Disambiguation5/5

Each tool targets a distinct operation: adjudicating a mutation, verifying a single episode's evidence, verifying the lineage chain, describing policy, exporting the lineage report, and resetting state. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (adjudicate_defensive_mutation, verify_episode_evidence, verify_immune_lineage, describe_policy, export_immune_lineage_report, reset_state). Even the two verify tools are distinguished by their object.

Tool Count5/5

Six tools is well-scoped for a domain involving adjudication, verification, export, and reset. Each tool serves a clear purpose without redundancy or excessive granularity.

Completeness5/5

The tool set covers the full lifecycle: creating sealed evidence (adjudicate), verifying it (verify_episode_evidence), verifying the overall lineage (verify_immune_lineage), understanding the protocol (describe_policy), exporting results (export_immune_lineage_report), and managing session state (reset_state). No essential operations are missing for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

quorum A
io.github.terradev-cloud
Attested multi-agent consensus: proposals, votes, and outcomes stamped and traced.
Agent Orchestration Autonomous Agents
71
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373
DJZS Trust MCP A
ai.djzs
Deterministic pre-execution audit for trading agents. PASS/WAIT/FAIL, reproducible verdict_hash.
Finance Blockchain
423
Hermes Plant — Agent Commerce Assurance A
io.github.JesseGdotIO
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Finance AI & Machine Learning
2522

Related MCP Servers

AI Workbench MCP
Autonomous Agents CI/CD & DevOps Coding Agents
hrishikesh-thakre
A
license
C
quality
D
maintenance
Enables acceptance gates for AI coding-agent runs by recording evidence, running deterministic validation, applying a quality gate, and rendering auditable outcomes.
Updated 3 months ago (2026-06-27 17:03 UTC)
7
29 PyPI
Apache 2.0
mcp-nixreview
Security Code Analysis
pete-builds
A
license
Not graded
quality
A
maintenance
A safety gate for agent-proposed NixOS configuration changes, grading security-relevant option deltas, attesting closures for vulnerabilities, and requiring human approval with a tamper-evident audit ledger.
Updated 4 days ago (2026-09-26 23:53 UTC)
MIT
airlock
Autonomous Agents Security CI/CD & DevOps
Rohit-ATS
A
license
Not graded
quality
B
maintenance
Enables agents to open production change dossiers, attach proof certificates, and request human approval through a secure, unforgeable gate—ensuring no irreversible change can proceed until it has been verified against a sandboxed shadow copy.
Updated 2 days ago (2026-09-28 20:37 UTC)
250 npm
1
MIT
weavatrix-qualityofficial
Testing & QA Tools CI/CD & DevOps Code Analysis
Weavatrix
A
license
Not graded
quality
A
maintenance
Enables coding agents to turn OpenSpec intents and Git changes into revision-bound proofs by planning, selecting, and running the smallest safe protection set, then verifying composite verdicts and explaining evidence or unresolved states.
Updated 11 days ago (2026-09-19 12:54 UTC)
MIT

Counterfactual Immune Forge

Why a practitioner would install this

Protocol

Prerequisites

Install and run

Outputs

MCP tools

Library use

Threat model and misuse boundary

Honest limitations

Provenance

Tenable status

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

weavatrix-qualityofficial