How do I use aside-jev?

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., "@aside-jev Score how risky it is to click the delete button" 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.

aside-jev

by himomohi

Overview Schema Source Related Servers Discussions Admin

Python

Remote

English | 한국어

Aside Jev connects the Aside REPL with TypeSafe Jev. A toolbar toggle, a persistent REPL session, and bounded action selection work together in one browser workflow.

Current status: 0.2.0 source preview · not yet released ON applies to new task instructions and the extension-specific MCP for the selected Aside account. jev_browser_run delegates action selection to Jev. The extension does not intercept all built-in Aside tools.

Same Jev. Two strategies. One race.

New SDK client per request vs connection reuse. Watch both lanes on the same time scale, then compare p50, p95, and TCP connections.

What this measures: both methods use the same Jev SDK in a localhost transport benchmark. Actual browser task speed with the default Aside model versus Jev has not been measured. This animation expands measured p50 values; it is not a screen recording. Method and limitations

The dashboard and extension popup default to English. Choose Korean in the English / 한국어 menu; each surface remembers your selection. Localization guide

Related MCP server: Jev MCP

Small candidate sets. Clear execution.

Bounded decisions	Grounded actions	Visible state
Compact the relevant observation and send only allowed candidates to Jev.	Use targets observed on the current page and check again before execution.	Inspect ON/OFF, connectivity, confidence, and timing.
The model does not invent code, selectors, or input values.	Stop on repetition, no progress, or stale observations.	Errors never silently switch to another model.

See the decision

Keep the goal and candidates in the main workspace, with longer observations and model settings in a separate panel. Results show candidate probabilities, decision time, round-trip time, and the latest 20 records from the current session.

One connection. A continuous decision loop.

flowchart LR
    A["Aside REPL<br/>Observe current page"] --> B["Compact context<br/>Build allowed candidates"]
    B --> C["Jev<br/>Choose a candidate ID"]
    C --> D{"Check confidence<br/>and current state"}
    D -->|Allowed| E["Aside<br/>Execute selected action"]
    E --> A
    D -->|Completion verified| F["Complete"]
    D -->|Stop condition| G["Stop · Resume manually"]
    classDef surface fill:#F4F5EE,stroke:#9AA991,color:#193326
    classDef decision fill:#203D2F,stroke:#203D2F,color:#F4F5EE
    classDef result fill:#DCE8C8,stroke:#A9BC8D,color:#193326
    class A,B,E surface
    class C,D decision
    class F,G result

One Aside MCP/REPL session stays open throughout a task. Refresh observations and candidates when the page changes, and execute only the valid candidate selected by Jev. Completion text and an optional URL condition are checked locally; the page is checked again after Jev selects finish.

Condition	Behavior
Repeated page/action or a page cycle	Stop the loop
No observable change after execution	Stop with `no_progress`
Page changes after the decision	Do not execute stale candidates
Low confidence, unknown ID, or Jev error	Stop without an automatic fallback
Step or time budget exhausted	Return state for manual resumption
OFF or a higher confidence threshold during selection	Recheck policy before execution

Install in a few steps

Windows and macOS · no Git, Python, or uv setup required. Install and sign in to Aside first.

Download ZIP and extract it.
Run Install.cmd on Windows or Install.command on macOS. Choose your Aside account and enter your Jev key when prompted. Review the changes and confirm.
Reopen Aside → Extensions → Developer mode → Load unpacked, select the folder printed by setup, pin Aside Jev, and turn ON. Start a new task.

The installer prepares a private Python environment, copies the extension to a stable folder, and adds the Jev MCP connection while preserving your other settings. The extension ID is fixed across computers. Quit Aside before confirming setup so it cannot overwrite the account settings during installation.

Windows Native Messaging needs the registration key used by your Aside build. Setup proposes an existing Aside NativeMessagingHosts location when found; otherwise it asks for a verified key. We have not verified that final browser connection on a Windows PC. Windows details and troubleshooting →

If macOS does not open the downloaded .command, run bash scripts/install.sh in the extracted folder. Do not disable OS security checks. English is the default; use .\Install.cmd --lang ko or bash scripts/install.sh --lang ko for Korean prompts.

