将子任务交给另一台机器上的本地模型，并在返回结果之前验证结果。
它是为解决一种特定形态的问题而构建的：能力强大、按量计费的助手运行在你面前的机器上，而一台完全够用的 GPU 机器却在角落里闲置。读取四十个文件、总结一个长页面、拉取一个数据集——这些都不需要昂贵的模型，而在助手的上下文中完成它们会消耗真正稀缺的那一种资源。
在作者的配置上实测，与在上下文中完成同样的四项任务相比：~2.7 倍更快，上下文消耗减少 6.1 倍，因为原始页面从未进入上下文。
任务必须附带检查。 无法说明如何知道任务是否成功的任务会被拒绝——不是警告，而是拒绝。
这不是对本地模型的不信任，而是调用方无法判断。当助手委派一个摘要任务并收到四百个自信满满的词时，它没有独立的方法知道这些词描述的是文档还是别的东西。没有检查就委派，等于又增加了一处绿灯毫无意义的地方。
检查刻意保持朴素：nonempty、contains、regex、json_keys、line_count、shell（你的 argv，退出码 0 即通过，输出通过管道送入 stdin），以及 summary_of（比源文本短，且不是源文本的副本）。
Related MCP server: Forgehand
工具 | 作用 | 工作发生的位置 |
| 一个普通提示词，带你自己定义的检查 | 模型主机 |
| 文本，或先抓取的 url/urls | 工作机（抓取 + 模型） |
| 搜索，阅读排名靠前的页面，总结 | 搜索在主机间交替，其余在工作机 |
| 抓取文件，报告字节数和 sha256 | 默认在工作机，也可在任何配置的主机 |
simple_job_stats 报告所有这些任务实际进行得如何，数据来自为每个任务写入的一行账本记录。
运行 MCP 服务器的机器上需要 Node 18+。
一个兼容 OpenAI 的聊天端点。 llama.cpp 的 llama-server、Ollama、vLLM、LM Studio，或托管的 API——任何能响应 POST /v1/chat/completions 的服务。
Python 3.9+，在负责抓取的机器上。仅用标准库；无需 pip 安装，无需 node，无需 beautifulsoup。
SSH 密钥认证，如果要使用第二台机器的话。这是可选的（见下文）。
两台计算机：
一台 Mac mini——日常工作站。16 GB 内存，通常有数 GB 的交换空间。它运行 Claude Desktop，因此也运行这个 MCP 服务器。
一台装有 RTX 5070 Ti 的 Pop!_OS 机器——实验室。它在 8080 端口上通过 llama-server 运行一个名为 ornith 的 35B 模型，一天中大部分时间都处于空闲状态。
一条 SSH 隧道让远程模型在 Mac 上看起来像本地模型：
ssh -N -o ServerAliveInterval=30 -L 127.0.0.1:8081:127.0.0.1:8080 pop-ospop-os 是 ~/.ssh/config 中的一个别名，带有密钥和 IdentitiesOnly yes，因此服务器可以通过 BatchMode=yes 以非交互方式访问它。
MCP 客户端条目就是：
{ "mcpServers": { "simple-job": { "command": "node", "args": ["/path/to/mcp-simple-job/index.js"] } } }其余由默认值完成：模型在 127.0.0.1:8081，工作机在 pop-os，账本在已有的 ~/Code/harness/ 目录中（如果存在的话）。
没有任何东西需要手动调用。助手选择工具——这比听起来更难，下文会介绍。
两台机器，一台运行客户端，一台运行模型：
{
"mcpServers": {
"simple-job": {
"command": "node",
"args": ["/path/to/mcp-simple-job/index.js"],
"env": {
"ORNITH_URL": "http://127.0.0.1:8081/v1/chat/completions",
"ORNITH_MODEL": "your-model-name",
"POP_HOST": "your-ssh-alias"
}
}
}
}一台机器——全部本地，没有任何 SSH：
{
"env": {
"ORNITH_URL": "http://127.0.0.1:11434/v1/chat/completions",
"ORNITH_MODEL": "qwen3:8b",
"SEARCH_HOSTS": "mac"
}
}SEARCH_HOSTS=mac 这个开关表示“没有第二台机器”。抓取、下载和搜索都在本地进行，搜索只有一个速率预算而不是两个。其他一切行为相同。
变量 | 默认值 | 作用 |
|
| 聊天端点 |
|
| 请求中发送的模型名称 |
|
| 工作机的 SSH 别名 |
|
| 要在哪些机器之间交替搜索；单机安装时设为 |
|
| 同一台机器两次搜索之间的最小间隔 |
|
| 一台机器被限流后暂停多长时间 |
| 位于 | 搜索计时状态的存放位置 |
|
| SQLite 账本 |
|
| 可选，要盖在行上的跟踪 id |
账本是可选的。 它会在首次使用时创建，如果无法写入，任务仍然会运行——日志记录是尽力而为的，绝不会阻塞工作。HARNESS_TRACE 是作者自己的跟踪设置的一个钩子；忽略它，行就只是有一个空的 trace id。
这是大多数人跳过的一部分，也是决定上述一切是否重要的部分。
一个没有任何东西会路由到它的工具，无论它工作得多好都是不可见的。作者有一个独立的 MCP 服务器，它工作得完美，但几个月里零调用，纯粹是因为从来没有任何东西告诉助手去使用它。构建一个能力与将请求路由到它是两件不同的事，而完成第一件会让人感觉已经完成了。
有三种方法可以缩小这个差距，从最便宜的开始。大多数人想要第二种。
1. 什么都不做，先看看。 有些客户端对工具描述的理解足够好，一个足够明显的请求——比如“总结这四十页”——会自动找到这个工具。在添加机制之前，值得先试一天。观察它是否真的被调用。
2. 把一条规则放在你的客户端保存常驻指令的地方。 Claude Desktop 项目指令、Claude Code 的 CLAUDE.md、.cursorrules、自定义 GPT 的指令——无论你的客户端在每一轮都会读取什么。类似这样：
有一个本地模型可以通过
simple-job使用。当材料尚未在上下文中且任务是机械性的时使用它：总结页面或文件、网络搜索加阅读、抓取下载、提取和重新格式化。它是免费的，不会在源材料上消耗上下文。当文本已经在上下文中、当任务需要解释而不是转写、或者当“正确”比“可检查”更重要时，自己做。绝不要委派需要判断的决策、必须正确的代码或文件编辑。
每个任务都必须携带检查——服务器会拒绝它无法验证的工作。
在何时不委派上花与“何时委派”同样多的篇幅。路由委派工具的失败模式是过度委派，而一个把所有事情都往下游送的助手，会在你想要判断的地方给你忠实的转写。
3. 如果你有路由器，就把它接入路由器。 如果你的设置已经将情境匹配到工具，就为“批量阅读或抓取尚未进入上下文的材料”添加一个条目。相对于常驻指令的优势在于它是可衡量的——你可以统计它在应该触发时是否触发了。常驻指令要么有效要么无效，而且没有任何东西记录是哪一种。
任何“看起来对”是唯一检验标准的东西。需要判断的决策。必须正确的代码。编辑文件。
还有一条通过测量而非品味发现的边界：小型本地模型能忠实转写，但不能解释。在测试中，它逐字复述了源文本中含糊的措辞，而不是解决其含义，并且把仓库的星标数总结得像是一个 bug 报告的一部分。把转写交给它。把解释留给自己。
下面的一切都是测量结果，而不是观点。这些数字也写在代码注释里。
推理模型从同一个 token 预算中产生它们的思考和答案。在一个总结任务上完全相同地运行三次，三次中有两次花费了 5,500–6,000 个字符思考，撞到上限，并以 HTTP 200 返回了空答案。
提高 max_tokens 没有修复它。reasoning_effort: "low" 没有修复它。一个 `` system 标签也没有修复它。只有 chat_template_kwargs: {enable_thinking: false} 修复了它，同一个任务随后用 258 个 token 就回答了。对于真正需要深思的任务，传入 think: true，并同时提高 max_tokens。
DuckDuckGo 不会礼貌地限流：
被服务的查询是 HTTP 200，约 28 KB，十个结果链接
被拒绝的查询是 HTTP 202，约 14.2 KB，其文本写着 “请完成以下挑战... 选择所有包含鸭子的方块”
这是 IP 上的一个验证码标记，而不是时间限制，而且拉开间隔并不能清除它。在静默四分钟后，从一台机器以 30 秒间隔发六个查询、从另一台以 15 秒间隔发六个查询，结果是 0 对 12。在被封锁期间每 5 秒轮询一次，162 秒内从未恢复——重试反而会喂养它。这个标记大约二十分钟后自行消退。
因此，搜索被拉开间隔，在机器之间交替（两个 IP 就是两个预算），并且限流被报告为 throttled，绝不会报告为“无结果”。这两者意思相反。
一个长页面会被截断以适配模型的窗口，而从顶部截断会静默地回答错误的问题。在一个 40,063 字符的页面、8,000 字符的窗口下被问到 “稀疏门控和负载均衡” 时，第一个版本返回了文章开头的流畅总结——其中“负载均衡”从未出现（它从第 16,181 个字符开始），“稀疏”也从未出现（14,671）。
因此 focus 引导窗口：先取开头作为上下文，然后取每个命名术语周围的段落，在每个术语获得第二个窗口之前，保证每个术语有一个窗口。两个早期版本都不够好——子串匹配在“download”中找到了“load”，报告了 42 次噪声命中；而按文档顺序取段落则在到达第 16,181 个字符之前就用完了预算。
如果页面从未使用这些词，调用会返回 ok:false 和 focus_not_found。零命中是比一段关于其他材料的貌似合理的总结更好的答案。
一个网站提供了 68,896 字节，其中只包含 40 个字符的文本（“Loading...”），这通过了原来的 if not text 守卫——于是这个页面外壳作为源材料进入总结，模型写出了一个自信的基准数字并引用它。
现在有两个测试，因为单独任何一个都会被欺骗：一个绝对下限，以及一个文本与字节的比率，它只会谴责一个同样短的页面。一个 GitHub issue 是 290,000 字节的标记，围绕 3,896 个字符的真实讨论，仅凭比率就把它丢弃了。
search_and_summarize 对页面进行编号，并要求使用 [1]、[2] 而不是 URL。当被要求提供 URL 时，模型把它在博客中读到的一个数字归因于一个文档页面——事实是真实的并且存在于材料中，但归因不是，而 summary_of 无法看到这一点，因为一个贴错标签的项目符号长度正确，并且不是复制品。
URL 是一长串不透明的字符串，难以正确复制。整数则不是，并且可以对照实际读取的页面进行范围检查——代码正是这样做的，对超出范围的数字使调用失败，并统计完全没有来源的项目符号。
通过两端的相同 sha256 验证：
客户端机器 | 工作机机器 | |
ssh 往返 | — | ~185 ms 每次调用 |
获取 4 个页面 | ~1.7 s | ~2.0 s |
下载 20 MB | 17.5 MB/s | 12.6 MB/s |
客户端机器在两项上都更快。 速度不是把工作发送给工作机的原因。原因是它持有模型，它在另一台机器被使用时处于空闲状态，而且第二台机器是第二个搜索预算。根据文件需要的位置来选择下载的主机，而不是根据吞吐量。
node test_e2e.mjs # 24 assertions, spawns the real server over JSON-RPC
node --test test/simple-job.test.mjs # 19 unit assertions on the checks端到端套件以客户端的方式启动实际的服务器，针对一个一次性的账本。进程内测试无法捕获 PATH 或环境变量错误，而这些正是只有在重启后才会出现的错误。
对 index.js 的更改在客户端下次启动服务器时生效。pop_agent.py 在每次调用时都会被重新读取，因此对获取、搜索和下载的更改会立即生效。
Download a file to pop (default) or to this Mac. Returns the path, byte count and sha256 — a download that reports success without those is not verified. Put it on pop when pop will use it (models, datasets, anything for the GPU); put it on the mac when you will open it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) url to download. | |
| dest | No | Directory on that machine. Default ~/Downloads. | |
| host | No | "pop" (default) or "mac". Measured 2026-08-21: the Mac is the faster of the two (17.5 vs 12.6 MB/s), so choose by where the file is needed, not by speed. | |
| max_mb | No | Refuse anything larger. Default 500. | |
| filename | No | Override the filename. | |
| overwrite | No | Replace an existing file. Default false — an existing file is an error, not a silent clobber. | |
| expect_sha256 | No | If given, the download fails unless the hash matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the expected return values ('path, byte count and sha256') and adds the important caveat that success without these is not verified, which is a meaningful behavioral warning. It also implies the default host is pop. However, it does not describe failure behavior beyond the overwrite rule (which is in the parameter schema), nor does it mention whether downloads are atomic or what happens on network errors. Given the lack of annotations, this is a strong disclosure but not exhaustive, so a 4 is appropriate.
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 two sentences long, front-loaded with the primary action and destination, followed by the return-value verification note and then the host-selection guidance. Every sentence carries meaningful information; there is no filler or redundancy. It is an excellent example of concise, high-signal writing.
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 7 parameters, no output schema, and no annotations, the description covers the core aspects: what it does, where it downloads, what it returns, and how to decide between hosts. It also adds the verification requirement that guards against silently bad downloads. It does not mention edge cases like how max_mb is enforced or what happens when an existing file blocks the download (though the parameter schema covers that), but these are secondary. Overall, an agent can call this tool safely and correctly, so a 4 is suitable.
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 already describes all 7 parameters with 100% coverage, so the baseline is 3. The main description adds value by explaining the strategic choice of host ('Put it on pop when pop will use it...'), which reinforces the host parameter's purpose and provides context beyond its schema description. It also emphasizes the verification requirement, which ties into the expect_sha256 parameter. While the schema covers syntax, the description adds usage logic, so a 4 is justified.
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 a clear verb-and-resource pair — 'Download a file' — and specifies the two possible destinations ('to pop (default) or to this Mac'), which uniquely defines the tool's action. It also distinguishes it from the sibling tools (simple_job, summarize, etc.) which are entirely unrelated, so there is no ambiguity about what this 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?
The description gives explicit, actionable guidance on when to use each host: 'Put it on pop when pop will use it (models, datasets, anything for the GPU); put it on the mac when you will open it.' This directly tells an agent how to choose the destination based on the intended use, and the default is also stated. No alternative tools are relevant, so this guidance is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web (DuckDuckGo), read the top pages on pop, and have ornith summarise them — one call, no Claude context spent on the raw pages. THE ONLY SEARCH TOOL HERE, and deliberately: DuckDuckGo rate-limits hard, so searches are spaced and alternated between this Mac and pop. A throttle is reported as a throttle, never as "no results".
| Name | Required | Description | Default |
|---|---|---|---|
| check | No | Optional. Defaults to {type:"summary_of"} against the fetched pages. | |
| count | No | How many search results to list. Default 6. | |
| focus | No | What you actually want to know, if narrower than the query. | |
| model | No | Default ornith:35b. | |
| pages | No | How many top results to read. Default 3, max 8. More pages costs seconds, not money. | |
| query | Yes | The web search query. | |
| think | No | Let ornith reason before answering. Default false. Measured 2026-08-21: with reasoning on, 2 of 3 summarise runs returned an EMPTY answer after burning the whole token budget on thinking. Turn it on only for a job that genuinely needs deliberation, and raise max_tokens with it. | |
| max_words | No | Target summary length. Default 250. | |
| max_tokens | No | Default 2048. Ornith reasons before answering; too low returns an empty answer. | |
| temperature | No | ||
| results_only | No | Skip reading and summarising; just return the search results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and excels: it discloses the DuckDuckGo backend, the reading and summarization pipeline, the lack of Claude context use, the spacing of requests, and the crucial behavior that throttles are reported truthfully. It even documents a known failure mode with the 'think' parameter. This is exemplary 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 front-loads the purpose but then becomes a run-on sentence mixing operational details, typos, and policy notes. While information-dense and not excessively long, it could be split into clearer sentences to improve scannability. It feels a bit stream-of-consciousness.
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 an 11-parameter tool with no output schema, the description covers the core use case, operational constraints, and a known gotcha ('think'). It doesn't describe the return value, but that's a reasonable trade-off given the already rich parameter documentation and the absence of an output schema. The description is sufficient for an agent to decide when 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 description coverage is high (91%), so the baseline is 3. The description itself does not add parameter-level details beyond what's in the schema, and the schema already describes 10 of 11 parameters. No contradiction or gap that requires the description to compensate.
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: 'Search the web (DuckDuckGo), read the top pages... and have ornith summarise them'. It also differentiates from siblings by declaring 'THE ONLY SEARCH TOOL HERE', making it unmistakable what this tool does relative to others. The typos ('pop', 'ornith') don't obscure the core verb-resource actions.
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 explicitly frames the tool as the only search option ('THE ONLY SEARCH TOOL HERE') and provides practical guidance on rate-limiting and throttle behavior. However, it doesn't explicitly state when *not* to use it (e.g., when you already have content to summarize, which sibling 'summarize' might handle), leaving exclusions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hand a plain subtask to ornith (35B, local, free) on pop and verify the result before returning it. REQUIRES a check — a task that cannot state how it would be known to have worked is refused. Good for: extraction against a schema, classifying, reformatting. Bad for: judgment calls, code that must be correct, editing files — do those yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What ornith should do. Be specific about the output format. | |
| check | Yes | How the result is verified. One of: {type:"nonempty"} | {type:"contains",text,case_sensitive?} | {type:"regex",pattern,flags?} | {type:"json_keys",required:[...]} | {type:"line_count",min?,max?} | {type:"shell",command:[argv...],timeout_ms?} (result is piped to stdin; exit 0 passes). | |
| model | No | Default ornith:35b. | |
| think | No | Let ornith reason before answering. Default false. Measured 2026-08-21: with reasoning on, 2 of 3 summarise runs returned an EMPTY answer after burning the whole token budget on thinking. Turn it on only for a job that genuinely needs deliberation, and raise max_tokens with it. | |
| context | No | Material for the task — the text, rows or code to work on. | |
| max_tokens | No | Default 2048. Ornith reasons before answering; too low returns an empty answer. | |
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it verifies the result before returning, refuses tasks without a check, and mentions limitations (bad for judgment calls, code, editing). However, it does not specify what happens if verification fails, error handling, or output format, leaving some behavioral aspects undisclosed.
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 concise and well-structured: it opens with the core action, then lists requirements and use cases. Every sentence adds value without redundancy, and the format is easy to parse.
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 there is no output schema, the description should explain the return value or error cases, but it only says 'returns it' without specifying format. It also omits details about parameter interactions (e.g., temperature affects creativity) and failure modes, leaving some operational context 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?
The schema already provides descriptions for all parameters (86% coverage). The description adds little beyond the note that a check is required (which is already in the schema). No additional semantic value is provided for parameters like temperature or max_tokens.
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 function: delegating a subtask to ornith and verifying the result. It explicitly lists good and bad use cases (extraction, classification, reformatting vs. judgment calls, code, editing), making the purpose and scope unambiguous.
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 provides explicit guidance on when to use the tool: it requires a verifiable check, lists suitable tasks, and explicitly warns against unsuitable ones (e.g., judgment calls, code) with 'do those yourself.' This clearly differentiates it from the alternatives (doing it manually or using other tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How delegation has actually gone: jobs by kind, how often the check passed, and speed. Answers whether this server is earning its place.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It implies a read-only informational tool but does not explicitly state that it performs no mutations, requires no auth, or has any other behavioral caveats. The phrasing 'answers whether this server is earning its place' is not operationally informative.
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 and front-loaded with the core subject, but the final clause 'Answers whether this server is earning its place' adds little operational value and is somewhat metaphorical. Still, it is concise overall with minimal 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?
For a zero-parameter statistics tool, the description gives a reasonable sense of the returned dimensions: jobs by kind, check pass rate, and speed. However, it does not clarify the output format or precisely what 'speed' refers to, and it lacks any comparison to sibling tools, leaving some ambiguity for an agent.
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 accepts zero parameters, so the schema already fully covers the input surface. The description does not need to explain parameter details, and the baseline for zero-parameter tools applies.
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 communicates that this tool reports statistics about job delegation, including breakdowns by kind, check pass rates, and speed. It is clear enough to identify the tool's purpose, though it lacks an explicit verb like 'returns' or 'computes' and does not explicitly differentiate itself from siblings.
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 guidance on when to use this tool versus alternatives such as simple_job or summarize. No context, conditions, or exclusions are provided that would help an agent choose this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise text with ornith on pop. Free, local, and it does not spend Claude context on the source. Pass the text directly, or a url/urls to fetch first (fetched on pop). The default check is a real one: the summary must be substantially shorter than the source and not a copy of it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Fetch this page on pop and summarise it. | |
| text | No | The material to summarise. Either this or url/urls. | |
| urls | No | Fetch several pages on pop and summarise them together. | |
| check | No | Optional. Defaults to {type:"summary_of"} against the source text. | |
| focus | No | What the summary should be about, if not everything. e.g. "only the benchmark numbers". | |
| model | No | Default ornith:35b. | |
| style | No | "bullets" (default) or "paragraph". | |
| think | No | Let ornith reason before answering. Default false. Measured 2026-08-21: with reasoning on, 2 of 3 summarise runs returned an EMPTY answer after burning the whole token budget on thinking. Turn it on only for a job that genuinely needs deliberation, and raise max_tokens with it. | |
| max_words | No | Target length. Default 200. | |
| max_tokens | No | Default 2048. Ornith reasons before answering; too low returns an empty answer. | |
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, and it does: free, local, avoids consuming Claude context, fetches URLs, and enforces a real anti-copy/shorter-than-source check. It does not cover failure modes or service dependencies, but the main behavioral traits that would affect an agent's invocation and expectation are present.
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 front-loaded with the main verb and purpose. Every sentence contributes useful information, but 'on pop' appears twice without definition, slightly hurting clarity. It is appropriately sized and not padded.
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 11 parameters, a nested check object, and no output schema, the description covers the main usage and the default verification behavior but leaves gaps: return value shape, error/failure behavior with URLs, and what the check object supports beyond its default. The schema covers most parameters, but the missing output context is notable.
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 high at 91%, so the baseline is 3. The description adds a little context about text/url/urls usage and the default check, but mostly repeats what the schema already documents. It does not add meaningful detail for parameters like focus, style, model, or temperature.
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 the core action clearly with a specific verb and resource: 'Summarise text with ornith on pop.' It also clarifies the two input modes (direct text or URL/URLs) and differentiates itself via 'does not spend Claude context on the source.' However, 'on pop' is unexplained jargon, and it does not explicitly contrast with sibling search_and_summarize, so it is not a 5.
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 explains how to invoke the tool ('Pass the text directly, or a url/urls to fetch first') but provides no guidance on when to choose this tool over its siblings. search_and_summarize is a plausible alternative for search-then-summarize use cases, yet no exclusion or comparison is mentioned.
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.
v1.0.0downloadsearch_and_summarizesimple_jobsimple_job_statssummarizeScored across 5 tools
Each tool has a clear, distinct purpose: simple_job delegates a generic subtask, summarize condenses text, search_and_summarize combines web search with summarization, simple_job_stats reports on job execution, and download retrieves files. No two tools overlap in functionality.
All tool names follow a consistent lowercase_with_underscores convention, and related tools (simple_job, simple_job_stats) share a common prefix while remaining descriptive. No mixed camelCase or other styles.
With 5 tools, the server is well-scoped—neither bare nor cluttered. Each tool serves a distinct, essential function, and the count aligns with the apparent purpose of task delegation and information retrieval.
The tool set covers the core operations needed for the server's domain: executing a job, summarizing, searching and summarizing, tracking job stats, and downloading files. No obvious missing functionality for the stated purpose.
Local ML: speech to text (SRT/VTT), text embeddings, reranking, similarity, entities, zero-shot.
Hand tasks, bugs and finished work to AI coding agents, and get back a write-up with evidence.
Exact IBAN, VAT, cron, regex answers; HTML/URL to hosted PDF or screenshot; agent memory; workflows.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation