This server exposes MCP tools that use TypeSafe Jev to observe a page, choose among explicitly allowed actions, and execute/verify browser steps, plus general-purpose decision and validation tools.
jev_browser_run: Runs a full observe → Jev selection → execute → verify loop in one persistent Aside REPL session, supporting click/focus/fill with completion text/URL checks, confidence gating, budgets, and stop conditions.
jev_choose: Selects one action ID from app-owned candidates based on the goal and observation; does not execute anything.
jev_step: Chooses, validates, and applies a confidence gate, returning an execution payload.
jev_validate: Checks whether a supplied candidate ID belongs to the candidate set and returns its original payload.
jev_system_one: Asks Jev structured questions using Noul (true/false criteria) and Score (ordered criteria) for completion/risk assessments.
jev_extension_status: Reads the extension popup's ON/OFF state and connection readiness without changing settings or calling Jev.
Supports live Jev for extension/browser tools and mock provider for general choice/step tools; connection reuse and bounded, inspectable decisions are emphasized.
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., "@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 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 release: 0.2.0 ON applies to new task instructions and the extension-specific MCP for the selected Aside account.
jev_browser_rundelegates action selection to Jev. The extension does not intercept all built-in Aside tools.
Icon-based popover with an animated connection control, on-demand diagnostics/settings, accessible labels, and reduced-motion support.
ON verifies the local MCP launcher, live Jev authentication, and the active Aside connection before unlocking extension MCP execution. Verification expires after one hour and is invalidated by settings/key changes or OFF.
macOS API keys are entered in a dedicated masked window and stored in Keychain. Windows retains its documented local credential path.
IP-based English/Korean tooltips and manual language override.
Bounded browser execution with fresh observations, completion/risk assessment, confidence checks, and stop-on-error behavior.
Guided Windows/macOS installation, localized documentation, and reproducible local transport benchmarks.
Release 0.2.0 · Download source and installers
The ZIP contains source and installation scripts, not a signed/notarized macOS app or a store-signed extension. See the installation guide. Windows CI covers isolated installation; real Windows browser integration remains unverified.
Related MCP server: jev-mcp
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 defaults to English. The extension uses Auto (IP): Korea selects Korean, other countries select English, with browser-language fallback when the lookup fails. You can override the language; the extension does not store your IP address. Localization guide
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. |
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.
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 resultOne 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 |
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 |
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
NativeMessagingHostslocation 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 --openThe 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.
On macOS, setup stores the API key in macOS Keychain, not in a plaintext file. Hidden terminal input and --env-file imports are supported; Windows retains its local environment-file storage. On macOS, the popup’s key icon opens a masked entry window; saved keys are never returned. Key presence is not authentication proof. See Keychain migration, rotation, and deletion.
Start the general decision tools over stdio:
uv run aside-jev serveTo 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 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 →
Tool | Purpose |
| Observe → Jev selection → execute → verify in a persistent REPL session |
| Inspect ON/OFF state and connection readiness |
| General Jev questions using Choice / Score / Noul |
| Select one ID from app-owned candidates |
| Select, check confidence, and return the execution payload |
| 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.
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.
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.pyRead more | Contents |
Local connection, account setup, ON/OFF, disabling | |
Entry points, source files, checks | |
Tests, runtime evidence, measurements, limits | |
English defaults, Korean dictionaries, localized media | |
Changes by version |
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.
Includes completion Noul and risk Score assessment after DOM completion.
verified is true only when both DOM and assessment pass; do not call a
separate assessment after success. On assessment_failed report partial
completion, never full success. Stops on stale observations and budgets.
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses that it uses live Jev (not a fallback LLM), stops on stale observations and budgets, includes a completion Noul and risk Score assessment, and defines exactly when 'verified' is true and how to report assessment_failed. It also warns against calling a separate assessment after success, which is critical operational guidance.
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 information-dense but not overly verbose. It front-loads the core purpose, then layers constraints, verification, and assessment behavior. While it includes domain-specific terms (Noul, Jev), each sentence adds value and no filler is present. The structure is logical, though a bit dense.
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 covers critical operational constraints (approval rules, verification mechanism, assessment failure handling) and notes the tool has an output schema (which reduces the need to describe return values). However, it omits explanations for several parameters (goal, timeouts, confidence) and doesn't describe how the REPL session interacts with the browser or the nature of the 'budget' that stops execution. Given the tool's complexity, this is a moderate 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?
Schema description coverage is 0%, so the description must compensate. It clarifies action_rules (exact role/name/action rows, fill requires explicit value) and explains completion_text/completion_url verification, but it leaves goal, target_id, timeout_s, max_steps, min_confidence, and total_timeout_s undefined. Only 3 of 9 parameters are meaningfully described, which is insufficient for a tool with no schema descriptions.
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 clearly states the tool runs a sequence of 'observe → Jev → execute' in a persistent REPL session, giving a specific verb and resource. It doesn't explicitly contrast with sibling tools like jev_step or jev_validate, but the composite flow is distinctive enough that an agent can infer its purpose.
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 implies usage for end-to-end browser automation ('Run observe → Jev → execute') and states constraints like 'Supports click/focus/fill only' and 'Never include an action needing ungranted user approval.' However, it doesn't explicitly say when to prefer this tool over siblings or when not to use it, leaving the selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose an app-owned action ID. No action is executed by this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| model | No | jev-latest | |
| prefer | No | ||
| history | No | ||
| provider | No | live | |
| timeout_s | No | ||
| candidates | Yes | ||
| observation | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Read the popup toggle state; this does not change settings or call Jev.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Choose, validate, and apply a confidence gate; return an execution payload.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| model | No | jev-latest | |
| history | No | ||
| provider | No | live | |
| timeout_s | No | ||
| candidates | Yes | ||
| observation | Yes | ||
| min_confidence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Call TypeSafe Jev with named questions. Each question uses type, instructions, criteria ONLY, never question or rubric. Score requires 2..64 ordered criteria from lowest to highest score. Noul uses true/false criteria descriptions. Example questions: {"completed":{"type":"noul","criteria":{"true":"The requested completion is visible","false":"Completion is absent"}}, "risk":{"type":"score","criteria":["No sensitive action","Reversible action","Sensitive or irreversible action"]}}. Report any error as an incomplete evaluation, never as overall success.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | jev-latest | |
| state | Yes | ||
| questions | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose an error-handling convention ('Report any error as an incomplete evaluation, never as overall success') and imposes input constraints, but it does not state side effects, permissions, or whether the operation is read-only. This is partial, not complete, behavioral transparency.
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 dense but not bloated; it front-loads the core action, then gives pragmatic constraints and a compact example. Each sentence adds necessary information, and the example JSON is directly useful without being excessive.
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 a schema that has no property descriptions, the description is the only source of semantics. It covers the nested 'questions' format and error conventions well, but it never defines the required 'state' parameter, nor does it explain 'model' or 'timeout_s'. An agent would likely struggle to construct a fully correct call.
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 explains the 'questions' parameter well: structure, supported types, criteria-count limits, and a concrete example. However, it leaves 'state', 'model', and 'timeout_s' semantically unexplained, which is a significant gap for a required 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 opens with a specific action ('Call TypeSafe Jev') and names the required payload shape (named questions with type/instructions/criteria). It is clear about what the tool does, though it does not explicitly contrast it with sibling tools such as 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use jev_system_one versus the sibling tools. The description focuses on how to format questions ('Score requires 2..64 ordered criteria', 'Noul uses true/false criteria descriptions') but does not state when to prefer this tool over alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a supplied candidate ID and return its original action payload.
| Name | Required | Description | Default |
|---|---|---|---|
| choice_id | Yes | ||
| candidates | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0jev_browser_runjev_choosejev_extension_statusjev_stepjev_system_onejev_validateScored across 6 tools
Several tools have overlapping responsibilities: jev_choose and jev_step both involve selecting an action, while jev_validate and jev_step both claim to validate. The descriptions help somewhat, but an agent could easily pick the wrong tool when choosing, validating, or executing a step.
All tools share a jev_ prefix, but the rest of the names follow no consistent pattern: single verbs like validate/choose, noun compounds like extension_status/system_one, and an inverted noun-verb in browser_run. This mixed style reduces predictability and makes the API harder to navigate.
Six tools is a reasonable size for a Jev/Aside-focused server, covering validation, evaluation, browser execution, extension status, and action selection. The count is not bloated, though some tools could potentially be consolidated.
The core workflow areas are represented: validation, system-one assessment, browser automation, and status reading. However, there is no obvious way to list available app-owned action IDs or modify extension settings, and the relationship between choose/step/validate leaves some workflow gaps.
Typed-question decisions from Jev: classify, moderate, route models and guard tool calls.
Human review for AI agents: ask through ActionBox and retrieve a typed decision before proceeding.
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.
Calibrated judgments for text: yes/no probabilities, picks from your options, or scores.