Installation details, update & removal →

uv sync
uv run aside-jev setup --dry-run
uv run aside-jev dashboard --open

The local demo uses http://127.0.0.1:8766. Add --port 0 for an available port. Existing Python/uv users can run uv run aside-jev setup for guided connection setup.

Live decisions require TYPESAFE_API_KEY or TYPESAFEAI_API_KEY. Setup accepts hidden terminal input or --env-file; keys stay in a local, unencrypted account-accessible file and never enter the popup. Key presence is not authentication proof.

Start the general decision tools over stdio:

uv run aside-jev serve

To enforce the popup's ON/OFF state and Live-only policy, use the installed wrapper or the following command after configuring the extension connection:

uv run aside-jev serve --extension

./scripts/install.sh only installs the Python package. Account instructions, Native Messaging, and MCP registration are part of the separate installation process.

Find the targetId of an already-open Aside tab and pass it to jev_browser_run:

{
  "goal": "Follow Continue until the Journey complete page",
  "target_id": "targetId-of-the-current-Aside-tab",
  "action_rules": [
    {"role": "link", "name": "Continue", "action": "click"}
  ],
  "completion_text": "Journey complete",
  "max_steps": 12,
  "total_timeout_s": 90,
  "min_confidence": 0.7
}

Supported actions: click, focus, fill. fill uses only the specified value.
Rules: provide exact accessible names within the user's authorized scope. Missing or ambiguous targets stop execution.
Completion: use distinctive completion_text. Add completion_url to require an exact URL match.
Default budget: 12 steps and 90 seconds total. Actions requiring separate approval must be approved before being added as candidates.

Reuse connections. Reduce overhead.

Reuse the SDK client and HTTP connection, and process MCP decision requests outside the event loop. Automatic retries are disabled; requests and tasks have explicit limits.

Local SDK transport benchmark · 30 requests per method · 2026-09-20

Metric	New client per request	Connection reuse
p50	1.157ms	0.540ms
p95	1.695ms	0.747ms
TCP connections	30	1

Transport-path p50 overhead fell by approximately 53.3% in this environment. This measures localhost SDK transport, not actual Jev inference speed. The default HTTP timeout of 15 seconds applies separately to connect, read, write, and pool waits.

Measurement method and boundaries →

A small toolset

Tool	Purpose
`jev_browser_run`	Observe → Jev selection → execute → verify in a persistent REPL session
`jev_extension_status`	Inspect ON/OFF state and connection readiness
`jev_system_one`	General Jev questions using Choice / Score / Noul
`jev_choose`	Select one ID from app-owned candidates
`jev_step`	Select, check confidence, and return the execution payload
`jev_validate`	Locally verify that an ID belongs to the candidate set

The general MCP/CLI jev_choose and jev_step support mock for testing. The extension-specific MCP and jev_browser_run are Live-only.

What has been verified

Verified locally	Not yet verified
Recorded Python and JavaScript regression checks	Live Jev authentication, decision quality, and inference latency
Six local page transitions and completion in actual Aside — decisions supplied by a fixture stub	Success rates across general websites
Native Messaging, ON/OFF, and backup/recovery in temporary profiles	Extension installation and MCP registration in a real user account
Local demo UI, input errors, and narrow-screen layout	Forced routing of all built-in Aside tools

See validation records for exact check counts and localization evidence.

OFF removes the managed instruction block from the selected profile. The status-check skill file remains.
OFF and timeouts do not undo browser actions already sent. If execution_state: unconfirmed, inspect the page before resuming manually.
Completion conditions and action rules are task-specific. This has not been validated as a universal browser agent.
Context sanitization limits size and masks credential patterns. It does not identify every possible personal or secret value.
The hero is generated concept artwork. Actual UI and execution evidence are identified in the validation record.

Development

uv sync --extra dev
uv run pytest -q
node --test tests/test_extension_controller.mjs
uv run python scripts/benchmark_latency.py --samples 30

# Verify six localhost transitions in actual Aside.
# This exercises browser execution without calling the Jev API.
uv run python scripts/verify_browser_runtime.py

