jev-ultrafast-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browser_openA | Open a URL in a new owned tab and return the element table. Use |
| browser_observeA | Re-read the page: new element table, or a delta if little changed.
|
| browser_actA | Execute one or more ops in order, then return a delta observation. Batch ops into a single call — each call is a round trip. op fields click ref (ref may be "e12", or "e12" of a combobox to open it) type ref, text, [clear=true], [submit=false] select ref, value (option value or label) toggle ref, [state] (checkbox/radio/switch; no state = flip) hover ref upload ref, path | paths[] keys key ("Enter", "Meta+A", "ArrowDown") | keys[] scroll [dir=down|up|left|right], [amount=600], [ref] nav url back | forward | reload wait [ms=500] wait_for_ref ref, [timeout_ms=8000] wait_for_text text, [timeout_ms=8000] wait_for_load [timeout_ms=20000] screenshot [path], [full=false], [format=jpeg] (path names a file in the shots dir) tab action=list|new|switch|close, [index], [url] eval js (only when JEVMCP_ALLOW_JS=1) Actions matching the confirmation rules (pay, delete account, …) return
needs_confirmation; re-send that op with "confirm": true to proceed. That
covers every op that clicks, not only the one named A bare single character in |
| browser_assertA | Verify the current page against deterministic checks. Returns pass/fail. checks {"type": "url_matches", "pattern": "/checkout"} {"type": "url_contains", "text": "/orders/"} {"type": "title_matches", "pattern": "Order"} {"type": "text_contains", "text": "Thanks", "regex": false} {"type": "text_absent", "text": "Error"} {"type": "element_exists", "role": "button", "name": "Continue"} {"type": "element_gone", "ref": "e12"} {"type": "value_equals", "ref": "e7", "value": "Zurich"} {"type": "checked", "ref": "e9", "state": true} {"type": "count_at_least", "role": "link", "min": 3} {"type": "js", "expr": "document.title.length > 3"} |
| browser_macroA | Record, replay, list, or delete a macro — a discovered path with no model calls. action="record_start" begin capturing ops (needs the session to be driving the task)
action="record_stop" finish and save under A field the page marks as a secret is never written to the macro: its text is
stored as the placeholder {{secret}}, so pass Replay re-resolves each step by role + name against a fresh observation and refuses to act when the best match is weak or ambiguous. |
| browser_goalA | Hand a whole browser task over. Needs a decision-model key. This is the entry point for browser work, not an optimisation on top of the
manual loop. Pass Leave Each step costs one request (operation + every target head in a single
speculative fan-out). The decision model is reachable through two APIs and both are supported here.
|
| browser_tabsA | List, open, switch to, or close tabs. Tabs opened by the page show up in observations on their own. To act on one,
prefer
|
| browser_sessionsA | List open sessions (independent owned tabs). |
| browser_closeA | Close a session's tab. Set shutdown_browser=True to stop the browser too. Only a browser this server launched is stopped. In attach mode the browser is yours: shutdown detaches and leaves it, and every other window, running. |
| browser_doctorA | Report environment: browser binary, connection, keys, and policy envelope. Call this when anything behaves unexpectedly — it separates "no browser" from "blocked by policy" from "no key". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a clear primary purpose, but there is some overlap: browser_act includes tab operations that browser_tabs also handles, and browser_close overlaps with tab-closing in browser_tabs and browser_act. The descriptions mostly disambiguate these contexts well, though an agent might occasionally hesitate between them.
All tools share a consistent browser_ prefix in snake_case, which makes the family obvious and predictable. The second part mixes action verbs (open, observe, act, assert, close) with nouns (macro, tabs, sessions, doctor), so it is not a strict verb_noun pattern but remains readable and mostly consistent.
Ten tools is well-scoped for a browser automation server. Each tool occupies a meaningful role: navigation, observation, interaction, verification, tab/session management, recording, autonomous task handling, and diagnostics. None feel redundant or missing.
The tool surface covers the full browser workflow: open, observe, act, assert, manage tabs and sessions, close, record/replay macros, delegate to a decision model, and diagnose environment issues. There are no obvious dead ends or missing operations for the stated domain.