cool-workflow
npm
v0.2.7
Source verified
Published by coo1white — publish provenance cryptographically ties this package to that repository. That is proof of origin, not an official vendor package.
A workflow control plane and run-time you are able to check: it sends out jobs in TypeScript, makes certain of work against facts before it goes through, puts state into fixed records, orders jobs by time, runs jobs again and again, gets a group of agents
The grade answers one question — how safe is this server for you to adopt — so it is computed in two auditable stages. Nothing below is an opinion or an LLM's guess; every line is a real term the deterministic engine applied, and the same input always yields the same number.
1. Threat score — 100 − 0 = 100. What the published surface and source actually contain:
The deterministic scan raised no scored threat in the surface it inspected — the threat score stayed at 100. Capability observations and advisory notes are recorded but never lower it.
2. Client adoption risk — 100 − 6 = 94. Three small, subtract-only factors that reflect your risk in adopting it — a clean scan proves less on a powerful, unverified or barely-inspectable package, so the grade says so plainly:
| Points | Adoption-risk factor |
|---|---|
| −6 | capability blast radius (high) — client exposure if the model is manipulated |
Capability observations and info notes are shown under Findings but never scored.
Open any row's finding below for the file, line and evidence behind a deduction.
In the server's implementation (`dist/mcp/tool-process.js:42`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: or = void 0; const node_child_process_1 = require("node:child_process"); const path = __importStar(require("node:path"))
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/mcp/tool-process.js
In the server's implementation (`dist/shell/commit.js:48`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ode:path")); const node_child_process_1 = require("node:child_process"); const fs_atomic_1 = require("./fs-atomic"); con
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/commit.js
In the server's implementation (`dist/shell/doctor.js:64`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ode:path")); const node_child_process_1 = require("node:child_process"); const agent_config_1 = require("./agent-config"
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/doctor.js
In the server's implementation (`dist/shell/execution-backend/agent.js:75`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: "node:os")); const node_child_process_1 = require("node:child_process"); const local_1 = require("./local"); const envel
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/execution-backend/agent.js
In the server's implementation (`dist/shell/execution-backend/container.js:13`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: unContainer; const node_child_process_1 = require("node:child_process"); const probes_1 = require("./probes"); const loc
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/execution-backend/container.js
In the server's implementation (`dist/shell/execution-backend/local.js:16`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: xecuteLocal; const node_child_process_1 = require("node:child_process"); const hash_1 = require("../../core/hash"); cons
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/execution-backend/local.js
In the server's implementation (`dist/shell/execution-backend/remote.js:51`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ode:path")); const node_child_process_1 = require("node:child_process"); const envelopes_1 = require("./envelopes"); con
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/execution-backend/remote.js
In the server's implementation (`dist/shell/onramp.js:36`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: ode:path")); const node_child_process_1 = require("node:child_process"); exports.CURATED_SMOKE_MAP = [ { pat
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/onramp.js
In the server's implementation (`dist/shell/remote-source.js:25`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: alizeRemote; const node_child_process_1 = require("node:child_process"); const node_crypto_1 = require("node:crypto"); c
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/remote-source.js
In the server's implementation (`dist/shell/workflow-app-loader.js:232`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: s const rawExport = require(entrypointPath); const selected = manifest.workflow.exportName && rawExport && typeo
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server dist/shell/workflow-app-loader.js
In a packaging/dev/install script (shipped, but not the server runtime) (`scripts/lang-policy-check.js:40`): Reading private keys / cloud credentials, or serializing the whole environment, is a sensitive-data source that becomes exfiltration when combined with any egress. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: fig", ".windsurfrules", ".npmrc", ".nvmrc" ]); // `EXCEPT_PATHS` are written repo-root-relative, so tracked files must
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server scripts/lang-policy-check.js
In a packaging/dev/install script (shipped, but not the server runtime) (`scripts/agents/claude-p-agent.js:32`): Spawning a shell/process is command-execution capability; with unsanitized tool input it is command injection / RCE. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: nSync } = require("node:child_process"); // Share the ONE canonical result contract with the codex/gemini/opencode // wr
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server scripts/agents/claude-p-agent.js
In a packaging/dev/install script (shipped, but not the server runtime) (`scripts/validate-run-state-schema.js:39`): Loading a module chosen at runtime (from a variable) can pull in and run attacker-influenced code paths. This is read from the code itself — not from the tool description — so a poisoned server cannot hide it behind honest-looking metadata.
Evidence: a; try { schema = require(SCHEMA_MODULE); } catch (e) { console.error(`validate-run-state-schema: FATAL — ca
Fix: Review this call path: confirm it never receives unsanitized tool input, constrain it, or remove it. Treat a server whose code reaches these sinks as high-capability regardless of what its tools claim.
Location: server scripts/validate-run-state-schema.js
Each tool and what it can reach — statically extracted from the published source.
cw_app_packageno sensitive capabilitycw_app_showno sensitive capabilitycw_app_validateno sensitive capabilitycw_approveno sensitive capabilitycw_candidate_listno sensitive capabilitycw_candidate_rankno sensitive capabilitycw_candidate_registerno sensitive capabilitycw_candidate_rejectno sensitive capabilitycw_candidate_scoreno sensitive capabilitycw_candidate_selectno sensitive capabilitycw_candidate_showno sensitive capabilitycw_comment_addno sensitive capabilitycw_dispatchno sensitive capabilitycw_feedback_collectno sensitive capabilitycw_feedback_listno sensitive capabilitycw_feedback_resolveno sensitive capabilitycw_feedback_showno sensitive capabilitycw_feedback_taskno sensitive capabilitycw_handoffno sensitive capabilitycw_node_diffno sensitive capabilitycw_node_replayno sensitive capabilitycw_node_replay_verifyno sensitive capabilitycw_node_showno sensitive capabilitycw_node_snapshotno sensitive capabilitycw_planno sensitive capabilitycw_rejectno sensitive capabilitycw_review_policyno sensitive capabilitycw_sandbox_chooseno sensitive capabilitycw_sandbox_resolveno sensitive capabilitycw_sandbox_showno sensitive capabilitycw_sandbox_validateno sensitive capabilitycw_summary_refreshno sensitive capabilitycw_summary_showno sensitive capabilitycw_topology_applyno sensitive capabilitycw_topology_graphno sensitive capabilitycw_topology_showno sensitive capabilitycw_topology_summaryno sensitive capabilitycw_topology_validateno sensitive capabilitycw_worker_failno sensitive capabilitycw_worker_listno sensitive capabilitycw_worker_manifestno sensitive capabilitycw_worker_outputno sensitive capabilitycw_worker_showno sensitive capabilitycw_worker_validateno sensitive capabilityScan history per published version. The engine is deterministic — the same version always yields the same score, so a changed score means the package itself changed.
| Version | Score | Findings | Engine | Scanned |
|---|---|---|---|---|
v0.2.7 latest |
A 94/100 | 13 | 1.13.0 | 2026-09-07 |
v0.2.6 |
A 94/100 | 13 | 1.13.0 | 2026-09-01 |
Show this server's live Trust Score in your README, docs or website. The badge is served straight from the registry and updates automatically after every rescan — no API key needed. It links back to this page, so anyone who sees the grade can also read the findings behind it instead of taking a number on faith.
The score above is reproducible: the same package version always yields the same result. Run it locally or over the free API — no account, no LLM, fully deterministic.
npx mcptrustchecker scan cool-workflow --online
Authenticated MCP transport with HTTP Signatures for AAuth agents
Local-first MCP server for parallel AI coding agents to claim file ownership before edits, preventing stomping on each other in the same worktree.
Agent-agnostic intercommunication system — sessions, messaging, channels, shared state, and real-time events
MCP server for AI agent task communication and delegation with diagnostic lifecycle visibility
Programmatic add/link/unlink for MCP servers across 23 AI coding agents (Claude Code, Claude Desktop, Cursor, VS Code, Codex, Gemini CLI, Zed, Cline, OpenCode, Goose, Kiro, Windsurf, and more). Functional API with dry-run support.
MCP server layer exposing agent-mesh orchestrator as an MCP agent