Read more	Contents
Extension setup	Local connection, account setup, ON/OFF, disabling
Feature map	Entry points, source files, checks
Validation	Tests, runtime evidence, measurements, limits
Localization	English defaults, Korean dictionaries, localized media
Changelog	Changes by version

Available Tools

6 tools

jev_browser_runA

Run observe → Jev → execute in one persistent Aside REPL session.

action_rules are explicitly authorized exact role/name/action rows; fill also
requires an explicit value. Never include an action needing ungranted user
approval. Supports click/focus/fill only. Uses live Jev, never a fallback LLM.
A completion_text and optional exact completion_url verify success locally.
Stops on stale observations, repeated actions/pages, errors and budgets.

ParametersJSON Schema

Name	Required	Description	Default
`goal`	Yes
`max_steps`	No
`target_id`	Yes
`timeout_s`	No
`action_rules`	Yes
`completion_url`	No
`min_confidence`	No
`completion_text`	Yes
`total_timeout_s`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior5/5

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

No annotations are present, so the description carries the full burden, and it does so thoroughly. It discloses live-Jev-only execution (never a fallback LLM), exact authorization semantics for action_rules, explicit verification through completion_text/completion_url, and specific stopping conditions including stale observations, repeated actions/pages, errors, and budgets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is dense and front-loaded, opening with the core pipeline and then adding only high-value constraints. Every sentence earns its place: authorization rules, supported actions, model behavior, verification, and stopping conditions. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no annotations and zero schema coverage, the description covers stopping behavior and constraints well, and an output schema exists so return values need not be described. Still, key invocation details remain unclear, such as what target_id refers to and how min_confidence and the timeout parameters behave. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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 does add real meaning for action_rules (exact role/name/action rows, explicit fill value) and for completion_text/completion_url (success verification). However, it leaves several parameters unexplained, including goal, target_id, max_steps, timeout_s, min_confidence, and total_timeout_s, so compensation is only partial.

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 clear verb and resource: it runs the observe → Jev → execute loop in one persistent Aside REPL session and explicitly names the supported action types (click/focus/fill). It does not directly contrast with siblings like jev_step or jev_validate, but the 'one persistent session' and full-pipeline language make its role reasonably distinguishable.

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 gives useful constraints that imply when the tool is appropriate: action_rules must be explicitly authorized, only click/focus/fill are supported, and live Jev is used. However, it offers no explicit guidance on when to prefer this tool over the sibling step tools, nor any exclusion criteria such as 'use jev_step for debugging individual actions.'

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

jev_chooseC

Choose an app-owned action ID. No action is executed by this tool.

ParametersJSON Schema

Name	Required	Default
`goal`	Yes
`model`	No	jev-latest
`prefer`	No
`history`	No
`provider`	No	live
`timeout_s`	No
`candidates`	Yes
`observation`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 description carries the full burden. It only discloses that no action is executed, but omits error behavior, latency/cost, side effects, authentication, and return semantics. The one disclosed behavior is useful but insufficient.

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?

Two terse sentences with zero filler, front-loading the verb and adding the key non-execution caveat. Efficient, though brevity comes at the cost of needed detail.

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?

With 8 parameters at 0% schema description coverage, no annotations, and a two-sentence description, an agent lacks essential context for input construction and tool behavior. The output schema does not compensate for missing parameter semantics.

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%, and none of the 8 parameters (including required goal, observation, candidates) are explained in the description. The tool cannot be correctly invoked without guessing parameter formats.

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?

States a specific verb ('Choose') and resource ('app-owned action ID'), with an explicit non-execution caveat that distinguishes it from execution siblings. Core purpose is clear even though alternatives are not named.

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 on when to use this tool versus jev_step or jev_browser_run. No mention of prerequisites, selection criteria, or when to prefer this tool over alternatives.

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

jev_extension_statusA

