How do I use nightmare-probe-engine?

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., "@nightmare-probe-engine Generate a falsifiable hypothesis from these observations and compile a probe." 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.

nightmare-probe-engine

by SweetKenneth

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Nightmare Probe Engine

Turn worst-case fleet hypotheses into the smallest bounded scan that could falsify them.

Generates falsifiable worst-case fleet hypotheses, compiles each into the smallest bounded targeted-scan probe with a control cohort, and returns a support/falsification verdict that requires discrimination from the controls.

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

A theory is not a finding. Every hypothesis carries the observations that suggested it and the exact probe that could kill it, so nobody argues about a hunch.
Probes stay small on purpose. A hypothesis compiles to the fewest targets that can discriminate it, inside an explicit budget, instead of another fleet-wide sweep.
Controls are mandatory for a verdict. Target support alone cannot mark a hypothesis SUPPORTED; the probe must also separate targets from the tested control cohort.
Falsification is a first-class result. A refuted hypothesis is recorded with its evidence, which is the outcome that actually shrinks the search space.
Nothing scans on its own. The engine plans and judges; the operator's own scanner executes and hands back observations.

Related MCP server: ReasonForge

Behavioural contract

nightmare_generate derives deterministic, evidence-seeking hypotheses from supplied assets and observations. No observation, no hypothesis.
nightmare_compile_probe compiles one hypothesis into a bounded probe plan: exact targets, an optional control cohort, and a budget it may not exceed.
nightmare_evaluate_probe compares target and control observations against the hypothesis and returns SUPPORTED, REFUTED or INCONCLUSIVE with its reasoning.
A SUPPORTED verdict requires both target support and discrimination from any tested controls.
Malformed, empty or out-of-range input fails closed rather than returning a confident guess.
Every run is a pure function of its inputs: same inputs, same hypotheses, same plan, same verdict.

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-nightmare-probe-engine.git
cd shpbl-nightmare-probe-engine
npm install      # devDependencies only: typescript
npm run build    # compiles to dist/
npm test         # 29 behavioural, boundary and fail-closed tests
npm start        # starts the MCP server on stdio

MCP client configuration:

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

Tools exposed

nightmare_generate — Generate deterministic evidence-seeking security hypotheses from fleet observations.
nightmare_compile_probe — Compile one hypothesis into a bounded targeted probe plan with optional control cohort.
nightmare_evaluate_probe — Evaluate target and control observations against a hypothesis and return a falsification/specificity verdict.

What it outputs

Hypothesis records with supporting observations, bounded probe plans (targets, controls, budget), and verdict objects with the discrimination reasoning, all returned as MCP structuredContent plus text JSON.

Verification

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

Strict TypeScript compile and --noEmit typecheck: PASS
Behavioural tests: 29/29 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

Known limitations

No Nessus, cloud or network client is embedded. The scan executor boundary must be supplied by an integration.
Hypotheses are deterministic structures derived from the observations you supply; this is not autonomous discovery of ground truth and carries no probabilistic calibration.
A SUPPORTED verdict is evidence of discrimination, not proof of causation.
Session memory is in process. Exported records are the durable artifact.

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 #171. 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

3 tools

nightmare_compile_probeC

Compile one hypothesis into a bounded targeted probe plan with optional control cohort.

ParametersJSON Schema

Name	Required	Description	Default
`assets`	Yes
`budget`	No
`history`	Yes
`hypothesis`	Yes

TDQS

C2.5/5.0

Behavior1/5

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

With no annotations and no output schema, the description carries the full burden of explaining behavior. The text only says 'compile' and 'bounded', which does not disclose whether the tool triggers expensive work, has side effects, requires auth, modifies state, or how it treats the given assets and history. The behavioral surface is essentially undisclosed.

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?

A single front-loaded sentence that wastes no words and names the core transformation. The adjectives 'bounded' and 'targeted' add qualifiers without verbosity. It is efficient, though perhaps too terse to be maximally useful.

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 4 parameters (3 required), nested input objects, no output schema, and no annotations. The description explains the core operation but omits what the tool will do with those required parameters, what a 'probe plan' contains, and what expected behavior is. The absent output format and undocumented inputs make this incomplete for safe invocation.

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. It adds bit of meaning by identifying 'hypothesis' as the singular hypothesis and referencing an 'optional control cohort', which likely maps to 'budget'. But it fails to explain 'assets', 'history', or 'budget' meaningfully, leaving most of the four parameters opaque.

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 clearly names the action ('Compile one hypothesis into a bounded targeted probe plan') with a specific verb and resource, and the contrast with siblings 'nightmare_generate' and 'nightmare_evaluate_probe' suggests the compile step is distinct. However, it does not explicitly contrast itself with those siblings or define what distinguishes a 'probe plan' from a 'generate' output, so it stops just short of a 5.

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 guidance is given about when to use this tool versus the siblings. The phrase 'Compile one hypothesis into a plan' implies a use case, but it never instructs when not to use it or names an alternative. The agent is left to infer the tool's role in the generation/evaluation pipeline.

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

nightmare_evaluate_probeC

Evaluate target and control observations against a hypothesis and return a falsification/specificity verdict.

ParametersJSON Schema

Name	Required	Description	Default
`plan`	Yes
`result`	Yes
`hypothesis`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the operation is read-only, has side effects, requires specific permissions, or any other behavioral traits. It merely says 'evaluate' and 'return', implying a non-destructive action, but this is not explicit. There's no statement about safety, reversibility, or limitations, leaving 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.

Conciseness4/5

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

