Jev MCP — ieee0824

This one is Rust over stdio for Codex with `jev.noul`, `jev.choice`, `jev.score`, and `jev.batch`, deterministic accept/verify/reevaluate policy, reliable/interactive profiles, and a bundled `jev-decisions` skill.

No. The digest states the server never reads files, collects history, or runs tools; the caller supplies evidence and finite candidates, and Jev is never a free-text planner or command generator.

The server maps confidence to accept, verify, or reevaluate, forcing open choices like unknown and other to reevaluate. Batch questions stay independent and cannot reference each other.

Reliable caps a single attempt at 30 seconds and 60 seconds overall with up to 2 retries on 429/529; interactive caps around 1.5 and 3 seconds with 1 retry and structured timeout errors instead.

Rust 1.88 or newer, a TypeSafe API key from the console, and an MCP client that speaks stdio. Build with `cargo build --release --locked` and the binary lands at target/release/jev-mcp. Add an [mcp_servers.jev] block to ~/.codex/config.toml pointing at that absolute path with tool_timeout_sec = 70, restart Codex, and either put the key in the config env block or pass it through env_vars from the environment.

Confidence is not independent for a noul, so the policy borrows from the probability itself. A value near 1 is a strong yes, near 0 a strong no, and near 0.5 an uncertain judgment. The deterministic policy class uses the distance of the yes probability from 0.5, so an answer sitting near the midpoint lands in verify or reevaluate rather than accept.

Setting JEV_TELEMETRY=1 emits one JSON line per tool call on stderr as JSONL with schema_version 1 and event jev_call. It records the tool name, question count, profile used, elapsed time, attempt and retry counts, timeout counts, the requested and resolved model, and input and output token counts, plus a structured error kind on failure. It never records state, instructions, criteria, probability distributions or API keys, and nothing goes to stdout.