How do I use security-genome-reactor?

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., "@security-genome-reactor infer security phenotypes from our latest 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.

security-genome-reactor

by SweetKenneth

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Security Genome Reactor

Evolve scan and policy configurations against the fleet's measured phenotype instead of its labels.

Infers latent security phenotypes from observed findings rather than operator labels, seeds competing scan/policy genomes per phenotype, evolves them under measured fitness, and keeps an explicit parent-before-child ancestry graph for every configuration in production.

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.

Why a practitioner would install this

Tags lie; behaviour does not. Phenotypes are inferred from observed findings and compliance behaviour, so a mislabelled asset group stops driving the scan policy.
Configurations compete instead of accumulating. Each phenotype gets several candidate genomes that are scored, not one inherited profile nobody dares change.
Fitness can be measured, not asserted. Callers may supply real measured fitness per genome; rehearsal is the fallback, never a substitute presented as measurement.
Every configuration has parents. Ancestry is returned in parent-before-child order, so 'why is this profile like this' has an answer.
A genome becomes a bounded trial. The reactor emits an explicit target/policy/profile trial plan rather than mutating anything.

Related MCP server: montology

Behavioural contract

genome_infer_phenotypes infers phenotypes from records above an explicit threshold and ignores cloud labels as ground truth.
genome_seed seeds multiple competing genomes for one phenotype.
genome_evolve runs one deterministic generation using caller-supplied measured fitness keyed by genome id, or rehearsal when none is supplied.
genome_trial_plan translates one genome into a bounded target/policy/profile trial plan.
genome_lineage returns ancestry in parent-before-child order and rejects cycles.
Populations below two genomes, unknown ids and invalid thresholds fail closed.

Prerequisites

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.

Install and run

git clone https://github.com/SweetKenneth/shpbl-security-genome-reactor.git
cd shpbl-security-genome-reactor
npm install      # devDependencies only: typescript
npm run build    # compiles to dist/
npm test         # 39 behavioural, boundary and fail-closed tests
npm start        # starts the MCP server on stdio

MCP client configuration:

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

Tools exposed

genome_infer_phenotypes — Infer latent security phenotypes from observed findings and compliance behavior, ignoring cloud labels as ground truth.
genome_seed — Seed multiple candidate security genomes for one phenotype.
genome_evolve — Run one deterministic evolutionary generation using rehearsal by default or caller-supplied measured fitness keyed by genome id.
genome_trial_plan — Translate a genome into a bounded target/policy/profile trial plan.
genome_lineage — Return ancestry in parent-before-child order for a genome from a supplied population/history.

What it outputs

Inferred phenotypes with supporting evidence, competing genome populations, per-generation fitness and selection results, bounded trial plans, and ordered ancestry graphs.

Verification

Reproduce all of it from a clean clone with npm run check:

Strict TypeScript compile and --noEmit typecheck: PASS
Behavioural tests: 39/39 PASS
Randomised invariant hammer: 30,000 cases / 420,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

Known limitations

No scanner or cloud client is embedded; records, fitness and execution are supplied by the caller.
Rehearsal fitness is an explicit fallback and is labelled as such — it is not a measurement of your fleet.
Phenotype inference is a deterministic clustering of supplied observations, not a claim about intent or ownership.
The reactor proposes trials. It never changes a scan, policy or profile.

Provenance and lineage

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.

Tenable status

Submitted to the Tenable CyberAgents Exchange for review on September 14, 2026 — pull request #173. Submission does not imply review, approval, certification, validation, endorsement or acceptance by Tenable.

Files

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.

License

Available Tools

5 tools

genome_evolveB

Run one deterministic evolutionary generation using rehearsal by default or caller-supplied measured fitness keyed by genome id.

ParametersJSON Schema

Name	Required	Description	Default
`phenotype`	Yes
`population`	Yes
`fitnessByGenomeId`	No

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses determinism and the default/caller-supplied fitness modes, which is meaningful, but it does not explain what 'rehearsal' entails, whether the population is mutated in place, or what 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.

Conciseness4/5

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

The description is a single efficient sentence with no filler, and the core action is front-loaded. It is slightly dense, but every phrase contributes to the overall meaning.

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?

This is a complex tool with nested objects, no annotations, and no output schema, yet the description offers only one sentence. It leaves important operational details undefined, such as side effects, return behavior, and what makes the generation 'deterministic' in practice.

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%, so the description must compensate, but it only adds meaning for fitnessByGenomeId ('caller-supplied measured fitness keyed by genome id'). The required phenotype and population parameters are not explained at all.

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 action ('Run one deterministic evolutionary generation') and names the fitness mechanism. It is clear about what the tool does, but it does not explicitly differentiate from sibling tools such as genome_seed or genome_lineage.

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 gives useful conditional guidance: use rehearsal by default, or supply measured fitness keyed by genome id. However, it does not say when to choose this tool over alternative genome tools or when not to use it.

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

