This MCP server provides fast, TypeSafe-powered decision primitives, verbatim context compaction, and safety guardrails for coding agents.
jev_compact: Compacts bloated context by pruning old verbose tool results while preserving conversation messages 100% verbatim.
jev_decide_choice: Performs fast multi-option classification with confidence and relative probabilities.
jev_decide_noul: Returns a calibrated boolean probability (0.0–1.0) for a yes/no verification question.
jev_decide_score: Scores context on an ordered rubric scale (e.g. severity/quality).
jev_guard: Audits risky commands or tool calls for security and loop-detection before execution.
jev_status: Checks Jev provider connectivity, model availability, and response latency.
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., "@universal-jev-mcp Compact this conversation and keep all messages verbatim."
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.
Universal TypeSafe Jev Runtime Plugin, MCP Server & Autonomous Browser Engine for Coding Agents (Codex, Pi, DSH, OpenCode, Antigravity).
Jev-Verified Receipt Extraction (95%+ Token Savings):
Evaluates lengthy terminal outputs (builds, tests, linters, game engine logs) using TypeSafe Jev System 1.
Dehydrates passing logs into high-confidence verified receipts ([Jev Verified Receipt ✓]) with 100% transparency to LLMs.
Isolates failure/error traces ([Jev Diagnostic Warning ⚠️]) while pruning routine output.
Triple Safety Barrier:
Unified Diff & Patch Immunity: Git diffs (diff --git, @@ ... @@) and patch outputs are strictly protected from pruning.
Exit-Code Fast-Path: Non-zero process exit codes immediately bypass LLM probabilistic guessing with 0ms latency and 100% deterministic diagnostic failure.
Smart Anchor Sampling & Middle Error Isolation: Automatically scans un-sampled intermediate log regions for errors (traceback, script error, exception), ensuring intermediate crashes (e.g. Godot/Blender/Cargo runs) are never concealed by normal trailing logs.
Universal 2-Tier Browser Engine (jev-ultrafast × browser-use):
Tier 1 (jev-ultrafast): Sub-second indexed DOM decisions via TypeSafe Jev System 1 (zero vision LLM overhead).
Tier 2 (browser-use Fallback): Automatically falls back to full multimodal semantic snapshots and visual reasoning when encountering CAPTCHAs, complex canvas, or blocked states.
Zero User Disruption: Always creates a fresh, isolated Ego Lite TaskSpace, leaving your personal tabs untouched.
Instant Cleanup: Space is guaranteed to be closed and destroyed immediately upon task completion in a finally block.
Verbatim Context Compaction & Auto Image Dehydration:
Compresses bloated conversation history while preserving user instructions 100% verbatim.
Automatically dehydrates images after 3 model turns, liberating up to 90% vision token budget.
Fast Decision Primitives:
Millisecond multi-choice classification (Choice), boolean hypothesis probability (Noul), rubric evaluation (Score), and security guardrails (Guard).
Related MCP server: context-architect
Requires Node.js 20+.
git clone https://github.com/raj8525/universal-jev.git ~/.agents/plugins/universal-jev
cd ~/.agents/plugins/universal-jev
./install.shSet your API key (Official TypeSafe API or OpenRouter fallback):
# Official TypeSafe System 1 Endpoint (Recommended)
export TYPESAFE_API_KEY="apikey_..."
# Or OpenRouter Fallback:
export OPENROUTER_API_KEY="sk-or-v1-..."对于已经安装过的用户，更新过程100% 平滑、幂等且无损：
直接进入项目目录重新运行安装脚本：
cd ~/.agents/plugins/universal-jev && ./install.sh为什么推荐直接运行 ./install.sh？
自动拉取：脚本会自动检查并执行 git pull --ff-only 同步 GitHub 上的最新提交。
配置幂等：脚本内置各 Agent 配置检测（OpenCode, Codex, Antigravity, Pi），绝不重复添加、不覆盖已有配置。
符号软链接：全局命令（~/.local/bin/jev、universal-jev-mcp 等）是指向仓库源码的软链接，更新后立即指向最新代码。
自动刷新 Schema：自动同步 Antigravity 最新的 MCP 工具定义（如 exitCode 参数）。
cd ~/.agents/plugins/universal-jev && git pull由于 ~/.local/bin/ 下的指令均为软链接，执行 git pull 后代码立即更新生效。
Agent 客户端 | 生效方式 | 是否需要重启应用 |
Codex (GPT-6) | 每次运行命令独立调用 In-Flight Hook ( | 无需重启！ 下一次在终端执行命令即自动应用最新补丁。 |
Antigravity / Gemini | 通过 MCP Server 连接 | 无需重启 IDE，新建会话（New Chat）或重连 MCP 即可生效。 |
OpenCode / Claude Code | 通过 MCP Server 连接 | 新建会话（New Session）或重启一次命令行即可。 |
Pi Coding Agent | TypeScript 扩展插件加载 | 重启 Pi 客户端或执行 |
# 1. 检查 API 连通性与模型延迟
jev status
# 2. 自主 2-Tier 浏览器任务 (jev-ultrafast -> browser-use 自动降级)
jev browse https://example.com "Verify page title and confirm done"
# 或直接通过专用 CLI:
ego-browse https://www.google.com/travel/flights "Find one-way flights from Zurich to London on Sep 20"
# 3. 布尔真值置信度验证 (Noul)
jev noul "Is this an emergency?" --state "Database CPU 100%"
# 4. 多选项分类 (Choice)
jev choice "Department" --criteria "infra:Server down,billing:Payment issue" --state "Service timeout"
# 5. 标尺评分 (Score)
jev score "Severity" --criteria "low,medium,high" --state "SyntaxError in script"
# 6. 命令安全风控检查 (Guard)
jev guard "rm -rf /"
# 7. 查看 Token 节省数据遥测
jev stats
# 8. 会话历史无损脱水
jev compact transcript.json --out compacted.json运行 ./install.sh 后，已为各大 Agent 自动注册如下能力：
Codex (GPT-6)：通过 universal-jev-codex-hook 拦截工具输出，长日志毫秒级收据化。
Pi Agent：通过 pi-extension.ts 实现工具结果脱水与 >=3 轮图片上下文自动瘦身。
Antigravity / OpenCode / Claude Code：通过 universal-jev-mcp 暴露核心工具：
jev_receipt：终端与工具长日志脱水为验证收据（支持 exitCode 短路）。
jev_compact：对话历史上下文无损压缩。
jev_decide_choice：快速多选项分类。
jev_decide_noul：布尔假说真值概率评估 ($0.0 \sim 1.0$)。
jev_decide_score：有序评分标尺。
jev_guard：高危命令与死循环熔断防护。
jev_status：服务连通性与延迟探针。
# 运行全量端到端测试 (原语、压缩、MCP Stdio 协议、收据)
npm test
# 运行收据脱水引擎专项测试 (涵盖 Diff 免疫、退出码短路、中间盲区采样等 7 大场景)
node ./test/test-receipt.jsMIT
Verbatim context compaction: prunes old verbose tool results while preserving conversation messages 100% verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| rawJson | No | Raw JSON or JSONL transcript string | |
| messages | No | Array of conversation message objects | |
| truncateHeadChars | No | Chars of output retained before omission note (default 250) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it explicitly discloses what is destroyed (old verbose tool results) and what is preserved (conversation messages verbatim). It stops short of saying whether the operation is reversible, how output is returned, or whether it mutates inputs, but the core safety profile is clear.
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 front-loaded sentence conveys the tool's purpose and its most important constraint. There is no filler or repetition of schema details.
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 is simple and all three parameters have schema descriptions, so the definition is adequate for basic invocation. It does not explain what the tool returns or how rawJson and messages interact, and with no output schema those details would need to come from the description to be fully complete.
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 coverage is 100%, so the parameters are already documented. The description adds useful context by mapping 'old verbose tool results' and 'conversation messages' to the tool's inputs, but it does not go into details about truncateHeadChars beyond the schema.
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 concrete operation ('prunes old verbose tool results') and a hard constraint ('preserving conversation messages 100% verbatim'), making the tool's function unmistakable. This also sets it apart from the decision/status sibling tools, which address different concerns.
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 phrase 'context compaction' implies when the tool should be used, and the preservation constraint explains a key selection criterion. It never explicitly says 'use this when context is too long' or names alternatives, so the agent must infer the usage situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast, calibrated multi-option classification with confidence and relative probabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Context or text to classify | |
| criteria | Yes | Mapping of option key to description | |
| question | Yes | Classification instruction or question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful behavioral context by promising calibrated output and relative probabilities rather than just a label. However, it does not disclose the exact return shape, side effects, or behavior for ambiguous inputs.
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 short, front-loaded sentence with no filler. It is concise, but slightly under-specified for a tool with no annotations and no output schema, so it does not quite earn a 5.
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 description omits when to use the tool, what the question field should contain, and how the returned confidence/probabilities are structured. With no output schema and no annotations, the one-sentence description is not sufficient for reliable selection and 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?
All three parameters are already described in the schema (100% coverage), so the baseline is 3. The description connects criteria to the multi-option classification concept but adds no parameter-level detail beyond what the schema already provides.
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 identifies the core operation as 'multi-option classification' and names key outputs ('confidence and relative probabilities'), which is a clear verb+resource statement. It does not explicitly differentiate this from sibling decision tools such as jev_decide_noul or jev_decide_score, so it stops short of 5.
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 for when to use this tool instead of alternatives like jev_decide_noul or jev_decide_score. The word 'Fast' hints at a possible use case, but it is not actionable enough to help an agent choose between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calibrated boolean verification (Noul) returning true probability between 0.0 and 1.0.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Context or assertion to verify | |
| question | Yes | Yes/No verification question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It discloses the output type and that results are 'calibrated,' but it does not explain side effects, interpretation of the probability, or what 'Noul' means. This is adequate for a simple verification tool but not deeply transparent.
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, efficient 14-word sentence with the core behavior front-loaded. No wasted words, though the unexplained 'Noul' is a minor clarity cost.
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?
Given low complexity (2 string params, no output schema), the description covers the output range but omits usage guidance and interpretation of the returned probability, leaving some ambiguity for an agent choosing between sibling decision tools.
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 100%: both 'state' and 'question' have clear descriptions. The tool description adds no parameter-level detail, so the baseline of 3 applies.
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 operation: 'boolean verification' that returns a probability between 0.0 and 1.0. It distinguishes from siblings like jev_decide_choice and jev_decide_score by emphasizing the boolean/probability output, though the term 'Noul' is unexplained.
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 phrase 'boolean verification' and the schema's 'Yes/No verification question' imply use for yes/no checks, but the description does not explicitly state when to prefer this over siblings like jev_decide_choice or jev_decide_score, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calibrated rubric scoring across ordered levels (e.g. 0 to 3 severity/quality).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Context to evaluate | |
| criteria | Yes | Rubric descriptions in ascending order | |
| question | Yes | Scoring goal or metric |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It says 'calibrated rubric scoring' but does not state whether this is a read-only computation, whether it has side effects, or what kind of result 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and the core concept appears immediately. It is not over-padded, and every word contributes to the stated purpose.
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 three-parameter tool with no annotations and no output schema, this description is too thin. It leaves the agent to infer what a score looks like, how criteria map to levels, and what 'calibrated' means operationally.
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 100%, so the baseline is 3. The description's 'ordered levels' loosely reinforces the schema's ascending-order criteria, but it adds no new meaning about state, question, or criteria interpretation beyond what the schema already provides.
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 operation ('Calibrated rubric scoring') and its domain ('ordered levels'), so an agent can tell this is a scoring tool. However, it never contrasts itself with siblings like jev_decide_choice or jev_decide_noul, so the differentiation is only implicit.
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 explicit guidance is given about when to use this tool versus jev_decide_choice, jev_decide_noul, or other siblings. The phrase 'rubric scoring' implies a use case, but there are no exclusions, triggers, or alternative-selection hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Security and loop-detection guardrail before running risky commands or tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command line or tool action to audit | |
| context | No | Working directory or intent context |
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. It describes a 'guardrail' metaphorically but does not state what happens when a risk or loop is detected, whether it blocks, warns, returns a verdict, or has side effects. This is a meaningful gap for a safety-related tool.
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 defining the tool's role and timing.
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?
With no annotations and no output schema, the description should explain how the agent uses the guardrail's result, what the tool returns, and how to interpret it. None of this is present, leaving an agent uncertain about the tool's end-to-end behavior.
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 100%, so the baseline is 3 and the schema already documents both parameters. The description adds minimal semantic context beyond pointing at 'risky commands or tool calls,' which loosely maps to the command parameter but adds little for the context 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 identifies the tool as a security and loop-detection guardrail used before risky commands or tool calls, which clearly communicates a distinct role. It lacks a crisp imperative verb, but the purpose is clear and it differs meaningfully from the sibling decide/status/compact tools.
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 phrase 'before running risky commands or tool calls' gives clear contextual guidance on when to invoke the tool. It does not explicitly mention alternatives or when not to use it, but the usage context is reasonably unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Jev provider connectivity, model availability, and response latency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 behavioral disclosure, but it only lists what is checked. It does not state whether the call is read-only, whether it performs network requests, what it returns, or how failures/latency results are represented.
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. It leads with the verb and enumerates the three check targets efficiently, making it easy to scan.
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 zero-parameter status check, the description covers the invocation targets and is adequate for selecting the tool. It is incomplete in that it never describes the result shape or behavioral caveats, which matters because there is no output schema to fill the gap.
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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The description adds no parameter details, but none are needed; the baseline for no parameters is 4.
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, 'Check', and names concrete resources: Jev provider connectivity, model availability, and response latency. It clearly states what the tool does, though it does not explicitly distinguish it from sibling tools such as jev_decide_* or jev_compact.
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 wording implies the tool should be used when a health/status probe of the Jev provider is needed, and the sibling names suggest non-overlapping purposes. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives.
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.0jev_compactjev_decide_choicejev_decide_nouljev_decide_scorejev_guardjev_statusScored across 6 tools
Each tool targets a distinct operation: compaction, guard, status, and three decision types that differ in output format (classification, boolean, score). The decide_* tools are clearly differentiated by their suffixes and descriptions, leaving no genuine ambiguity.
All tools use the 'jev_' prefix followed by snake_case verbs and descriptive modifiers (compact, decide_choice, decide_noul, decide_score, guard, status). The pattern is uniform and predictable, with no mixing of conventions.
Six tools is well within the ideal 3-15 range, providing a focused utility set without redundancy or bloat. Each tool earns its place for the server's stated purpose.
The tool surface covers core utility needs: compaction, guardrails, status monitoring, and three decision modalities. Minor gaps exist (e.g., no configuration tool or free-form generation), but these are likely outside the intended scope and do not create dead ends for typical workflows.
Deterministic contextual decision arbitration and action routing for autonomous software. Takes current state, context, or intent plus caller-supplied candidate actions, state transitions, routes, refusals, escalations, tools, or models and returns a deterministic ordered candidate field. Also provides persistent machine representations for memory, retrieval, indexing, and downstream coherence measurement.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.
