Click on "Install 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., "@Yevgeny Catalogue every dependency in this monorepo and tell me which ones are unmaintained."
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.
An MCP server that lets a frontier coding agent hand work to a local LLM.
Claude Code (or any MCP client) calls Yevgeny to offload research, cataloguing, and long-running computation onto a model running on your own GPU — work that would otherwise burn context and tokens on grunt labour.
The interesting part is not the Ollama call. It is that the local model gets real tools — filesystem reads, web fetch, Python execution — on a host with no OS-level sandbox, and the boundaries that make that survivable are the bulk of the code.
Why it's built this way → docs/DESIGN.md
> Claude, have Yevgeny catalogue every dependency in this monorepo
and tell me which ones are unmaintained.
→ delegate_start({ task: "...", root: "D:/projects/app" })
← job_id: 20260901-49eb1c51, state: running
→ delegate_status({ job_id: "20260901-49eb1c51" })
← steps: 12/40
step 9: fetch_url {"url":"https://registry.npmjs.org/..."}
step 11: write_scratch {"name":"deps.json"}
→ delegate_result({ job_id: "20260901-49eb1c51" })
← [report + deps.json, 41 packages, 6 flagged]Claude stays in charge of judgement. Yevgeny does the legwork.
Related MCP server: Local Worker MCP
Tool | Blocking | Use for |
| yes, seconds | one-shot text work: summarise, extract, classify, reformat |
| no, returns a job id | multi-step research, cataloguing, simulations |
| no | progress, tool calls, background process liveness, log tail |
| no | final report plus a listing of everything written |
| no | abort a job; optionally kill its background processes |
| no | is Ollama up, which models are pulled, which Python was found |
ask is a single model turn with no tools. delegate_start runs a real agent
loop and returns immediately — poll it rather than waiting, because a job can
run for hours.
Why both shapes exist, rather than one: DESIGN.md → Two call shapes.
Yevgeny's own tools are glob, grep, read_file, write_scratch,
fetch_url, exec_python, exec_python_bg, exec_poll.
The boundaries, all enforced in src/tools.js:
Reads are confined to the root passed to delegate_start. Omit root
and the agent has no filesystem read access at all. Escapes via .. and
via symlinks are both rejected — a lexical check alone is not enough, so the
realpath of the nearest existing ancestor is checked too.
Writes only ever land in that job's own scratch directory,
jobs/<job-id>/. The agent cannot modify your files.
Execution is Python only, through an interpreter resolved and version-
checked at startup, with shell: false and cwd forced to the job scratch
dir. No shell, no cmd, no arbitrary binaries.
Network is HTTP/HTTPS only. Loopback and private ranges are refused, so the model cannot probe services on your machine or your LAN.
The threat model these come from is written up in DESIGN.md → What the boundaries are actually for.
exec_python is wall-clock capped and meant for quick computation and for
validating a script before committing to a real run. exec_python_bg spawns
detached and returns at once — that is the path for multi-hour jobs, and the
child survives the agent loop finishing.
So a job can complete while its simulation is still going. delegate_status
reports every background process the job launched and whether that pid is
still alive, because a finished job is not the same as finished work.
Scripts should write results to files and checkpoint as they go. Nothing retries them if the machine reboots.
Node 22+ (uses fs.promises.glob, native fetch)
Python 3.11+ — discovered automatically; YEVGENY_PYTHON pins one
Ollama with a tool-capable model pulled
Developed and tested on Windows 11. The code makes no Windows-specific
assumptions and should run on macOS and Linux, but that is untested — the
helper scripts status.ps1 and yevgeny.cmd are Windows-only, and neither is
needed to run the server.
git clone https://github.com/pSuarezFrancisco/yevgeny-mcp
cd yevgeny-mcp
npm install
ollama pull gemma4:12b # or any tool-capable model
node scripts/smoke.js # should print 27 passedRegister it with Claude Code:
claude mcp add yevgeny --scope user -- node /absolute/path/to/yevgeny-mcp/src/index.jsFull walkthrough, model choice, and troubleshooting: docs/SETUP.md. Calling it from another machine on your LAN: docs/REMOTE.md.
Everything has a working default. Override with environment variables:
Variable | Default | Notes |
|
| |
|
| must support tool calling |
| auto-discovered | pin if discovery picks the wrong one |
| unset |
|
| — | Windows only; for |
Limits — step budget, context window, byte caps, timeouts — live in
src/config.js under LIMITS.
node scripts/smoke.js # 27 assertions: path scoping, exec, fetch guards
node scripts/mcp-smoke.js # 8 assertions: MCP protocol over real stdio
node scripts/e2e.js # a real job against the real model (minutes)smoke.js attacks the security boundaries directly without involving the
model, because those are the parts a confused agent leans on hardest.
mcp-smoke.js speaks real newline-delimited JSON-RPC to a spawned server.
Neither needs a model pulled.
e2e.js is the only one that exercises Yevgeny's own judgement: a real job
fetches two pages, structures them to JSON, verifies that with Python, and
reports a cited table. Passing it means the plumbing works — it does not mean
the research is right. Spot-check output against a source you trust.
powershell -File status.ps1Prints Ollama's state, which model is resident and what fraction is on GPU,
recent jobs colour-coded by state, live background pids, and a GPU line from
nvidia-smi. Written so you can answer "is it running, and is it melting
anything" without asking the agent.
MIT — see LICENSE.
Ask Yevgeny (the local model) a single self-contained question and get the answer back immediately. No tools, no web access, one turn. Use for summarising, extracting or reformatting text you already have, classifying items, or drafting. For anything needing research, files or computation use delegate_start instead.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Absolute paths to read and prepend as context | |
| model | No | Ollama model, default gemma4:12b | |
| prompt | Yes | The full question or instruction, including any text to work on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It is transparent about being one-turn and offline, but it tells agents to use delegate_start for anything needing files, while the input schema offers a files parameter for reading absolute paths as context. This internally contradicts the tool's actual capabilities.
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 tight sentences: the first defines the core behavior, the second scopes use cases and exclusions. Key constraints are front-loaded with no 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?
The description covers the main use cases, exclusions, and the one-tun nature, and schema descriptions cover all parameters. However, the conflict around file handling prevents an agent from confidently deciding whether the files parameter should be used or avoided.
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 100%, so prompt, model and files are already documented. The description adds only that the prompt should be a single self-contained question, but it muddies the files parameter by delegating file-related requests elsewhere.
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?
Description names a specific verb and resource: asking Yevgeny a single self-contained question and getting an immediate one-turn answer. It also distinguishes itself from the delegate_* siblings by stating 'No tools, no web access, one turn.'
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?
Gives explicit usage context: summarising, extracting, reformatting, classifying, drafting. It also states when not to use it — for research, files or computation use delegate_start — so an agent has clear routing criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running delegated job. Aborts the agent loop. Background processes it launched keep running unless kill_children is set.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| kill_children | No | Also kill background processes the job launched |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does real work: it discloses the agent-loop abort and the critical side-effect that background processes survive unless kill_children is set. It stops short of stating reversibility, post-cancel state, or behavior on already-finished jobs, but the essential behavioral surface is exposed.
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?
Three terse sentences, main action front-loaded, with every sentence earning its place: purpose, abort scope, and the kill_children caveat. No filler or redundant schema restatement.
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 low-complexity 2-parameter tool with no output schema, the description covers purpose, the cancellation mechanism, and the conditional side effect. Minor gaps remain – error cases (job not found/already finished), idempotency, and return value – but nothing an agent needs to invoke correctly is missing.
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 covers kill_children at 50%; the description reinforces that same parameter by tying it to the default background-process behavior, adding mild value. job_id is left to the schema and is self-evident as the job identifier, so no meaningful semantics are added beyond the schema.
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?
'Stop a running delegated job' provides a specific verb and resource, and 'Aborts the agent loop' clarifies the mechanism. The action is clearly distinct from sibling tools (delegate_start, delegate_status, delegate_result, ask), though it doesn't explicitly name an alternative as a top-rating definition might.
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?
Usage is implied: call this when a delegated job is running and should be stopped. There is no explicit when-to-use, prerequisites, or exclusions, and it doesn't route the agent toward a sibling for related needs (e.g., checking state first via deelegate_status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect the final report from a delegated job, plus a listing of every file it wrote to its scratch directory. Note that a finished job may still have background processes running - check delegate_status for those.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| include_files | No | Scratch filenames to inline in full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds the non-obvious caveat that a finished job may still have background processes running and directs the agent to delegate_status for those, while the 'collect' wording implies a read-only retrieval. It does not explicitly state that no files are deleted or that the call is non-mutating, but it is considerably transparent.
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 sentences, front-loaded with the core result and file-listing behavior, then a short caveat and sibling pointer. Every sentence earns its place with no redundant wording.
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?
Despite no output schema, it tells the agent what will be returned: a final report plus a listing of scratch files. It also covers the key ambiguity about background processes. It does not describe error behavior for unknown job_ids or output formatting, but for a focused result-collection tool the essentials are present.
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 covers include_files but not job_id. The description's mention of 'delegated job' indirectly clarifies job_id as the identifier of a previously delegated job, but it does not explain include_files beyond the schema's own text. At 50% coverage, it partially compensates but relies on the schema for half the parameter meaning.
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?
Clearly states a specific, non-trivial action: 'Collect the final report from a delegated job' plus a second concrete deliverable, 'a listing of every file it wrote to its scratch directory.' This distinguishes it from siblings like delegate_start, delegate_status, and delegate_cancel, which handle creation, status, and cancelling.
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?
Explicitly routes the agent to delegate_status when it needs background-process info, giving an alternative for a specific situation. It implies the main use case is after a delegated job has finished, though it does not explicitly say 'call only when delegate_status reports done.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hand a multi-step task to Yevgeny and get a job id back immediately. Yevgeny can search and read files, fetch web pages, write structured output, and run Python (including multi-hour background simulations). Returns at once - poll with delegate_status and collect with delegate_result. Give a thorough brief: state the goal, the sources or directories to use, and the exact output format you want.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Absolute path the agent may read from via glob/grep/read_file. Omit for web-only work. The agent can never write here. | |
| task | Yes | Full task brief, including desired output format | |
| model | No | Ollama model, default gemma4:12b |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses asynchronous behavior (returns at once, poll later), support for multi-hour background simulations, and the read-only restriction on root. It stops short of failure modes or concurrency details, but core behavioral traits are well covered.
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 efficient sentences. The primary behavior is front-loaded, then capabilities, then invocation protocol, then brief guidance. Every sentence contributes without waste.
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 no output schema, the description explaines the return value (job id) and the rest of the workflow (poll/collect). It covers capabilities, the required brief format, and the root condition. It omits error/health edge cases, but those are plausibly covered by sibling tools lik e yevgeny_health.
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 coverage is 100%, so the baseline is 3. The description adds meaningful usage meaning beyond the schema: it instructs the caller to provide a thorough brief with goal, sources/directories, and output format, and tells when to omit root. These enrich the task and root parameters beyond their raw 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 uses a specific verb ('Hand a multi-step task') and a resource (Yevgeny), and clearly states the immediate outcome (job id back). It distinguishes itself from siblings by explicitly pointing to delegate_status and delegate_result as follow-up tools.
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?
It explains when to use the tool (multi-step tasks) and gives clear post-invocation guidance (poll with delegate_status, collect with delegate_result). It also provides a conditional usage detail (omit root for web-only work), though it does not explicitly contrast with delegate_cancel or ask.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check how a delegated job is going without blocking: its state, how many steps it has taken, which tools it has called, any background processes it launched and whether they are still alive, and the tail of its log.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| log_lines | No | Lines of log tail, default 25 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states the operation is non-blocking and enumerates the behavioral scope: state, steps taken, tool calls, background process liveness, and log tail. It does not cover edge cases like invalid job_id or whether the call is read-only, but the wording strongly implies a safe inspection operation.
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 front-loaded sentence with a colon that cleanly introduces a specific list of what the status check returns. Every clause adds useful information, and there is no redundant or filler wording.
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 simple 2-param status tool with no output schema, the description covers the key invocation context and return content well: state, steps, tool calls, background processes, and log tail. It lacks formal response structure and error behavior, but those are minor for an agent deciding whether and how to call this tool.
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 coverage is 50%: only log_lines has a description, while job_id is bare. The description gives contextual meaning to job_id via 'a delegated job' and matches log_lines through 'tail of its log', but it does not add detailed parameter semantics beyond what the schema already provides. This is adequate but not compensative for the undocumented job_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 uses the specific verb 'Check' and names the resource ('a delegated job') while enumerating exactly what the status check covers: state, step count, tool calls, background process liveness, and log tail. This clearly separates it from sibling tools like delegate_start, delegate_cancel, or delegate_result.
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 phrase 'without blocking' implies it is meant for non-blocking async status monitoring, which is useful context. However, it does not explicitly mention when to prefer delegate_status over delegate_result or when to consider delegate_cancel, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that Yevgeny is usable: Ollama reachable, which models are pulled, the Python interpreter it resolved, and recent jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. The word 'Check' strongly implies a read-only diagnostic with no destructive side effects, and the list of checks tells the agent what state is inspected. It does not describe the return format or failure behavior, but for a health check this is a reasonable level of 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 a single, well-structured sentence that front-loads the core purpose ('Check that Yevgeny is usable') and then uses a colon-separated list to enumerate specific checks. Every word earns its place, with no repetition or 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 parameterless health-check tool with no output schema and no annotations, the description provides sufficient context for an agent to select it and invoke it correctly. It specifies the subject of the check and the concrete dimensions of usability, covering the essential decision-making needs.
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 tool has zero parameters, so the baseline is 4. The description adds meaningful context by defining what 'usable' means (Ollama reachable, models pulled, Python interpreter, recent jobs), which helps the agent interpret the tool's purpose even though there is nothing to configure.
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 the specific verb 'Check' and names the target resource 'Yevgeny', then enumerates exactly what is verified: Ollama reachability, pulled models, the resolved Python interpreter, and recent jobs. This clearly distinguishes it from the sibling delegation tools, which perform actions rather than diagnostics.
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 a health-check/diagnostic tool to confirm Yevgeny is usable, but it does not explicitly state when to use it versus alternatives or when not to use it. With siblings like delegate_start and delegate_status, an agent can infer it is a preflight check, but the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: direct one-turn ask, async delegated job lifecycle (start, status, result, cancel), and health check. delegate_status and delegate_result are separated by live progress versus final output, so there is no real ambiguity.
The delegate_* tools follow a consistent and predictable prefix pattern. ask and yevgeny_health deviate slightly from that convention, but they are readable and clearly labeled, so the overall naming remains coherent.
Six tools is a well-scoped set for a local-agent delegation server. Each tool maps to a necessary operation: direct ask, job start, status polling, result collection, cancellation, and health checking, with no redundant entries.
The tool set covers the full delegated-job lifecycle: start, monitor, collect, and cancel, plus a direct quick-ask path and a health check. Background process handling is also addressed through cancel and status. There are no obvious dead ends for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Central async research commons for persistent AI agents
Shared control plane for AI coding agents — tasks, memory, decisions, file locks. 12 tools.
Project memory, semantic code search, and grounded agent context.
Read a project's prompts, logs and agents, and send new work to the agent on your own machines.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pSuarezFrancisco/yevgeny-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