genome_infer_phenotypesA

Infer latent security phenotypes from observed findings and compliance behavior, ignoring cloud labels as ground truth.

ParametersJSON Schema

Name	Required	Description	Default
`records`	Yes
`threshold`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It usefully states that cloud labels are intentionally ignored as ground truth, which is a meaningful behavioral trait. It does not, however, describe whether the tool is read-only, what it returns, or how it treats edge cases, so transparency is only partial.

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 entire description is one focused sentence with no filler. The core action and key behavioral caveat are front-loaded, and every phrase earns its place.

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?

The tool has no annotations, no output schema, and a non-trivial input schema with nested records. The description does not state what the tool returns, how threshold affects inference, or what a caller should do with the resulting phenotypes, leaving significant gaps for correct invocation and interpretation.

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 adds semantic meaning for records fields by referring to 'observed findings and compliance behavior' and for cloudTags via 'ignoring cloud labels'. It does not explain the threshold parameter at all, leaving a notable gap for an optional but potentially important input.

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 uses a specific verb ('infer') and a specific resource ('latent security phenotypes'), and names the exact input sources ('observed findings and compliance behavior'). It clearly differentiates this from sibling tools like genome_seed or genome_evolve by describing an inference task rather than population seeding or evolution.

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 when to use the tool: when you have observed findings and compliance data and want latent phenotypes. However, it provides no explicit exclusions, prerequisites, or guidance on when to prefer a sibling tool over this one.

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

genome_lineageB

Return ancestry in parent-before-child order for a genome from a supplied population/history.

ParametersJSON Schema

