Engineering · · 4 min read

Give Your Coding Agent Your Local Models: TheYgent as an MCP Server

TheYgent 1.2 ships an MCP server: Claude Code, Codex, and OpenCode can hand files to your local models without reading them, run and build your agents, and search your docs and code.

By Arman Bahlakeh

A coding agent spends most of its effort reading. It reads logs to find the one failing line, docs to find the one setting, and source files to find the one function. All of that reading goes through the agent's own model and fills its context window, even when a much smaller model could have done the reading and reported back.

TheYgent 1.2 ships an MCP server. Add it to Claude Code, Codex, or OpenCode, and the coding agent gets the platform as tools: the models on your machine, the agents you built, and retrieval over your documents and code. This post covers what that gives a coding agent and how the pieces fit.

Four jobs a coding agent can hand off

Offload to a local model. ask_model sends a prompt to a model on your TheYgent inference plane and returns the answer. Use it for summaries, commit messages, release-note drafts, classification, extraction, and second opinions. The useful part is files. The coding agent names a log or a document, and the MCP server reads the file itself and sends it to the local model. Only the answer comes back. A build log the coding agent never reads never enters its context, and never reaches its provider.

Run the agents you built. Anything published on the canvas, such as a router, a PII firewall, or a review loop, is one run_agent call away. The run is an ordinary TheYgent run, on your own models and tools, with its full trace on the Runs page.

Build new agents. A coding agent is good at writing structured documents, and a TheYgent agent is one JSON document. The server hands it an authoring guide generated from the same node registry the runtime uses. It also gives it validate_agent, which applies the publishing rules locally, and run_graph, which test-runs a document without saving it. Ask for a commit-title agent and the coding agent writes it, tests it on two examples, and publishes it. The agent then opens in the visual editor like any other.

Search your docs and code. add_rag_files takes files, folders, or globs such as docs/**/*.md. It skips hidden, dependency, and build directories, and uploads everything else into a retrieval source embedded by your own model. Source code now indexes as plain text alongside PDFs and office documents. Each file is named by its path in the project, so two index.ts files stay two documents. search_rag then answers with the same hybrid semantic and keyword retrieval that agents use.

What it looks like

These came from end-to-end runs on a Mac. The test stack used a deliberately tiny chat model (Qwen3-0.6B on MLX) and nomic-embed-text on llama.cpp.

  • We indexed the MCP server's own source folder plus the developer docs, 21 files, with one add_rag_files call. They were embedded and searchable about nine seconds later. A question about how directories are walked came back with the right function as the top passage.
  • A commit-title agent was built, validated, test-run, and published entirely through tools. It then ran from Claude Code by name.
  • For a reasoning model, think: false turns thinking off per call. The same commit-title prompt took 16 generated tokens instead of 417.
  • Claude Code was asked to have the local model list the errors in an 800-line log. It passed the log as files, never read it, and got back both errors.

A model this small is right about what is in a file more often than about its details. Pick the model for the job. A 4B or larger local model is a better default for summaries you'll act on.

What goes where

The MCP server runs on your machine, launched by the coding tool over stdio, and holds no state. It is a client of TheYgent's two planes, just like the web interface. Model calls go straight to the inference plane and never touch the control plane. Agent runs, retrieval, and samples go to the control plane with a personal API key, which acts with your role. Nothing new is exposed. The server uses the same documented endpoints the interface does.

Your coding agent's own model still sees whatever the agent reads and whatever a tool returns. The MCP server changes what the agent has to read.

Connect it

With TheYgent running and a personal API key created (profile menu, API keys → Create), run make mcp-setup in your checkout. It prints the configuration for Claude Code, Codex, and OpenCode with your path filled in. For Claude Code:

claude mcp add theygent --scope user -e 'THEYGENT_API_KEY=tyk_…your key' \
  -- uv run --project /path/to/TheYgent --package theygent-mcp theygent-mcp

Then ask for outcomes in plain words: "have TheYgent's local model summarize the failures in build.log" or "index docs/ in TheYgent and tell me how auth is configured". A line in your CLAUDE.md or AGENTS.md saying when to prefer the local model turns that into a habit. The docs have a snippet.

Try it