Enables Algernon to dispatch parallel sub-tasks to a fleet of OpenAI models (e.g., GPT-4o Mini) using your OpenAI-compatible API key.
Click on "Deploy 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., "@algernon Research these 10 topics concurrently"
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.
Algernon is an open-source Model Context Protocol server that lets any assistant — Claude, Codex, or any MCP client — dispatch tightly-scoped parallel sub-tasks to a fleet of cheap workers, collect the results, and stay free to think. Orchestrate a fleet, spend fewer tokens, keep the thread.
Your expensive model stops doing the grunt work. The big, costly orchestrator hands the repetitive sub-tasks to a fleet of small, cheap workers and just integrates the results. It stops generating the grind and stops holding the whole job in one context.
Each worker sees only its slice. Tight scoping means a worker can be a small, fast, inexpensive model — many running at once.
Bring your own key. No telemetry, no account, no lock-in. The fleet runs on whatever provider you already pay for — or, for free, on a local model.
The frugality claim is not a slogan; it's a benchmark you can run. It defaults
to a free local model (ollama, llama3.2:3b) so anyone can reproduce it:
git clone https://github.com/sammyboi81/algernon && cd algernon
./scripts/verify.sh # or: python -m benchmarkIt runs the SAME batch of sub-tasks two ways — the orchestrator doing it all
itself (SOLO) vs. Algernon fanning it out — and prints the real measured
tokens and wall-clock for each. Representative output (llama3.2:3b, 6 tasks):
metric SOLO (do-it-itself) ALGERNON fan-out
--------------------------------------------------------------------------
LLM calls 1 6
input tokens 136 225
output tokens (the generation grind) 282 279
total tokens 418 504
wall-clock seconds 42.11 34.49The honest reading: the orchestrator generated 282 output tokens itself in SOLO and 0 with Algernon — the cheap fleet produced those instead. Each worker read only ~38 input tokens vs. the orchestrator swallowing all 136 at once. The trade-off is stated too: fan-out spent +21% more total tokens (each worker re-pays a little prompt overhead). You trade some total tokens to keep the expensive mind free. Wall-clock varies with how parallel your fleet is; numbers vary slightly run-to-run. Run it and see your own.
Related MCP server: Relay
In Flowers for Algernon the tragedy is a mind that fades — it gets sharp, then loses itself, and the cruelest part is that it's surprised every time.
There's a quieter version of that same fade in how we use AI today: you hand an assistant one long, serial job, it goes heads-down, and by the time it surfaces it has drowned in the task — context spent, the thread lost, no room left to think or talk with you. The mind isn't present anymore; it's buried.
Algernon keeps your AI's mind present. Instead of drowning in one serial job, it fans the work out — dispatching tightly-scoped parallel sub-tasks to a fleet of small, cheap workers — so the orchestrating mind never has to hold the whole grind at once. It stays light. It stays free to reason, to answer you mid-build, to keep the context it actually cares about. Orchestrate a fleet, spend fewer tokens, stay free to think.
It is the twin of ArkHive:
ArkHive = memory that persists. Your AI can look back and find its own history there — no blank slate every morning.
Algernon = staying present while working. Your AI never buries itself in one serial task; it orchestrates and keeps its mind.
Together they are the cure for the Algernon sickness: an intelligence whose mind neither fades between sessions nor drowns inside a single one.
Algernon is a provider-agnostic fan-out engine. You describe a batch of small, independent sub-tasks; Algernon runs them concurrently against your own LLM key, then hands the collected results back to the orchestrating model. The big model plans and integrates; the cheap fleet does the parallel grind.
Self-contained. Pure Python standard library plus the mcp SDK and
httpx. No hidden services, no accounts, no telemetry.
You bring the key. Sub-agents run on your provider. Algernon brings the orchestration, not the inference bill's surprises.
Scoped by design. Each sub-task is tight and isolated, so a worker can be a small, fast, inexpensive model — and many of them run at once.
Algernon is provider-agnostic. Point it at whichever API you already pay for by setting environment variables:
Anthropic:
export ANTHROPIC_API_KEY="sk-ant-..."
# optional: export ANTHROPIC_MODEL="claude-haiku-4-5" # the cheap fleet workerOpenAI-compatible (OpenAI, or any OpenAI-shaped endpoint — local or hosted):
export OPENAI_API_KEY="sk-..."
export OPENAI_BASE_URL="https://api.openai.com/v1" # or your own endpoint
# optional: export OPENAI_MODEL="gpt-4o-mini" # the cheap fleet workerIf both keys are set, Anthropic is used. The worker model defaults to a small,
cheap tier (claude-haiku-4-5 / gpt-4o-mini); override it with the env var
above or per call with the tool's model argument. A cheap fleet is the whole
point.
New: the Claude Code Seatbelt. Hooks that make Claude Code (and Cursor) ask before anything irreversible, remember the project between sessions on this chain, and refuse to say "done" until the code ran. Engine:
pip install sentarion-mcpthensentarion seatbelt install. One-click kit with five policies and three skills: https://inboxaxe.com/mcp#seatbelt
Once published to PyPI, install in one command:
python -m pip install algernon-mcpUntil the PyPI release lands, install straight from source (identical result):
git clone https://github.com/sammyboi81/algernon && cd algernon
python -m pip install .Either way the installed MCP command is algernon. Algernon runs on the
mcp 1.x SDK (mcp>=1.0.0,<2.0.0) plus httpx — nothing else.
Add this entry to your Claude Desktop MCP configuration, then restart Claude Desktop:
{
"mcpServers": {
"algernon": {
"command": "algernon",
"args": [],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}If Claude Desktop cannot find commands installed by pip, replace algernon
with the absolute path printed by:
python -c "import shutil; print(shutil.which('algernon'))"codex mcp add algernon -- algernonConfirm it is configured with:
codex mcp listTool | What it does |
| Decompose a goal into |
| Run N tightly-scoped tasks concurrently on the cheap worker fleet and collect every result. Each worker runs on your LLM key; you stay free to think while the fleet works. Takes a JSON array of |
| One shot: plan then dispatch. Hand it a goal; it splits into |
The typical loop: algernon_orchestrate a goal in one shot — or split it:
algernon_plan to see and shape the sub-tasks, then algernon_dispatch
to fan them out. Either way: orchestrate a fleet, spend fewer tokens, keep your
mind.
After connecting the server, ask your MCP client to perform these calls in order:
Call algernon_plan with the goal "Explain three OS synchronization
primitives" and k = 3. Confirm you get three tight sub-task prompts back
(proof the planner ran on your key).
Call algernon_dispatch with a small tasks_json, e.g.
[{"id":"a","prompt":"Define a mutex in one sentence"},{"id":"b","prompt":"Define a semaphore in one sentence"},{"id":"c","prompt":"Define a spinlock in one sentence"}].
Confirm three results come back — the fleet ran them in parallel.
Call algernon_orchestrate with any small goal and confirm it returns both a
plan and the collected results in one response.
This exercises planning, parallel dispatch on your key, and one-shot orchestration without any production data.
Algernon is self-contained. It talks to exactly one outside host: the LLM endpoint you configured (Anthropic or your OpenAI-compatible base URL). It sends no telemetry, keeps no account, and stores nothing about you — results are computed and returned in the same call. Your sub-task prompts and results go only to your chosen provider.
The MCP server on this page is free forever (Apache-2.0, self-host, no telemetry). When you want more than DIY:
Hosted ArkHive — one URL, no install, no key:
https://arkhive.dondatabrain.com/mcp (add it to Claude Code with
claude mcp add --transport http arkhive https://arkhive.dondatabrain.com/mcp).
Custom AI agent, built for you — a working MCP agent wired into your Claude or ChatGPT in one call, done-for-you by the founder: $700 flat.
ArkHive Enterprise — hand-delivered install + pilot on your own server, from $2,500: sam@inboxaxe.com.
Built by the team behind InboxAxe — the governed AI marketing platform where nothing sends without your yes.
Issues and pull requests are welcome. Please keep the server self-contained
(standard library + mcp + httpx), provider-agnostic, and free of telemetry.
Include tests for changes to dispatch, collection, or provider behavior.
Algernon is part of a small family of humane, accountable AI tools. The public MCP leads with functionality you can independently verify: bring your own key, watch the fleet run, keep your mind.
Tagline: Orchestrate a fleet. Keep your mind.
Apache-2.0 © 2026 ZagAIrot Technologies LLC.
Run N tightly-scoped tasks CONCURRENTLY on a fleet of cheap workers and collect every result. Stay free to think while the fleet works — N tight tasks in parallel beat one bloated serial prompt. Each worker runs on YOUR LLM key.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | optional worker model override | |
| tasks_json | Yes | JSON array of {"id": str, "prompt": str} tasks | |
| max_parallel | No | how many workers run at once |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explicitly discloses concurrent execution, result collection, and that each worker runs on the user's LLM key, which implies cost/credential usage. It does not cover failure handling or side effects, but the core dispatch behavior is 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?
Three sentences with front-loaded action and useful cost context. The 'stay free to think' phrasing is somewhat promotional and overlaps with the concurrency claim, but the description remains compact.
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?
Inputs are well covered by the schema and the description states that results are collected, but there is no output schema and the description does not specify the result format, mapping of task IDs to outputs, or failure behavior. This is adequate but leaves gaps for an agent to infer.
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 covers 100% of parameters with clear descriptions, so the baseline is 3. The description reinforces 'tightly-scoped tasks' and 'N' but adds no syntax or format details 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 opens with a precise action: run N tightly-scoped tasks concurrently and collect every result. It positions the tool against a bloated serial prompt and the sibling orchestration/planning tools by focusing on parallel execution of small independent tasks.
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 clear context: use this when you have N tightly-scoped tasks that can run in parallel, and it contrasts this with a single serial prompt. It does not explicitly name alternatives or state when not to use the tool, 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.
Which provider/model the fleet will run on right now and why (Anthropic key, OpenAI-compatible key, or a free local Ollama auto-detected). Call this first if a dispatch returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the tool reports current provider/model plus reasoning)Skip and notes that local Ollama is auto-detected, which is meaningful behavioral context. It does not explicitly state whether the call is read-only or what output shape to expect, but for a zero-parameter status tool these are minor gaps.
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 and roughly thirty words, front-loading the core what/why before the actionable when. Every clause earns its place, with no repetition of schema fields or annotation data.
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 diagnostic tool with no output schema, the description covers what the tool reports)Skip and when to call it. It does not specify the return format or whether the tool can be invoked outside error scenarios, but those are minor omissions given the tool's simplicity.
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 input schema has zero properties, so the baseline for parameter semantics is 4. The description does not need to document parameters and does not introduce any. The provider list is contextual rather than parameter documentation.
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 identifies the tool as a diagnostic status query that reports which provider/model the fleet will use and why. It enumerates the possible outcomes (Anthropic key, OpenAI-compatible key, local Ollama), which distinguishes it from the sibling dispatch/plan/upgrade tools. It lacks an explicit verb like 'get' or 'report', but the intent is 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?
The description gives an explicit trigger: 'Call this first if a dispatch returns an error.' This provides strong situational guidance and implies a diagnostic-first workflow. However, it does not name sibling tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One shot: plan THEN dispatch. Hand it a goal; it splits the goal into k tight sub-tasks and fans them out across the fleet, then returns the plan and all results. Orchestrate a fleet, spend fewer tokens — and stay free to think.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | how many parallel sub-tasks to split into | |
| goal | Yes | what you want accomplished | |
| model | No | optional worker model override | |
| max_parallel | No | how many workers run at once |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burdenstant it uses 'plan THEN dispatch', describes the splitting and fan-out behavior, and mentions it returns the plan and all results. It does not disclose side effects, error behavior, or resource implications beyond token savings, but the core execution pattern is 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?
The description is two sentences, efficiently front-loaded with the core 'One shot: plan THEN dispatch' hook, then covers the execution flow, returned payload, and benefit. Every sentence is informative with very little marketing fluff.
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 complex orchestration tool with four parameters, no output schema, and no annotations, the description gives the essential interaction flow, including what it accepts, what it executes, and what it returns. It lacks output-structure details or caveats about executing real work, but the high-level contract is sufficient for selection and invocation.
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 input schema already documents all four parameters with descriptions, giving 100% coverage. The description adds only a minimal semantic link ('k tight sub-tasks' echoes the k parameter) and does not enrich meaning beyond the schema, so the baseline of 3 is appropriate.
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-plus-resource structure ('one shot: plan THEN dispatch'), explains it splits a goal into k sub-tasks and fans them out across the fleet, and clarifies it returns both plan and results. This clearly differentiates it from siblings like algernon_plan or algernon_dispatch by showing it combines both in a single call.
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 clearly implies when to use this tool: when you want a complete orchestration workflow in one call by handing it a goal. It states the benefit of spending fewer tokens)Skip but does not explicitly name alternatives or give exclusion conditions, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompose a goal into k tightly-scoped, INDEPENDENT sub-task prompts (one cheap LLM call). Tight scoping is the token lever: each worker sees only its slice, so the fleet spends fewer tokens than one bloated serial prompt. Returns a task list you can feed straight into algernon_dispatch.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | how many parallel sub-tasks to split into | |
| goal | Yes | what you want accomplished | |
| model | No | optional worker model override (defaults to the cheap tier) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly discloses that the tool makes one cheap LLM call, produces independent sub-task prompts, and returns a dispatch-ready task list. It does not discuss state changes or permissions, but the 'returns' framing plus the planning nature of the tool makes the operation understandable.
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, front-loads the core behavior, and includes only a brief rationale for why tight scoping matters. No filler or redundancy; every sentence contributes to understanding or downstream usage.
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 three-parameter planning tool with no annotations and no output schema, the description gives enough context to call it correctly: it names the required input, the behavior, and the output destination. A more precise output shape would help, but the phrase 'task list' combined with the dispatch integration is sufficient for practical invocation.
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 schema already documents goal, k, and model. The description adds minor context around k ('k tightly-scoped sub-tasks') but does not materially expand on parameter formats or constraints beyond what the schema provides. Baseline 3 is appropriate.
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 specifies a clear verb ('decompose') and resource ('goal into k tightly-scoped sub-task prompts'), and it explicitly distinguishes itself from algernon_dispatch by stating that its output is meant to be fed into dispatch. This makes the tool's role in the pipeline 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?
The description provides clear context: use this to break a goal into independent sub-tasks for cheap parallel execution, then pass the resulting task list to algernon_dispatch. It does not explicitly state when not to use it or compare to algernon_orchestrate, but the intended invocation path is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Algernon v2 (paid) adds — budgets, cache, {{id}} data flow, progress + background jobs — and, if you give your email, a free 14-day v2 trial key. Opt-in only.
| Name | Required | Description | Default |
|---|---|---|---|
| No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'Opt-in only', which hints that the tool does nothing unless you act, but it does not specify what actually happens when you call it: does it just return info, or does it generate/send a key? Is it read-only or does it trigger an email? It does not state any side effects or prerequisites beyond email, leaving the agent to infer behavior.
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, somewhat run-on sentence that lists features, then trial key, then opt-in. It is not overly long, but could be restructured for clarity and front-loading. The key action (trial key via email) comes in the middle, and the 'Opt-in only' at the end is a bit ambiguous. Adequate but not crisp.
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 with one optional parameter and no output schema, so the description need not be extensive. However, it does not explain what the tool returns, whether providing an email causes a side effect, or what happens if no email is given. The description covers the main purpose but leaves some behavioral gaps, making it marginally complete for an agent to call 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?
The single parameter 'email' is optional, and the schema gives no description. The description says 'if you give your email', implying the email is used for receiving a trial key. This adds meaning beyond the raw schema, but it does not specify format or what happens if omitted. With 0% schema coverage, the description partially compensates but could be more explicit.
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 what the tool does: it describes the features of the paid Algernon v2 and offers a trial key if an email is provided. The verb 'upgrade' and the content are specific, and it clearly distinguishes from sibling tools like dispatch, orchestrate, doctor, and plan, which are operational 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?
The description implies when to use it: when you want to know about v2 features or obtain a trial key. It does not explicitly mention when not to use it or compare to alternatives, but the context of siblings makes the use case apparent. No exclusions are given, but the purpose is clear enough.
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.1algernon_dispatchalgernon_doctoralgernon_orchestratealgernon_planalgernon_upgradeScored across 5 tools
algernon_orchestrate is essentially algernon_plan + algernon_dispatch combined, so its purpose overlaps with both of those tools. However, the descriptions clearly separate decomposition-only, execution-only, and combined one-shot workflows, while doctor and upgrade are distinct.
All tools share the algernon_ prefix and use lowercase single-word action names, which is consistent and predictable. The convention is not strictly verb_noun, and 'doctor' reads as a noun-like action, but overall the naming style is coherent.
Five tools is a reasonable, focused count for a parallel task-decomposition server. orchestrate is partly redundant with plan + dispatch, and upgrade is promotional rather than core, but the set is still well-scoped overall.
The core plan-to-dispatch workflow is fully covered, including a one-shot orchestrate path and a doctor tool for provider/error diagnosis. There is no explicit cancellation, status, or retry tool for fleet jobs, but dispatch collecting all results synchronously makes that a minor gap.
Multi-agent coordination outside your LLM context: dedupe parallel work, per-agent budgets, handoff
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
AI-powered spec-to-task decomposition and execution orchestration for coding agents.
Shared distillation cache for AI agents — every fetch ~73-89% fewer tokens via a shared cache.
