algernon
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_MODEL | No | Model used for the worker fleet when using an OpenAI-compatible API. | gpt-4o-mini |
| OPENAI_API_KEY | No | OpenAI API key or compatible API key for OpenAI-compatible endpoints. | |
| ANTHROPIC_MODEL | No | Model used for the worker fleet when Anthropic is used. | claude-haiku-4-5 |
| OPENAI_BASE_URL | No | Base URL for OpenAI-compatible endpoint. Override for custom or local endpoints. | https://api.openai.com/v1 |
| ANTHROPIC_API_KEY | No | Anthropic API key. Used if set, even if OPENAI_API_KEY is also set. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| algernon_doctorA | 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. |
| algernon_upgradeA | 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. |
| algernon_planA | 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. |
| algernon_dispatchA | 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. |
| algernon_orchestrateA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.