The description is a single sentence that is front-loaded with the action and outcome. It is concise with zero wasted words. However, given the complexity of the tool (three opaque object parameters, no schema coverage), the description could be longer and still remain efficient. But as written, it is structurally clean and direct.

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 nested object parameters with zero schema coverage and no annotations or output schema. The description provides only a high-level purpose but omits essential details: what each parameter should contain, how 'target and control observations' map to the params, what the verdict format is, or any error/edge-case behavior. An agent would be unable to correctly construct inputs or interpret results, making the description severely incomplete.

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% – none of the three parameters (hypothesis, plan, result) have any textual documentation. The description only hints at 'hypothesis' and 'observations' but does not explain the roles of 'plan' and 'result', nor the expected structure of the objects. The agent is left without any semantic guidance beyond parameter names, and the description does nothing to compensate for the schema's silence.

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 ('evaluate') and resource ('target and control observations against a hypothesis') and specifies the outcome ('falsification/specificity verdict'). This clearly conveys what the tool does. It doesn't explicitly differentiate from siblings (nightmare_generate, nightmare_compile_probe), but the 'probe' in the name and the evaluation focus distinguish it well enough. It could be improved by naming alternatives, so not a perfect 5.

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 gives no guidance on when to use this tool versus the sibling tools. It doesn't state prerequisites, context, or any conditions that would select this tool over alternatives. The intended workflow is left entirely to inference, providing no explicit usage context.

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

nightmare_generateC

Generate deterministic evidence-seeking security hypotheses from fleet observations.

ParametersJSON Schema

Name	Required	Description	Default
`assets`	Yes
`options`	No
`observations`	Yes

TDQS

C2.9/5.0

Behavior2/5

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 states the output is 'deterministic' and 'evidence-seeking', which is useful, but it doesn't disclose what the generated hypotheses look like, whether the tool mutates any state, what inputs are required beyond the schema, or any side effects. For a generation tool with zero annotation coverage, this is a significant gap.

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 sentence with no wasted words, and the key qualifiers ('deterministic', 'evidence-seeking') are front-loaded. It is appropriately concise, though it could earn a 5 by adding a brief usage note without bloating.

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 output schema, no annotations, and 0% parameter coverage, so the description is the only source of guidance. It explains the high-level purpose but omits what the generated hypotheses contain, how the parameters map to behavior, and how this relates to the sibling tools. An agent would struggle to invoke this correctly with only the given information.

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 does not explain the meaning of 'assets', 'observations', or 'options'. The description names the resource ('fleet observations') but doesn't clarify what 'assets' refers to or how 'options' shapes the output. With three parameters and zero schema descriptions, the description must compensate and does not.

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 ('generate') and resource ('security hypotheses from fleet observations'), and the 'deterministic evidence-seeking' qualifier adds useful specificity. It doesn't explicitly distinguish from siblings, but the resource and purpose are clear enough that an agent can infer it produces hypotheses rather than compiling or evaluating probes.

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 a use case: generating hypotheses from fleet observations. However, it provides no explicit guidance on when to choose this tool over nightmare_compile_probe or nightmare_evaluate_probe, nor any exclusions or prerequisites. The context is clear but the routing guidance is left to inference.

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 updatesv1.0.0Sep 14, 2026
- First observednightmare_compile_probe
- First observednightmare_evaluate_probe
- First observednightmare_generate

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.1/5.0

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

Disambiguation5/5

Each tool handles a distinct lifecycle stage: generating hypotheses, compiling them into probes, and evaluating results. There is no functional overlap or ambiguity between the three tools.

Naming Consistency4/5

All tools share the nightmare_ prefix and use verb_noun style. nightmare_generate lacks an explicit object compared to nightmare_compile_probe and nightmare_evaluate_probe, but the intent is still clear.

Tool Count5/5

Three tools map directly to a focused generate-compile-evaluate workflow. The count feels intentional and well-scoped for a single-purpose security probe engine.

Completeness4/5

The tool set covers the full hypothesis-to-verdict pipeline without obvious dead ends. It may rely on external systems for actual probe execution, but within its stated domain it appears complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Senlay Physical Context A
io.github.smartsurfsolar
Physical-world evidence and operability checks with provenance and explicit data gaps.
Home Automation & IoT Monitoring Security
41
aboard
me.untype
Falsifiable claims about systemic problems: causal graph, forecasts, dossiers.
Knowledge & Memory Research & Data
12
Meta Council B
com.meta-council
Multi-expert decision intelligence with transparent synthesis and auditable workflows.
Autonomous Agents Agent Orchestration
1612
agentstack-mcp A
io.github.inity13
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Autonomous Agents Agent Orchestration
241

Related MCP Servers

AGI Cognitive MCP Server
AI & Machine Learning Research & Data
SVG-campus
F
license
Not graded
quality
D
maintenance
Provides programmatic access to causal discovery, topological data analysis, Gaussian process belief updating, thermodynamic auditing, and HCHL inference for agents and researchers.
Updated 3 months ago (2026-06-19 17:53 UTC)
-
ReasonForge
Autonomous Agents
euuuuuuan
A
license
Not graded
quality
C
maintenance
Provides 8 MCP tools for deterministic, read-only reasoning: intake, routing, planning, rubric, sweep checklist, verdict gate, reflection, and evaluation. It forces scope locks, disconfirmation-first plans, blind-spot sweeps, and evidence-gated verdicts.
Updated 2 months ago (2026-07-30 16:55 UTC)
Apache 2.0
prism-mcp
AI & Machine Learning Agent Orchestration
Santhosh0303
F
license
A
quality
B
maintenance
Enables AI harnesses to run reasoning preflight and contradiction measurement, exposing tools for perspective selection, claim-pair contradiction scoring, and synthesis contract generation to improve final answers.
Updated 8 days ago (2026-09-08 22:23 UTC)
4
-
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

Nightmare Probe Engine

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

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

AGI Cognitive MCP Server

ReasonForge

prism-mcp

weavatrix-qualityofficial