Read the popup toggle state; this does not change settings or call Jev.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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 transparently states the operation is read-only and side-effect-free: 'does not change settings or call Jev.' It does not describe return behavior, but an output schema is present, so this is not a critical omission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single tightly packed sentence. It front-loads the primary action and resource, then adds a valuable side-effect clarification without any filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter status tool with an output schema, the description captures the essential context: what is being read and that no side effects occur. It is slightly light on how this relates to the sibling tools, but the negative 'does not call Jev' provides enough distinction for safe selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero properties and schema description coverage is 100%, so there are no parameters needing elaboration. Per the 0-param baseline, the description need not add parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Read the popup toggle state.' It also explicitly distinguishes itself from the Jev action siblings by noting it 'does not change settings or call Jev,' so an agent can tell it apart from tools like jev_step or jev_browser_run.

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 this is the right tool for read-only status checks through 'Read the popup toggle state' and the exclusion 'does not change settings or call Jev.' However, it never names a specific sibling or states a concrete condition for when to prefer this tool over alternatives.

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

jev_stepC

Choose, validate, and apply a confidence gate; return an execution payload.

ParametersJSON Schema

Name	Required	Default
`goal`	Yes
`model`	No	jev-latest
`history`	No
`provider`	No	live
`timeout_s`	No
`candidates`	Yes
`observation`	Yes
`min_confidence`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.1/5.0

Behavior2/5

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

The description says the tool 'applies a confidence gate' and returns a payload, but it does not explain side effects, whether anything is mutated or executed, preconditions, or failure behavior. Since no annotations are present, the description carries the full burden and only partially meets it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The sentence is compact and has no filler, using a clear semicolon to separate process from output. It is too terse, however, to be genuinely helpful for a tool with 8 parameters, so brevity trades away necessary substance.

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?

Given 8 parameters, required inputs, no annotations, and a 0% schema description coverage, this definition is far from complete. It does not explain what goal, observation, or candidates mean, how the confidence gate behaves, or what the execution payload represents, leaving the agent without enough context to call the tool correctly.

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%, and the description names none of the 8 parameters such as goal, observation, candidates, min_confidence, or timeout_s. With the schema providing only titles and types, the description was expected to compensate and does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description has a real verb structure ('Choose, validate, and apply a confidence gate') and an output ('return an execution payload'), so it is not a tautology. However, 'confidence gate' and 'execution payload' are unexplained jargon, and the actions overlap with sibling tools like jev_choose and jev_validate without distinguishing this tool from them.

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 provided about when to use jev_step versus alternatives such as jev_choose, jev_validate, or jev_system_one. There are no conditions, exclusions, or contextual hints, so the agent must infer the tool's place in the workflow.

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

jev_system_oneC

Call TypeSafe Jev System One with Choice / Score / Noul questions.

ParametersJSON Schema

Name	Required	Default
`model`	No	jev-latest
`state`	Yes
`questions`	Yes
`timeout_s`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2/5.0

Behavior1/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 for behavioral disclosure. It only says 'Call', providing no information about side effects, whether the operation is read-only or mutating, required permissions, rate limits, or output behavior. This is even less transparent than a minimally descriptive mutation tool like 'update_drive'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is a single short sentence with no filler, but it is under-specified rather than appropriately concise. It omits essential context needed to use the tool, so the brevity is not a product of careful triage but of lacking substance.

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?

Given a 4-parameter tool with nested objects and no annotations, this description is grossly incomplete. It does not explain state, questions, timeout, model selection, or how this tool relates to the sibling tools. The presence of an output schema does not compensate for missing usage context.

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 needs to compensate. It adds a slight hint that 'questions' involves Choice / Score / Noul types, but it says nothing about the state parameter, model, timeout_s, or how to structure the nested objects. The description does not meaningfully explain the required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('TypeSafe Jev System One') and an action ('Call'), and it mentions the question types (Choice / Score / Noul questions). However, 'Call' is a generic verb and the phrase does not explain what the system does, and it does not differentiate from siblings like jev_choose or jev_step.

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?

There is no explicit guidance on when to use this tool versus alternatives. The phrase 'with Choice / Score / Noul questions' hints at an input context, but no conditions, exclusions, or sibling comparisons are provided.

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

jev_validateC

Validate a supplied candidate ID and return its original action payload.

ParametersJSON Schema

Name	Required	Description	Default
`choice_id`	Yes
`candidates`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 reveals that validation returns an action payload, but says nothing about side effects, permissions, error handling, or whether validation changes state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

