jev-browser-sidekick-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TYPESAFE_API_KEY | No | Your official TypeSafe API key. Required if using the TypeSafe provider. | |
| OPENROUTER_API_KEY | No | Your OpenRouter API key. Required if using the OpenRouter provider. |
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": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_actionA | Drive a browser through steps you write, with Jev choosing on each page. Covers several independent errands in one call through groups, one tab each, so two sites never need two calls. Returns a status per step, a handoff when one stops, and the tokens the API reported. Read this server's instructions for the step shapes. |
| use_jev_rawA | Ask Jev one typed question, or several, with no browser involved. Use it whenever a decision has more than one defensible answer and you are about to pick on instinct. Jev gives a probability for every option and a confidence, so a close call reads as close, and a clear one reads as clear. Anything you would otherwise settle by coin flip and call judgment belongs here. Decisions worth handing over: which of these fixes to do first, which name or design to ship when each has a real trade-off, whether this text meets a bar you can write down, which of two error messages a stranger understands faster, whether a step is risky enough to stop and ask the user, how to rank a list of candidates, which of two readings of an ambiguous request the user meant. Ask every question you have in one call. They share the state, they answer in parallel, and each extra question costs its own tokens and almost no extra time. Three questions over a page of state run about a tenth of a cent, so the cost is rarely the reason to skip it. The answer gives the chosen option, the probability of every option, a confidence, and the tokens the API counted. Read the jev://raw-decisions resource before the first call for the question shapes and the criteria rules. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| jev-raw-decisions | How to write state, choice, score, and noul questions for use_jev_raw: criteria rules, confidence, size limits, and worked examples. Read before the first use_jev_raw call. |
| jev-reading-a-result | Every status and reason a step can carry, the handoff shape and how to resume from it, and what each usage field counts. Read when a run comes back rejected, blocked, unverified, or max_steps. |
TDQS
Scored across 2 tools
run_action is entirely about browser automation while use_jev_raw is explicitly a non-browser decision tool. Their purposes and outputs do not overlap, so there is no risk of an agent selecting the wrong tool.
Both names are snake_case and verb-first, which is mostly consistent. However, run_action follows a clean verb_noun pattern while use_jev_raw mixes a product name and an adjective, making it slightly less predictable.
Two tools is minimal and sits at the thin end of acceptable. Each tool covers a broad area, but the server still feels sparse for something positioned as a browser sidekick.
run_action appears to consolidate multi-step browser workflows and returns statuses and handoffs, while use_jev_raw covers decision support. The main gap is a lack of separate low-level browser inspection or control tools, but the step-based design likely lets agents work around it.