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., "@shpbl-counterfactual-exposure-planner Compare two futures: patch all criticals or isolate the edge gateway."
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.
Compare several remediation futures against a sealed exposure graph before touching production.
A deterministic what-if engine for exposure data: clones a sealed exposure graph, applies bounded interventions, recomputes weighted risk and reachable attack surface, then ranks the resulting futures and marks the Pareto-efficient ones before production changes.
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.
"Patch this or isolate that?" gets a measured answer. Both futures are computed against the same sealed baseline instead of argued.
Your input graph is never mutated. Every scenario runs on a clone, so a planning session cannot corrupt the state of record.
Reachability, not just counts. Scenarios are scored on weighted risk, reachable attack surface and critical reachable findings, plus their own cost.
Inferior options are labelled. Pareto marking stops a scenario that is worse on every axis from being presented as a reasonable choice.
Rankings are reproducible. Deterministic utility with stable tie-breaks means the same data ranks the same way in tomorrow's review.
Related MCP server: CyberSim Pro MCP Server
Validate and clone the baseline exposure graph; caller input is never mutated.
Support bounded interventions: patch a finding, isolate an asset, reduce exposure probability, or vary criticality as a stated assumption.
Recompute weighted risk, reachable attack surface, critical reachable findings and intervention cost for every scenario.
Seal both baseline graph and scenario with SHA-256 canonical digests.
Rank scenarios deterministically by utility with stable tie-breaks.
Mark Pareto-efficient scenarios so a dominated scenario is not presented as equally attractive.
Unknown targets and out-of-range values 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-counterfactual-exposure-planner.git
cd shpbl-counterfactual-exposure-planner
npm install # devDependencies only: typescript
npm run build # compiles to dist/
npm test # 25 behavioural, boundary and fail-closed tests
npm start # starts the MCP server on stdioMCP client configuration:
{
"mcpServers": {
"shpbl-counterfactual-exposure-planner": {
"command": "node",
"args": ["/absolute/path/to/shpbl-counterfactual-exposure-planner/dist/src/mcp-server.js"]
}
}
}exposure_baseline — Measure a sealed exposure graph without mutating it
exposure_simulate — Simulate one intervention scenario against current exposure state
exposure_rank — Rank multiple counterfactual scenarios deterministically and identify Pareto-efficient options
Sealed baseline measurements, per-scenario risk/attack-surface/cost metrics with canonical digests, a deterministic ranking, and Pareto flags.
Reproduce all of it from a clean clone with npm run check:
Strict TypeScript compile and --noEmit typecheck: PASS
Behavioural tests: 25/25 PASS
Randomised invariant hammer: 30,000 cases / 120,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
Results describe the graph you supply; missing assets, edges or findings produce a confident answer about an incomplete world.
No scanner or vendor API client is embedded and nothing is changed in production.
Criticality variation is an explicit assumption, not a measurement.
Cost is the caller's declared intervention cost, not an economic model.
This product exists because two things were put together, and both are credited.
Upstream capability inspiration — packetchaos/navi, by Casey Reid (packetchaos), 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 Casey Reid (packetchaos), Tenable, or any other party.
Submitted to the Tenable CyberAgents Exchange for review on September 14, 2026 — pull request #175. 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.
Measure a sealed exposure graph without mutating it
| Name | Required | Description | Default |
|---|---|---|---|
| graph | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does explicitly state that the tool does not mutate the graph, which is valuable. However, it does not describe what 'measure' returns, what 'sealed' implies about allowed inputs, or any error or side-effect 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, front-loaded sentence with no filler. Every word contributes to the core meaning: the action, the object, and the non-mutating guarantee.
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?
For a tool with no annotations, no output schema, and only a generic object parameter, this description is too sparse to fully support correct invocation. It does not explain the output format, how 'baseline' differs from the sibling tools, or what constraints a 'sealed exposure graph' imposes.
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 identifies the parameter as a 'sealed exposure graph' without explaining its required shape or how to construct it. This adds some domain meaning beyond the bare schema, but it does not sufficiently compensate for the lack of schema documentation on a nested object parameter.
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 ('Measure') and resource ('sealed exposure graph'), and adds the important qualifier 'without mutating it,' which clarifies the operation's intent. It does not explicitly distinguish itself from the sibling tools exposure_simulate and exposure_rank, but 'measure' is reasonably distinct from those verbs.
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 provides minimal context ('sealed exposure graph') but gives no guidance on when to use this tool versus exposure_simulate or exposure_rank, and no exclusions or prerequisites. An agent would have to infer the appropriate use case from the tool name rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank multiple counterfactual scenarios deterministically and identify Pareto-efficient options
| Name | Required | Description | Default |
|---|---|---|---|
| graph | Yes | ||
| scenarios | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself carries the behavioral disclosure burden. It adds the concrete trait 'deterministically' and indicates that the result is a Pareto-efficient selection, valuable non-obvious information. However, it does not describe side effects, permissions, or the return format beyond this selection, leaving a residual transparency gap.
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?
A single, tight sentence that front-loads the action and is free of filler. Every word contributes to the core concept, making it easy to parse and retain.
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 nested objects (graph and scenarios), no output schema, and no annotations, yet the description stays only at a high level. It does not explain what relative structure the graph must take, what counts as a counterfactual scenario, or how the resulting Pareto-efficient options are represented. This is insufficient for correct invocation by an agent.
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 gives 'scenarios' a semantic meaning as 'counterfactual scenarios', but the 'graph' parameter is not mentioned at all, and no guidance is provided on the structure or relationship between the two parameters.
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 ('Rank') and resource ('multiple counterfactual scenarios'), and adds the distinct function of identifying Pareto-efficient options. This separates it from siblings exposure_baseline and exposure_simulate, though it does not explicitly name them as alternatives.
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 this tool versus exposure_baseline or exposure_simulate. The phrase 'multiple counterfactual scenarios' implies a use case, but it does not provide conditions, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate one intervention scenario against current exposure state
| Name | Required | Description | Default |
|---|---|---|---|
| graph | Yes | ||
| scenario | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Simulate' hints at non-mutating hypothetical evaluation, but the description never confirms whether state is modified, whether it is read-only, what inputs may be invalid, or what the output looks like. For a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded with the main action, so it is not bloated. However, the brevity reflects under-specification rather than disciplined conciseness, so it earns a middling score rather than a high one.
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?
For a tool with two complex nested object parameters, no output schema, and no annotations, this description is far too sparse. An agent cannot determine the required shape of scenario, how it relates to the graph, or what the simulation returns. Given the complexity signals, the definition is incomplete 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 both parameters are bare untyped objects, yet the description adds nothing about the structure or meaning of 'graph' and 'scenario'. Besides their names, an agent has zero information about what to pass — this is the low-coverage case where the description was required to compensate, and it entirely fails to do so.
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 ('simulate') and resource ('one intervention scenario against current exposure state'), which clearly distinguishes it from the sibling tools exposure_baseline and exposure_rank. It is slightly terse about what the simulation produces, but the core purpose is unambiguous.
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 choose exposure_simulate over exposure_baseline or exposure_rank, nor any mention of prerequisites (e.g. whether the graph must first be initialized). The agent must infer usage entirely from the tool name and one-line description.
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.0exposure_baselineexposure_rankexposure_simulateScored across 3 tools
Each tool has a clearly distinct role: baseline measurement, single-scenario simulation, and multi-scenario ranking. There is no real overlap or ambiguity between these three operations.
All tools share the exposure_ prefix and snake_case, which makes them predictable. The minor deviation is that exposure_baseline uses a noun while exposure_simulate and exposure_rank use verbs, slightly breaking a pure verb_noun pattern.
Three tools is on the lower end but appropriate for a tightly scoped counterfactual exposure planner. Each tool covers a distinct stage in the workflow and none feels redundant.
The core planning workflow of baseline, simulate, and rank is well covered. The main gap is the lack of tools for defining/persisting scenarios or applying a chosen intervention, but this is not a fatal omission for a planner.
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Portfolio scenarios with instrument checks, Monte Carlo analysis and interactive reports.
Auditable US clean-energy tax-credit scenarios for 45Q, 45V, 45Y, 48E, and 45X.
IaC attack-path auditor: finds internet-to-crown-jewel chains in Terraform/CFN/K8s.