A single sentence that is grammatically tight, front-loads the verb, and contains no filler. It is appropriately concise for a tool with only two required parameters and an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is low in complexity and has an output schema, so the description does not need to explain return values. However, it omits parameter semantics and usage guidance, leaving an agent to infer how candidates and choice_id should be supplied and when this should be called over sibling tools.

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% for both required parameters. The description only hints that choice_id is a 'candidate ID' and says nothing about what candidates contains or how it relates to choice_id.

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 action ('Validate') and a clear resource ('supplied candidate ID') plus the result ('return its original action payload'). It does not explicitly distinguish itself from siblings like jev_choose or jev_step, but the core function is clear.

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 provided about when to use this tool versus jev_choose, jev_step, or jev_system_one. There are no preconditions, exclusions, or alternative selection criteria mentioned.

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.

6 tool updatesv0.2.0Sep 20, 2026
- First observedjev_browser_run
- First observedjev_choose
- First observedjev_extension_status
- First observedjev_step
- First observedjev_system_one
- First observedjev_validate

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

C2.8/5.0

Scored 2026-09-20 19:20 across 6 tools

Disambiguation3/5

jev_choose and jev_step both involve choosing actions, and jev_validate overlaps with the validation portion of jev_step. The descriptions clarify the boundaries reasonably well, but an agent could still confuse these tools when selecting the right step in a workflow.

Naming Consistency2/5

All tools share the jev_ prefix, but the second part mixes verbs (validate, choose) and nouns (system_one, step, extension_status, browser_run). There is no consistent verb_noun pattern, making the tool names feel ad hoc.

Tool Count5/5

Six tools is well-scoped for a Jev integration server covering verification, selection, gating, status, and full browser runs. Each tool serves a distinct purpose within the domain, and none feel redundant or unnecessary.

Completeness4/5

The toolset covers the core workflow of asking Jev, validating candidates, choosing actions, applying gates, checking state, and running an observe-validate-execute session. A small gap is the lack of an explicit stop/reset tool for the persistent REPL session, but the browser_run tool handles lifecycle limits internally.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ARBITER A
fyi.grip
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.
Agent Orchestration Autonomous Agents Knowledge & Memory
21
MeatSpace A
io.github.zmarten
Human-in-the-loop for AI agents. Submit choices, get a human decision.
Agent Orchestration
32
Superforms B
co.superforms
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Agent Orchestration Speech Processing App Automation
112
Vizier B
io.github.vassiliylakhonin
Deterministic authorization for one proposed AI agent action, returned with a signed receipt.
Security Autonomous Agents
11

Related MCP Servers

jev-mcp
CI/CD & DevOps Autonomous Agents Developer Tools
minhgv
A
license
A
quality
B
maintenance
Provides coding agents and CI with a typed decision layer that sends bounded state and questions to Jev, then returns deterministic actions for review, risk assessment, requirement checks, and verification.
Updated 5 days ago (2026-09-18 04:12 UTC)
9
MIT
Jev MCP
Autonomous Agents AI & Machine Learning Developer Tools
chungsubeen0
A
license
A
quality
B
maintenance
Enables frontier coding agents to delegate routine probabilistic judgments to TypeSafe Jev, providing calibrated triage signals for failures, attempts, completion, context ranking, findings, risk, and generic evidence-grounded questions.
Updated 4 days ago (2026-09-18 18:18 UTC)
7
MIT
jev-flash-router
Agent Orchestration AI & Machine Learning Autonomous Agents
Ravinder82
A
license
A
quality
B
maintenance
Enables AI coding agents to make fast, zero-output-token decisions by evaluating context, diffs, logs, or options through the OpenRouter Decisions API using TypeSafe Jev, returning calibrated probabilities for binary, categorical, or scoring questions.
Updated 3 days ago (2026-09-20 03:12 UTC)
1
136 npm
2
MIT
Jev MCP Proxy
AI & Machine Learning Autonomous Agents
altregubov
A
license
B
quality
C
maintenance
Enables AI agent skills to route state-evaluation requests to TypeSafe AI's Jev System One model, supporting typed questions, choice classification, binary probabilities, and rubric scoring with calibrated confidence.
Updated 5 days ago (2026-09-18 14:01 UTC)
4
MIT