把 Claude Code 的杂活交给运行在你自有硬件上的模型。
localagents 是一个 MCP 服务器，为 Claude Code 提供 run_agent 工具。每次调用都会启动一个完整的无头 Claude Code 会话——相同的工具、相同的 CLAUDE.md、相同的工作树——只不过它的 API 流量不是发往 Anthropic，而是发往你自行运行的 llama.cpp 或 vLLM 服务器。Claude 编写任务简报，本地模型执行工作，Claude 审查结果。你的 Anthropic token 预算只花在需要它的地方。
单块 GPU 上的 27B Qwen 完全能胜任“为这个模块添加 CLI 并配上相应测试”；Opus 更适合花在设计对话上，而不是盯着 pytest 运行。两个本地代理可以并行地针对一个固定的接口分别构建一个包的两半。
状态：早期。 它能用，我每天都在用，但接口会变动。它专门针对 llama.cpp 和 vLLM；Ollama 不是目标。
Claude Code (your session)
│ MCP: run_agent(task, model=...)
▼
localagents ── spawns ──▶ headless `claude` (Agent SDK)
│ │ ANTHROPIC_BASE_URL
│ ▼
└──── in-process shim ◀────┘ normalises requests, logs them,
│ translates backend errors
▼
llama-server / vllm (/v1/messages, on your machine or your LAN)有三件事让它不仅仅是一个环境变量：
实时探测的注册表。 models.yaml 列出服务器所在位置和模型名称菜单。每次调用都会发现每台服务器当前实际提供什么、真实上下文窗口大小以及有多少个槽位被占用。你手动启动和停止模型——服务器从不启动任何东西——当 Claude 需要一个未运行的模型时，它会按名称向你请求。
Claude Code 与后端之间的垫片（shim）。 Claude Code 会发送本地聊天模板拒绝的内容，而本地服务器也会以 Claude Code 无法识别的方式失败。垫片对两个方向都做了修复（详见下文），并为每个任务写入一个 requests.jsonl，这样你就能确切看到线上传输了什么。
与 Claude 自己的子代理相同的隔离模型。 默认情况下，任务在你的工作树中运行，就像 Agent 工具那样。isolation: worktree 会在 local-agent/<job> 分支上为它创建一个全新的 git worktree，并且仅当它修改了内容时才保留，同时在任务记录中附带 diffstat，以便 Claude 以 diff 形式审查。
Related MCP server: lmstudio-mcp
Python 3.12+ 和 uv
Claude Code。Agent SDK 自带 claude 二进制文件，因此无需安装其他任何东西。
一个支持 Anthropic /v1/messages 接口的服务器：
llama.cpp llama-server — 用 --jinja 启动；加上 --slots --metrics 可在工具输出中获取占用率和缓存统计。
vLLM，带 --enable-auto-tool-choice --tool-call-parser <parser>。
一个能真正驱动 Claude Code 的模型：扎实的原生工具调用能力，以及每次请求 128k 或更大的上下文窗口。Qwen3.8-27B 表现良好。更小的窗口也能用，但会频繁压缩；参见上下文窗口。
git clone https://github.com/ccebelenski/localagents.git && cd localagents
uv tool install -e . # `localagents` on PATH; editable, so repo edits apply
cp models.example.yaml models.yaml # edit for your servers (gitignored)
claude mcp add --scope user local -- localagents --config "$PWD/models.yaml"用户级作用域意味着每个项目都能获得 local 服务器。它会继承启动它的 Claude Code 会话的 cwd，因此 run_agent 默认使用该项目的目录树。项目可以自带 ./models.yaml 来覆盖注册表。
如果你希望只保留在一个项目中，请将其放入该项目的 .mcp.json：
{"mcpServers": {"local": {"command": "localagents", "args": ["--config", "/path/to/models.yaml"]}}}添加后重启 Claude Code（或 /mcp → 重新连接）；MCP 服务器在启动时加载。
Claude 会像使用任何工具一样使用它。按名称请求它，它就会做正确的事：
使用本地代理为 CLI 添加
--json标志，并在测试中覆盖它。
Claude 在背后做的是：调用 list_models 查看当前状态，调用 run_agent(task=…) 获取任务 id，然后使用 wait_job / job_status / job_log 直到完成，接着读取 files_touched（或 worktree diff）并检查工作。超过 Claude Code 2 分钟工具超时时间的任务会被放到后台，稍后再拾取；你无需做任何事。
如果没有合适的模型在运行，你会被要求启动一个：
qwen3.8-27b没有在任何地方运行。请让用户把它启动起来。 备注：llama.cpp 上的默认中型编码模型；使用 --reasoning on 运行
按你通常的方式启动它，说“已经启动了”，Claude 就会重试。
工具 | 作用 |
| 带实时健康状态、服务 id、上下文窗口、槽位占用率的端点；以及带 |
| 启动任务： |
| 跟踪和控制任务 |
| 告诉用户如何启动池中模型 |
| 在会话内添加到模型池（写入 |
| 无工具的一次性生成——摘要、草稿、分类 |
任务记录存放在 ~/.local/state/localagents/jobs/<job>/：transcript.txt（代理说了什么、做了什么）、events.jsonl（每条 SDK 消息）、requests.jsonl（每个后端请求及其时序、大小和用量），如果你开启请求转储，还会有 requests_full.jsonl。
models.yaml从 models.example.yaml 开始。它会在每次调用时重新读取，因此编辑会立即生效，而且服务器从不重写它——register_* 写入一个边车文件 models.local.yaml，该文件会被合并覆盖在其上。
endpoints:
llamacpp:
base_url: http://127.0.0.1:8080
backend: llama.cpp
gpu-server:
base_url: http://gpu-server.lan:8000
backend: vllm
host: gpu-server
models:
qwen3.8-27b:
notes: default mid-size coder on llama.cpp; run with --reasoning on
deepseek-v4-flash:
host: gpu-server
notes: vllm needs --enable-auto-tool-choice --tool-call-parser deepseek_v3endpoints 是提供 /v1/messages 服务的位置。它们提供什么会被探测。
models 只是名称。名称会与服务的 id 进行模糊匹配（qwen3.8-27b 能找到 unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL），因此一个条目只需要 notes，也许还需要一个 host 用于在请求启动时转达。served_name（精确 id 或 glob）、endpoint、context（回退窗口）和 bring_up（启动命令）都可以作为覆盖项，如果你需要的话。启动命令很快就会过时；名称加备注通常更耐久。
defaults 涵盖默认模型、permission_mode（acceptEdits）、允许和禁止的工具（子代理不能生成子代理）、要加载哪些 Claude 设置、max_turns、timeout_s，以及一个系统提示后缀，告诉代理它是被委派者以及如何汇报。
llama.cpp 和 vLLM 都原生支持 /v1/messages，所以把 ANTHROPIC_BASE_URL 指向它们几乎就能工作。垫片弥补了这些差距：
对话中途的系统消息。 Claude Code 会在 messages 中放入 role: system 条目——技能列表、一个 token 预算标记，以及每轮一个。Qwen 的聊天模板会拒绝：“System message must be at the beginning”。垫片会将每一条就地折叠进相邻的用户消息，作为一个 <system>…</system> 文本块。如果改为把它们提升到顶层的 system 字段，每一轮都会改变提示词的开头，这会使服务器的 KV-cache 前缀失效，并每次重新评估整个约 35k token 的提示词（在 27B 上每轮 21–47 秒）。就地折叠则保持提示词只追加：llama-server 日志中 f_sim_best 为 0.88–0.99，每轮 2.5–14 秒。
上下文溢出。 Claude Code 对任何它不认识的模型都假定 200k 窗口；当槽位较小时，它会撞上 llama.cpp 的 exceed_context_size_error，而 Claude Code 无法理解这个错误，任务就会失败。参见下一节。
垫片所做的一切在不需要时都是空操作，而且每个请求都会被记录其时序、消息数量、字节大小和报告的用量。
两层机制让会话保持在真实窗口之内：
探测会读取它——llama.cpp 的 /props n_ctx（每个槽位：当统一 KV 关闭时，-c 除以 --parallel）、vLLM 的 max_model_len——然后会话会获得 CLAUDE_CODE_MAX_CONTEXT_TOKENS。Claude Code 自己的自动压缩随后会在正确的时机触发。低于 128k 时，输出预算也会缩小到 n_ctx/8，因为压缩阈值是 window − max_output，否则它会停留在零。
如果请求仍然溢出，垫片会将后端的错误改写为 Anthropic 的 prompt is too long: N tokens > M maximum，Claude Code 会通过压缩并重试来应对。
在 64k 下这能用，但会剧烈抖动：Claude Code 约 20k 的固定提示词和工具模式，加上约 7k token 的压缩摘要（在 27B 上约 55 秒）以及它重新附加的文件，会在几轮内重新填满窗口，然后它的抖动保护会结束任务。给每个槽位 128k 或更多。
llama.cpp：llama-server -hf <gguf> --jinja -fa on --slots --metrics，再加上 --reasoning on 用于思考模型，--parallel N 用于并发任务。开启 /slots 后，list_models 会显示 {total, busy, free}，这样 Claude 就能知道第二个代理是会立即运行还是排队。开启 /metrics 后，每个任务都会记录已处理与已缓存的提示词 token、缓存命中率、提示词和生成的 tok/s，以及投机解码接受率——这些计数器是服务器级的，因此重叠的任务会共享增量。
vLLM：vllm serve <model> --served-model-name <alias> --enable-auto-tool-choice --tool-call-parser <parser>。上下文窗口来自 /v1/models 中的 max_model_len；占用率（requests_running/waiting、kv_cache_usage）和每个任务的缓存统计来自其始终开启的 /metrics。vLLM 在 Anthropic 端点上将上下文溢出报告为 HTTP 500 internal_error；垫片也会转换这个错误。会话以 CLAUDE_CODE_ATTRIBUTION_HEADER=0 启动，因为每个请求的归因哈希会破坏前缀缓存。已用 DeepSeek-V4-Flash 验证：思考块会连同其签名一起重放，从第二轮开始每一轮都命中前缀缓存。
任务的第一个回合在冷槽位上大约消耗 20k token 的提示词（系统提示词加工具模式），在 27B 上约 10 秒。之后的一切都是缓存命中加上增量。
uv sync --dev
uv run pytest -q参见 CONTRIBUTING.md 了解项目结构以及如何针对真实服务器测试改动。
MIT。参见 LICENSE。
Copyright © 2026 Chris Cebelenski
Cancel a running job (kills the headless Claude session).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait—that cancellation kills the headless session—but does not elaborate on reversibility, side effects on job output, or whether the cancellation is asynchronous. This is partial disclosure but not comprehensive.
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 sentence with no unnecessary words. The core action ('Cancel a running job') is front-loaded, and the parenthetical adds essential behavioral detail. It is highly concise and well-structured.
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 one-parameter cancellation tool, the description covers the essential action and primary side effect. However, it lacks details about error handling (e.g., what happens if the job is already finished), whether cancellation is synchronous, or any prerequisites. The presence of an output schema reduces the need to describe return values, but overall the description is adequate yet not rich.
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 0%, so the description must compensate. The only parameter, job_id, is never explained; its meaning is only implied by the tool's purpose. The description does not clarify how to obtain a valid job_id or that it must reference a running job.
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 ('Cancel') and a clear resource ('a running job'), and adds the clarifying detail that it 'kills the headless Claude session.' This clearly distinguishes it from related tools like job_status, wait_job, and list_jobs without needing to inspect their schemas.
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 states only what the tool does, not when to use it relative to alternatives. It does not mention conditions for use (e.g., only when a job is running) or contrast with siblings like job_status or wait_job. No guidance on when to avoid this tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail of a job's human-readable transcript (assistant text, tool calls, results).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| tail_lines | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that the tool returns the tail of a transcript and what content categories are included, but it does not describe behavior for missing jobs, incomplete jobs, or error conditions. This is adequate but not rich.
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?
One concise sentence with no filler. 'Tail of a job's human-readable transcript' is front-loaded and the parenthetical content list adds useful scope without bloating the text.
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 tool is simple and has an output schema, so return values need not be re-described. However, with no annotations and no parameter-level details, the description leaves some context implicit, such as the unit for tail_lines and whether the tool is safe for active jobs. An agent can still call it, but the context is minimally sufficient.
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 0%, so the description must compensate, but it does not explicitly explain job_id or tail_lines. The word 'Tail' loosely implies tail_lines controls how much is returned, and job_id is inferable from 'a job's transcript', but the meaning of the default and the line-count semantics are left to the schema titles only.
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 states a specific resource and action: retrieving the tail of a job's human-readable transcript. It also clarifies content type (assistant text, tool calls, results), which distinguishes it from status-oriented siblings like job_status or list_jobs, though it does not name them.
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?
There is no explicit guidance about when to use this tool versus alternatives such as job_status, wait_job, or list_jobs. The phrase 'tail of a job's transcript' weakly implies a read-after-run scenario, but no exclusions or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current status, last activity, files touched, and result (if finished) of a job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the transparency burden. It does disclose what the tool reports and notes the conditional result field for finished jobs, but it does not explicitly state that the call is non-mutating, non-blocking, or what happens for unknown jobs.
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 compact and efficiently lists the key return categories without filler. Minor structural issue: it is a noun phrase rather than a complete verb-led sentence.
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?
Because an output schema exists, the lack of return-value detail is acceptable, and the essentials for invoking with job_id are present. However, the tool lacks usage context and behavioral caveats, leaving an agent to infer how this relates to wait_job and job_log.
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 0%, so the description needs to compensate, but it only implies job_id through 'of a job'. It does not explain the expected format, where to find the ID, or any constraints beyond the schema's generic string type.
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 identifies a specific resource (a job) and lists the exact information returned: current status, last activity, files touched, and result when finished. It is clear enough to separate from list_jobs or wait_job, though it lacks an explicit verb like 'Gets' or 'Returns'.
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?
No guidance is given about when to call this instead of siblings such as wait_job or job_log. The 'if finished' caveat is the only hint about polling behavior; there is no explicit context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List jobs from this server session (newest last).
| Name | Required | Description | Default |
|---|---|---|---|
| include_finished | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses ordering and session scoping, but it does not mention side-effect guarantees, pagination, or how include_finished affects results.
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?
A single concise sentence with no filler. The action is front-loaded, and the scope and ordering details are included efficiently.
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 list operation with one self-explanatory optional boolean and an output schema, the description is mostly sufficient. The main gap is the lack of connection to sibling tools and explicit include_finished behavior.
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 0%, and the description never mentions the include_finished parameter. The parameter name and default value imply its meaning, but the description adds no semantic value for it.
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 states a concrete action and object ('List jobs'), scopes them to 'this server session', and adds ordering ('newest last'). This clearly distinguishes it from siblings like job_status, job_log, and cancel_job.
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 gives no guidance on when to use list_jobs versus job_status, job_log, or wait_job. It implies a session scope but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured endpoints (with live health + what they're serving now) and the model pool.
Pool entries that are currently reachable are marked `available: true` with the endpoint name
and the served id. Unavailable ones are the menu to ask the user for (by name, on `host`).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses live health semantics, the meaning of 'available: true', and how unavailable entries should be treated. Read-only behavior is only implicit via the verb 'List', but that is reasonable for this tool.
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 front-load the primary purpose and each subsequent sentence adds useful semantic or behavioral detail. No filler or redundancy.
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 zero-parameter listing tool with an output schema, the description is complete: it explains what is listed, what availability means, and how to interpret unavailable entries. Nothing needed for correct invocation 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?
The tool has zero parameters, so there is no parameter documentation burden. The description appropriately focuses on behavior and output meaning instead.
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?
States a specific verb ('List') and distinct resources: configured endpoints with live health and the model pool. It also clarifies what availability means, differentiating this from list-style siblings like list_jobs.
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 when to use it: to inspect live endpoint availability and decide which unavailable models to ask the user about. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot completion on a local model, no tools, no agent loop. Cheap offload for summaries, drafts, classification, translation, boilerplate. Returns the text.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | Yes | ||
| system | No | ||
| endpoint | No | ||
| max_tokens | No | ||
| temperature | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the core behavior (one-shot, no tools, returns text) and notes it's 'cheap' (low cost), but omits potential failure modes, authorization requirements, or network behavior (despite an endpoint parameter). It adds some value but not full 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 3 succinct sentences, front-loading the primary action and immediately differentiating from siblings. Every sentence contributes: purpose, use cases, and return value. No filler or redundancy.
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 tool with 6 parameters and sibling tools for registering models/endpoints, the description doesn't mention prerequisites or how to choose a model. It assumes the agent knows it can just pass prompt and rely on defaults, but lacks guidance on when to specify model/endpoint. Given the output schema exists, return format is covered, but operational context is incomplete.
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 parameter description coverage is 0%, and the tool description offers no parameter-specific explanation. It doesn't clarify how 'model', 'endpoint', or 'system' interact, nor does it mention defaults or dependencies. The parameter names are self-explanatory, but the description adds no semantic value 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?
The description clearly states the tool performs one-shot completion on a local model, explicitly contrasting with agent loops and tools. It lists concrete use cases (summaries, drafts, classification, translation) and specifies the output, leaving no ambiguity about what the tool does.
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 explicitly identifies when to use it ('cheap offload' for simple tasks) and when not to ('no tools, no agent loop'), implicitly routing to sibling tools like run_agent for agentic needs. While it doesn't name the alternative directly, the exclusion is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update an inference endpoint (persisted to models.yaml) and probe it.
`base_url` is the server root that exposes `/v1/messages`, e.g. `http://127.0.0.1:8080`.
`backend` is one of llama.cpp | vllm | ollama | other (informational).
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | local | |
| name | Yes | ||
| notes | No | ||
| backend | No | other | |
| base_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool persists to models.yaml and probes the endpoint, which is useful, but it omits critical behavioral details such as whether the operation is idempotent, what happens on probe failure, error handling, or potential side effects like network timeouts. For a tool that mutates state and performs network calls, this is insufficient.
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 brief at two sentences plus a code block, which is concise. However, it lacks a clear structure: the parameter explanations are dropped inline rather than presented as a list, and key scoping info is not front-loaded. It's not bloated, but it could be more organized.
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 the tool has five parameters, no annotations, no output schema (schema is present but no output schema referenced), and 0% schema description coverage, the description is incomplete. It does not explain the return value of probing, error conditions, or how the endpoint is validated. An agent cannot fully predict the tool's behavior from the description alone.
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 0%, so the description must explain parameters. It explicitly covers base_url (server root exposing /v1/messages) and backend (enum of llama.cpp, vllm, ollama, other), but fails to describe the other three parameters: name, host, and notes. Two of five parameters are explained, leaving the rest undocumented.
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 clearly states the tool's purpose: 'Add or update an inference endpoint (persisted to models.yaml) and probe it.' The verb 'add or update' combined with the resource 'inference endpoint' is specific, and the persistence detail distinguishes it from related tools like register_model or list_models.
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 provides no explicit guidance on when to use this tool versus alternatives. It mentions the tool registers endpoints but doesn't indicate when to prefer it over other registry-related tools, nor does it list any prerequisites or exclusions. The context about base_url and backend is informative but not usage-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a model in the pool (persisted to models.yaml).
Only `name` is required: it is fuzzy-matched against served ids (alphanumerics, case-folded,
substring), so `qwen3.8-27b` finds `unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL`. `host` and `notes`
are what gets relayed when asking the user to bring it up. The rest are overrides:
`served_name` (exact id or glob) when fuzzy matching is ambiguous, `endpoint` to prefer one,
`context` as a fallback window when the backend doesn't report one, `bring_up` a start command
(goes stale quickly; usually leave empty).
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| name | Yes | ||
| tags | No | ||
| notes | No | ||
| context | No | ||
| bring_up | No | ||
| endpoint | No | ||
| served_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses key behaviors: upsert semantics, persistence to a YAML file, the fuzzy-matching algorithm, and the caveat that bring_up goes stale. It clearly indicates mutation and side effects. It omits auth/permission requirements and error scenarios, but the disclosed details are substantial.
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 front-loaded with the core purpose, then breaks down parameters with clear rationale. Each sentence adds value, though it is somewhat long. The structure is logical and efficient, with no wasted words.
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 the tool's complexity (8 params, matching algorithm, overrides) and lack of annotations, the description covers most operational aspects: required field, matching behavior, param purposes, and a caveat. The omission of tags and lack of error/edge-case discussion are gaps, but the output schema presumably covers return values. Overall, it is largely complete for an agent to invoke correctly.
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?
With 0% schema description coverage, the description explains most parameters (name matching, host/notes relay, served_name, endpoint, context, bring_up) with usage context. However, the 'tags' parameter is completely ignored, leaving one of eight parameters undocumented. The detail given for the others is strong and compensates for the schema gap.
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 action ('Add or update a model in the pool') with a concrete resource and persistence detail ('persisted to models.yaml'). The verb+object is unambiguous and distinct from sibling tools like register_endpoint.
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 when to use the tool (to add or update a model) but does not explicitly contrast it with alternatives such as register_endpoint or request_model. No when-not-to-use guidance, prerequisites, or conditions that select this tool over siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What to relay to the user to bring up a model that is not currently running.
Returns the pool entry's `host`/`notes` (and a start command only if one is on file). If the
model is already up, says so instead.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior, and it does so well. It discloses the return payload (host/notes, plus a start command only if one is on file) and the conditional behavior when the model is already up. It implies a read-only, informational operation by saying it relays content to the user, though it does not explicitly state that no start action is triggered.
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 compact: a one-sentence purpose, a one-sentence return summary, and a one-sentence conditional behavior note. Every sentence adds distinct information, and the key purpose is front-loaded. No redundant phrasing or unnecessary detail.
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 one-parameter tool, the description is largely complete: it explains what to pass, what to expect in return, and the main conditional case. It does not address what happens if the model is unknown or not registered in the pool, but the presence of an output schema and the clear conditional wording make this a minor gap rather than a blocking one.
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 schema has only a 'model' string parameter and no parameter description, so schema coverage is 0%. The description adds some context by framing 'model' as the identifier of a model that is not currently running, but it does not specify expected values, naming conventions, or where the model identifier comes from. This is partially compensated by the self-explanatory parameter name and the surrounding context.
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 clearly states the tool's purpose: relay to the user what is needed to bring up a model that is not currently running. It identifies the resource (model) and a specific action (request/relay), and the conditional 'if the model is already up, says so instead' further clarifies scope. It does not explicitly name a sibling tool, but the unique purpose is recognizable.
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 gives a clear usage condition: use this when a model is not currently running and you need instructions to give the user. It also handles the alternative case by noting that if the model is already up, the tool says so. It does not name alternative tools like list_models or register_model, but the intended context is reasonably explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate a task to an agent on a local model. Returns a job id immediately.
The agent is a headless Claude Code session (Read/Edit/Write/Glob/Grep/Bash, project
CLAUDE.md, same working tree) whose API calls go to the local endpoint. Write the task like a
brief for a capable but junior engineer: what to do, where, how to verify, and what to report.
Args:
task: The brief. Be explicit; local models follow less implicit context than Claude.
model: Pool name (see list_models) or a served model id/glob. Default from models.yaml.
endpoint: Force a specific endpoint; with no `model`, uses whatever it is serving.
cwd: Working directory (default: this server's cwd, i.e. the current project).
isolation: "none" (work in cwd, like a normal subagent) or "worktree" (fresh git worktree
on branch local-agent/<job>; kept only if the agent changed something, reported in
job.worktree with a diffstat). Use worktree for risky/large edits you want to review as a diff.
wait_s: If > 0, block up to this many seconds and return the result when done (else job id).
permission_mode: acceptEdits (default) | bypassPermissions | default | plan.
max_turns: Cap on agent turns (default from models.yaml).
allowed_tools: Override auto-approved tools.
system_prompt_append: Extra instructions appended to the Claude Code system prompt.
resume_job: Continue a previous job's session (same model) with `task` as the next message.
timeout_s: Wall-clock cap for the job.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| task | Yes | ||
| model | No | ||
| wait_s | No | ||
| endpoint | No | ||
| isolation | No | none | |
| max_turns | No | ||
| timeout_s | No | ||
| resume_job | No | ||
| allowed_tools | No | ||
| permission_mode | No | ||
| system_prompt_append | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the agent's toolset (Read/Edit/Write/Glob/Grep/Bash, project CLAUDE.md, same working tree), immediate-return behavior, isolation details including worktree retention and diffstat reporting, permission modes, resume semantics, and blocking behavior via wait_s. This goes well beyond what the name and schema reveal.
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 appropriately sized for a 12-parameter tool. Each sentence earns its place: the opening sentence states purpose and return behavior, the second gives task-writing guidance, and the arg list is dense but scannable. No redundancy.
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 12 parameters, no annotations, and an output schema to cover return values, the description is complete. It covers all parameters, defaults, the immediate-return/blocking distinction, worktree behavior, permission modes, and resume capability. Nothing an agent needs to invoke this tool 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 description coverage is 0%, so the description must fully compensate, and it does. Every one of the 12 parameters gets a meaningful explanation with defaults, allowed values, and behavioral effects (e.g., isolation explains 'none' vs 'worktree', permission_mode lists all options, resume_job explains continued sessions).
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 opens with 'Delegate a task to an agent on a local model,' which is a specific verb and resource, and immediately states the key behavioral distinction: 'Returns a job id immediately.' This clearly differentiates run_agent from the job-management siblings (job_log, cancel_job, job_status, wait_job).
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 gives strong usage context: how to write the task brief, when to use isolation='worktree' ('Use worktree for risky/large edits you want to review as a diff'), when wait_s should be used, and points to a sibling tool via 'Pool name (see list_models)'. It doesn't explicitly name alternatives for follow-up status checks (e.g., job_status/wait_job), but the immediate-return semantics make that implication clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block up to timeout_s seconds for a job to finish; returns its status/result either way.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the blocking behavior, the timeout bound, and the fact that it returns a status/result even when the job has not finished. This is meaningful transparency, though it does not mention error cases like invalid job_id.
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 entire description is one sentence with no filler. It front-loads the blocking behavior, states the timeout parameter, and conveys the return guarantee efficiently.
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 two-parameter wait tool, the description covers the core behavior and return guarantee, and an output schema exists to document the result shape. It could add a note about already-finished jobs or invalid IDs, but nothing essential is missing for correct usage.
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 0%, so the description needed to compensate. It clarifies that timeout_s is measured in seconds and controls the blocking duration, but it does not explain job_id beyond the implicit 'a job'. The parameter names are largely self-explanatory, so this is adequate but not exceptional.
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?
States a specific verb ('Block'), the resource ('a job'), and the outcome ('returns its status/result either way'). This clearly distinguishes wait_job from siblings like job_status or list_jobs, which check or list rather than block.
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 conveys a clear usage context: call this when you are willing to block up to a timeout for a job to finish, and you will get the result whether or not it completed. It does not explicitly name alternatives or state when not to use it, such as 'use job_status for non-blocking checks', so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cancel_jobjob_logjob_statuslist_jobslist_modelslocal_completeregister_endpointregister_modelrequest_modelrun_agentwait_jobScored across 11 tools
Most tools target distinct resources and actions: job lifecycle (run_agent, job_status, job_log, wait_job, cancel_job, list_jobs) and model/endpoint management (list_models, request_model, register_model, register_endpoint) are clearly separated. The main overlap risk is between wait_job and job_status, both returning status/result, but blocking vs non-blocking behavior distinguishes them.
The naming mostly follows a clear verb_noun pattern (cancel_job, list_models, register_model, run_agent, wait_job, list_jobs). Minor deviations exist with job_log, job_status, and local_complete, which use noun-first or adjective-verb constructions but are still readable and predictable.
11 tools is well-scoped for a local agent orchestration server. Each tool covers a distinct operational concern, and none feel redundant or superfluous.
The core domain is well covered: job creation, waiting, status, logs, cancellation, listing, plus model pool and endpoint registration and a one-shot completion fallback. Minor gaps include no explicit unregister/delete tool for models or endpoints, but these are not major blockers for typical workflows.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Connect ChatGPT, Claude, Cursor or VS Code to your Windows PC: files, terminal, browser, apps.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