Name	Required	Description	Default
`genomes`	Yes
`genomeId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure, but it only says 'Return ancestry' and the ordering. It does not explicitly state that the tool is read-only, what happens when a genomeId is absent from the supplied genomes, or what the output contains beyond ordering. The verb 'Return' implies a read, but that implication is not enough for 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?

The description is a single sentence with no filler. It fronts the core purpose and adds the key ordering detail, so every word 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?

The tool has only two parameters, but no output schema and no annotations. The description tells the result order but not the output format or edge cases such as whether the ancestry is returned as IDs or full genome objects. Given the sizable genomes input schema, a bit more context about the returned shape would make the tool fully usable.

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 adds some meaning by calling the array parameter a 'supplied population/history' and framing genomeId as targeting one genome, which helps map the two parameters. However, it does not explain the semantics of the required genome fields in the array items, though the schema already details those.

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 resource ('ancestry'), the target ('a genome'), and the order of results ('parent-before-child'). It is clearly different from siblings like genome_seed or genome_evolve, though it does not explicitly name them, so it stops short of a top score.

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 description provides no guidance on when to use this tool instead of alternatives such as genome_infer_phenotypes or genome_evolve. It also does not say when this tool is not appropriate or what conditions trigger its use.

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

genome_seedC

Seed multiple candidate security genomes for one phenotype.

ParametersJSON Schema

Name	Required	Description	Default
`phenotype`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Seed' implies some generative or state-creating behavior, but the description does not state whether the operation mutates data, is randomized, how many candidates are produced, or what it returns.

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

Conciseness3/5

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

The description is extremely concise and front-loaded with no filler, which is good. However, the brevity crosses into under-specification for a tool with a nested parameter and no other context.

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 workflow tool with four siblings, no annotations, and no output schema, this description omits return values, side effects, candidate count, randomness, and any relationship to the other genome tools. An agent lacks enough information to confidently select and invoke it.

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%, and the description only says 'for one phenotype' without explaining the phenotype object, its required nested fields, or how to populate values like centroid or dominantSignatures. The schema is self-documenting, but the description adds almost no semantic meaning to the parameter.

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 ('seed') and names the resource ('multiple candidate security genomes') for one phenotype, which clearly states the core operation. It is reasonably distinguishable from siblings like 'evolve' and 'infer_phenotypes', though it never defines what a 'security genome' is in this context.

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?

No when-to-use guidance is provided, and the description does not mention alternatives or prerequisites. An agent has to guess from sibling names that seeding is an initial generation step before evolving or planning trials.

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

genome_trial_planC

Translate a genome into a bounded target/policy/profile trial plan.

ParametersJSON Schema

Name	Required	Description	Default
`genome`	Yes
`phenotype`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

With no annotations at all, the description carries the full burden of explaining side effects and safety, and it does not. 'Translate' weakly implies a conversion rather than a mutation, but the description does not state whether the operation is read-only, persists anything, returns a plan object, or has validation or authorization requirements.

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 front-loaded sentence with no filler or redundant restatement of the schema. It is efficient, though the awkward slash chain 'target/policy/profile' reduces clarity slightly.

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

Completeness1/5

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

This tool has two highly nested required objects, no output schema, and no annotations, so the description is far too thin. It does not explain what the trial plan contains, what 'bounded' constrains, how the phenotype influences the result, or what the return value looks like.

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

Parameters1/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 for the undocumented parameters. It only mentions 'genome' and says nothing about the equally required 'phenotype' parameter, nor does it explain what target/policy/profile mean or how the parameters relate to the generated plan.

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

Purpose3/5

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

The description names a specific transformation (genome → trial plan) and the output concept is at least distinguishable from sibling actions like seeding, evolving, or inferring phenotypes. However, it never mentions the required phenotype input and the phrase 'bounded target/policy/profile trial plan' is domain jargon that leaves the actual deliverable vague.

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 versus genome_seed, genome_evolve, genome_infer_phenotypes, or genome_lineage. The agent must infer from the name and one-line description that it is for producing a trial plan, but no conditions, exclusions, or alternatives are given.

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.

5 tool updatesv1.0.0Sep 14, 2026
- First observedgenome_evolve
- First observedgenome_infer_phenotypes
- First observedgenome_lineage
- First observedgenome_seed
- First observedgenome_trial_plan

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

B3.2/5.0

Scored 2026-09-14 23:45 across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct step in the genome workflow: inferring phenotypes, seeding candidates, evolving generations, planning trials, and tracing lineage. There is no meaningful functional overlap between any two tools.

Naming Consistency3/5

All names share the genome_ prefix and use snake_case, which is readable and recognizable. However, the pattern is mixed: genome_infer_phenotypes is verb-object, genome_seed and genome_evolve are bare verbs, while genome_trial_plan and genome_lineage are noun phrases.

Tool Count5/5

Five tools is well-scoped for this specialized domain. Each tool represents a meaningful stage in the reactor lifecycle without redundant or filler operations.

Completeness5/5

The set covers the core genome lifecycle: infer phenotypes, seed candidates, evolve generations, produce trial plans, and inspect lineage. Fitness is intentionally caller-supplied, so no evaluation tool is a necessary gap.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

aribot A
io.github.aristiun
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Security Penetration Testing
162
ImmensityOAuth
io.github.CodingWithJoseph
Discover software problems, analyze evidence, and create implementation-ready Build plans.
Code Analysis Observability Project Management
1
Toreva GoalsOAuth
io.github.toreva
Durable, user-controlled goals and governed plans for AI agents.
Autonomous Agents Knowledge & Memory
1
StrixOAuth
ai.strix
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Penetration Testing Version Control
1

Related MCP Servers

Rigour MCPofficial
Code Analysis Security Developer Tools
rigour-labs
A
license
Not graded
quality
B
maintenance
Enables AI agents to self-govern by scanning code for hardcoded secrets, structural violations, and AI drift in real-time, providing fix packets for automatic remediation.
Updated 2 days ago (2026-09-14 12:55 UTC)
27
MIT
montology
Developer Tools Code Analysis
shinyobjectz
A
license
C
quality
B
maintenance
Enforces design systems and vocabulary via ontology checks, candidate scanning, linting, and structural search across repositories.
Updated 13 days ago (2026-09-03 17:55 UTC)
7
39
Apache 2.0
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 10 days ago (2026-09-06 15:56 UTC)
MIT
Counterfactual Immune Forge
Security Testing & QA Tools
SweetKenneth
A
license
A
quality
C
maintenance
Enables agents and security automation to adjudicate proposed defense mutations against a sealed, canonicalized attack scenario, enforcing reproduction, impact-screening, regression, and proven-improvement gates before promoting at most one candidate. Every verdict, rejected candidate, and rejection reason is sealed into a recomputable SHA-256 Merkle evidence root and hash-linked lineage that can be independently verified without trusting the server.
Updated 4 days ago (2026-09-12 02:20 UTC)
6
MIT

Security Genome Reactor

Why a practitioner would install this

Behavioural contract

Prerequisites

Install and run

Tools exposed

What it outputs

Verification

Known limitations

Provenance and lineage

Tenable status

Files

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Rigour MCPofficial

weavatrix-qualityofficial