Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fleet-immune-system Find co-occurring fleet threat patterns from our normalized scan findings."
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.
Treat normalized scan findings as immune signals: discover patterns, synthesize non-executing defenses, remember what worked.
Treats normalized scan findings as immune signals: discovers co-occurring fleet threat patterns, synthesizes non-executing defensive recipes, retains successful outcomes as recallable memory, and targets adjacent cohorts likely to show the same variant.
It is an analysis and decision surface, not an actuator: it has no network client, touches no files, spawns no processes, and reads no environment variables.
Findings stop being a flat list. Co-occurrence across the fleet is surfaced as a supported pattern with the signals that support it, so related exposure is treated as one condition.
Defensive recipes never execute. A synthesized antibody is a described, reviewable response plan — the server has no actuator and cannot run it.
Successful responses are remembered. A crystallized outcome is recallable by pattern similarity, so the second occurrence does not restart the analysis.
Adjacent cohorts get named. The cycle planner points at neighbours in the supplied topology that are likely to carry the same variant, before they are scanned.
Breeding cannot escalate. Combining two recipes is deterministic and may not introduce destructive action absent from both parents.
Related MCP server: mcp-resonance
immune_discover returns co-occurring patterns that meet an explicit minimum support; unsupported coincidence is not a pattern.
immune_synthesize produces a non-executing antibody recipe from a pattern and its signals.
immune_cycle plans one cycle: patterns, variants, memory recall and adjacent-cohort targets from the supplied topology.
immune_crystallize retains a pattern/antibody/outcome above a confidence floor into session-local immune memory.
immune_recall returns the closest retained crystal for a pattern, or nothing when similarity is below the threshold.
immune_breed deterministically combines two recipes and refuses to escalate destructive action beyond both parents.
Unknown fields, malformed signals and out-of-range thresholds fail closed.
Node.js 20 or newer (node --version). 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.
git clone https://github.com/SweetKenneth/shpbl-fleet-immune-system.git
cd shpbl-fleet-immune-system
npm install # devDependencies only: typescript
npm run build # compiles to dist/
npm test # 38 behavioural, boundary and fail-closed tests
npm start # starts the MCP server on stdioMCP client configuration:
{
"mcpServers": {
"fleet-immune-system": {
"command": "node",
"args": ["/absolute/path/to/shpbl-fleet-immune-system/dist/src/mcp-server.js"]
}
}
}immune_discover — Discover co-occurring emergent fleet threat patterns from normalized defensive scan signals.
immune_synthesize — Synthesize a non-executing defensive antibody recipe from a threat pattern.
immune_cycle — Plan one fleet immune cycle with variants, memory recall and adjacent cohort targeting.
immune_crystallize — Persist a successful pattern/antibody outcome into the server-local immune memory for later recall.
immune_recall — Recall the closest retained immune-memory crystal for a threat pattern.
immune_breed — Breed two non-executing antibody recipes into a deterministic next-generation candidate without escalating destructive action.
Supported threat patterns, non-executing antibody recipes, one-cycle plans with variant and adjacent-cohort targeting, memory crystals and recall matches with similarity scores.
Reproduce all of it from a clean clone with npm run check:
Strict TypeScript compile and --noEmit typecheck: PASS
Behavioural tests: 38/38 PASS
Randomised invariant hammer: 30,000 cases / 210,000 invariant checks PASS
Static scan for network, filesystem, process and dynamic-eval surfaces in src/: PASS (0 findings)
Worked example runs end to end: PASS
Runtime dependencies: 0
No scanner, cloud or network client is embedded; normalized signals are supplied by the caller.
Pattern support is a co-occurrence measure over the signals you supply, not a causal claim.
Antibody recipes are descriptions for human or adapter execution. Nothing here applies a change.
Immune memory is session-local; exported crystals are the durable artifact.
This product exists because two things were put together, and both are credited.
Upstream capability inspiration — conard0-git/targeted-nessus-scan, by Isaac Conard (conard0-git), MIT licensed. Its observed behaviour was studied as a capability surface: what a practitioner in that domain actually needs to do. The exact paths and lines that were read are recorded in PROVENANCE.json. No line of upstream implementation code is used in this package. The upstream licence text is preserved under THIRD_PARTY_NOTICES/ as provenance; it does not license this implementation.
SHPBL capability library — shpbl.com. SHPBL (shpbl.com) is a governed library of reusable software capabilities and a method for composing them: it reads a target repository, identifies what capability it demonstrates, matches that against owned capability records, and writes new software where neither side had it before. The capability parents used here are listed by identifier in PROVENANCE.json. No harvested capability body is embedded in this package.
The implementation in this repository was written fresh from the approved capability contract for this run. The literal composition is 0% upstream code, 0% copied SHPBL capability bodies, 100% new implementation. That is an exact-line and byte-level statement about this source tree, not a legal opinion.
Author and copyright: Kenneth E. Sweet Jr., MIT licensed.
Attribution does not imply endorsement by Isaac Conard (conard0-git), Tenable, or any other party.
Submitted to the Tenable CyberAgents Exchange for review on September 14, 2026 — pull request #172. Submission does not imply review, approval, certification, validation, endorsement or acceptance by Tenable.
src/ — implementation and the stdio MCP server.
tests/ — behavioural, fail-closed and MCP integration tests.
scripts/ — randomised invariant hammer and the static security scan.
examples/worked-example.ts — an end-to-end run you can execute.
SECURITY.md — threat boundary and forbidden behaviour.
PROVENANCE.json — upstream and SHPBL capability lineage.
MANIFEST.json / CHECKSUMS.sha256 — released file inventory and hashes.
LICENSE — MIT.
MIT © 2026 Kenneth E. Sweet Jr.. See LICENSE.
Breed two non-executing antibody recipes into a deterministic next-generation candidate without escalating destructive action.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| mutation | No |
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 does disclose a key behavioral trait: the operation is non-escalating and deterministic, which is valuable context. However, it does not explain what 'breeding' entails (e.g., how the two recipes are combined, what happens to the inputs, whether the original recipes are modified), nor does it describe the output format or any side effects. The description adds some behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise and front-loads the core action ('Breed two non-executing antibody recipes'). It packs useful constraints into a compact form. It could be slightly more structured by separating the safety note, but it is not bloated or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, nested objects, no output schema, and no annotations, the description is not complete enough. An agent would not know what the 'mutation' parameter does, what the output looks like, or what constraints apply to the breeding process (e.g., whether inputs must be of a certain mode or generation). The description provides a high-level purpose but lacks the operational detail needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the schema's lack of parameter documentation. The description mentions 'two non-executing antibody recipes' which maps to parameters a and b, but it does not explain the 'mutation' parameter at all. The nested object schemas for a and b are detailed but the description adds no meaning about how they are used in breeding. This is a clear gap for a 3-parameter tool with zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Breed') and resource ('two non-executing antibody recipes into a deterministic next-generation candidate'), which clearly distinguishes it from sibling tools like immune_discover or immune_synthesize. It also adds a meaningful constraint ('non-executing', 'without escalating destructive action') that helps an agent understand the tool's role. However, it does not explicitly name sibling tools or contrast them, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have two non-executing antibody recipes and want to breed them into a next-generation candidate. It also implies a safety constraint ('without escalating destructive action'), which suggests it is preferred over more destructive alternatives. However, it does not explicitly state when NOT to use it or name alternative tools, leaving the agent to infer the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a successful pattern/antibody outcome into the server-local immune memory for later recall.
| Name | Required | Description | Default |
|---|---|---|---|
| floor | No | ||
| outcome | Yes | ||
| pattern | Yes | ||
| antibody | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does add behavior beyond a bare write operation: it gates persistence on success, scopes storage to 'server-local' memory, and indicates the memory is intended for later recall. However, with no annotations, it leaves out important behavior such as whether repeated calls overwrite existing memory, what happens on conflict or failure, and whether there is any eviction or capacity limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler and front-loads the core action. The slash in 'pattern/antibody outcome' introduces mild ambiguity, but structurally it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, deeply nested objects, no annotations, and no output schema, a single-purpose sentence is insufficient for correct invocation. The agent is missing semantic definitions for the nested fields, the meaning of `floor`, and any information about the persisted form or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names pattern, antibody, and outcome without explaining their contents or interrelations. The optional `floor` parameter is not mentioned at all, and the meaning of fields like detectionRate, falsePositiveRate, coverage, and cost is left entirely to inference from property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (persist) and a specific target (successful pattern/antibody outcome into server-local immune memory), and the phrase 'for later recall' helps separate it from the read-style sibling immune_recall. However, 'pattern/antibody outcome' is slightly ambiguous about whether the stored item is one composite thing or all three schema objects, and no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'successful' signals that this tool is meant for validated, persisted results rather than arbitrary ones, which is a real usage hint. It gives no explicit guidance about when to use it vs. immune_discover, immune_synthesize, immune_breed, or immune_cycle, and it does not name immune_recall as the read counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan one fleet immune cycle with variants, memory recall and adjacent cohort targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | ||
| topology | No | ||
| minSupport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool 'plans' but does not state whether this is a read-only operation, what side effects or mutations occur, what inputs trigger the behavior, or what the resulting plan looks like. The jargon about 'memory recall' and 'adjacent cohort targeting' hints at behavior but does not explain concrete effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the primary action ('Plan one fleet immune cycle'). It is appropriately brief, though the brevity contributes to under-specification rather than being a structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested input schema, no output schema, and no annotations, while five sibling tools create selection ambiguity. The description provides a high-level purpose but omits required input semantics, output/return expectations, and usage context, so the definition is not sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not map any of the three parameters (signals, topology, minSupport) to the planning concepts. The required signals parameter is a complex nested object with five fields, yet the description only offers abstract phrases like 'variants' and 'memory recall' without tying them to schema properties. This leaves an agent without meaningful parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Plan one fleet immune cycle,' and it enumerates three distinctive features—variants, memory recall, and adjacent cohort targeting—that help separate it from siblings like immune_discover or immune_recall. However, it does not explicitly name or contrast any sibling tool, so the distinction is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use immune_cycle instead of the five sibling tools, no mention of prerequisites, and no exclusions. Usage must be inferred entirely from the terse phrase 'Plan one fleet immune cycle,' which is not enough for an agent to choose confidently among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover co-occurring emergent fleet threat patterns from normalized defensive scan signals.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | ||
| minSupport | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It indicates an analytical/discovery operation but does not mention whether it is read-only, what output or return value to expect, whether it mutates state, or any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a purpose statement, though it could have used additional structured detail about parameters and usage without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters (one nested), no output schema, no annotations, and several similarly named sibling tools, this description is substantially incomplete. It provides only the core purpose and omits usage guidance, parameter semantics, behavioral disclosures, and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain either parameter. 'Signals' is hinted at by the phrase 'scan signals,' but the required nested fields (assetId, cohort, signature, severity) and the meaning of minSupport are left entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Discover') and a concrete resource ('co-occurring emergent fleet threat patterns' from 'normalized defensive scan signals'). It gives a clear sense of what the tool computes, though it does not explicitly differentiate it from the sibling immune_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like immune_synthesize, immune_crystallize, or immune_recall. The description implies the input is scan signals, but it never states conditions, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall the closest retained immune-memory crystal for a threat pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| threshold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read/retrieval operation and the notion of 'closest', but it does not mention what happens when no crystal matches, whether the operation has side effects, what output is returned, or any thresholds/edge cases in behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler, and the core action and object are front-loaded. It is appropriately concise, though the brevity borders on underspecification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested required pattern object with seven subfields, an optional threshold, no output schema, and no annotations. A one-sentence description is far too thin for an agent to construct valid input, understand threshold effects, or interpret the returned crystal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds almost no parameter meaning. It only calls the main parameter a 'threat pattern', which is already implied by the schema, and it says nothing about the optional 'threshold' parameter or the required nested fields. The description does not compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recall') and names the resource ('closest retained immune-memory crystal') for a 'threat pattern', making the core operation and target understandable. It does not explicitly distinguish itself from sibling tools like immune_crystallize or immune_discover, but the memory-recall framing is distinct enough to avoid major confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the alternatives, nor any conditions, prerequisites, or exclusions. The one-line description leaves usage entirely to inference, which is insufficient for an agent deciding between immune_recall, immune_discover, and immune_synthesize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synthesize a non-executing defensive antibody recipe from a threat pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| signals | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. The qualifier 'non-executing' is a useful behavioral disclosure, indicating the tool produces a recipe rather than taking action. However, it does not say whether the operation is read-only, whether it has side effects, or what the output recipe contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the verb, object, and key qualifier. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema, no annotations, and no output schema, a single sentence is not enough. The description omits usage context, parameter details, output format, and behavioral edge cases, so an agent cannot reliably call it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only hints at 'pattern' as a threat pattern; the required 'signals' parameter and all nested fields are left unexplained. This is minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Synthesize') and resource ('non-executing defensive antibody recipe') and names the input source ('from a threat pattern'). It clearly conveys what the tool produces, though it does not explicitly compare with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of immune_discover, immune_cycle, immune_crystallize, immune_recall, or immune_breed. The only hint is 'from a threat pattern,' which is not enough to select among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0immune_breedimmune_crystallizeimmune_cycleimmune_discoverimmune_recallimmune_synthesizeScored across 6 tools
Each tool targets a distinct stage in the immune-system workflow: discovery, synthesis, planning, persistence, recall, and breeding. While synthesize and breed both produce antibody recipes, their inputs and methods differ clearly in the descriptions.
All tool names follow the same immune_<verb> pattern using lowercase snake_case. The verbs are varied but consistently placed, making the naming scheme predictable and readable.
Six tools is well-scoped for an immune-system domain, covering the main phases without redundancy or bloat. Each tool earns its place in the workflow.
The core lifecycle is covered: discover, synthesize, plan, persist, recall, and breed. A minor gap is lack of memory deletion or invalidation, but this is not essential to the described non-executing defensive purpose.
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Agent-ready economic, market & geo-health intelligence — 318 MCP tools, 309 driver-backed indices.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
Fleet entry point: 22 hosted MCP servers, 160 tools, 110 free. Searches 138 agent skills.
