jev-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TEXT_MODEL | No | The name of the text model to use. | kimi-k3 |
| KIMI_API_KEY | No | Alternative API key for Moonshot Kimi text model. Used if TEXT_MODEL_API_KEY is not set. | |
| DEEPSEEK_API_KEY | No | API key for DeepSeek text model. Used if TEXT_MODEL_API_KEY is not set. | |
| MOONSHOT_API_KEY | No | API key for Moonshot Kimi text model. Used if TEXT_MODEL_API_KEY is not set. | |
| TYPESAFE_API_KEY | Yes | The TypeSafe API key. Required; without it no run can start. | |
| OPENROUTER_API_KEY | No | API key for OpenRouter text model. Used as a fallback. | |
| TEXT_MODEL_API_KEY | No | API key for the text model. Takes precedence over provider-specific keys. Used for typing values into fields. | |
| TEXT_MODEL_BASE_URL | No | Base URL for a custom OpenAI-compatible endpoint. Used with TEXT_MODEL_API_KEY. |
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_taskA | Operate a website autonomously in the user's real, logged-in Chrome: open |
| browser_statusA | Report whether a browser run can work at all, before spending time on one. Says which API keys are present and where they came from, which text model would type into fields, whether the browser-harness daemon is running and whether a Chrome is connected to it, and which operations are therefore blocked. Read-only and free: it opens no browser, loads no page, calls no model and costs nothing. Call it when browser_task or browser_read fails, before the first run of a session, or when the user asks whether the browser agent is ready. It says nothing about any particular website. |
| browser_readA | Open one page in the user's real, logged-in Chrome and return its visible text plus the table of elements that can be operated. This tool clicks nothing, types nothing and selects nothing. Opening the page is itself a request, though: it opens a background tab and navigates to |
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 3 tools
The three tools are sharply delineated: browser_task performs autonomous multi-step interaction, browser_read is a read-only page fetch, and browser_status is a diagnostic readiness check. Both browser tools explicitly cross-reference when the other should be used, removing any ambiguity.
All tools share the browser_ prefix, making the family instantly recognizable. However, browser_read uses a verb while browser_task and browser_status use nouns, so the pattern is not perfectly uniform.
Three tools is a well-scoped set for the server's purpose: one for autonomous interaction, one for passive reading, and one for environment status. No tool feels redundant or extraneous.
The tool surface covers the full lifecycle of a browser automation session: verify readiness, read a single page, and execute multi-step tasks. Limitations are documented rather than missing functionality, and no obvious dead ends remain for the stated domain.