Async Hero
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASYNC_HERO_MODEL | No | Optional model override for all worker profiles. | |
| DEEPSEEK_API_KEY | Yes | Provider API key. For the default DeepSeek configuration, this is the key used by the isolated Codex environment. | |
| ASYNC_HERO_CODEX_BIN | No | Path to the Codex executable. | codex |
| ASYNC_HERO_STATE_DIR | No | Directory for SQLite database and immutable job artifacts. | ./state |
| ASYNC_HERO_WORKSPACE | No | Authorized research workspace root. Only this directory may be inspected by workers. | current directory |
| ASYNC_HERO_CODEX_HOME | No | Path to the isolated Codex configuration directory. | ~/.async-hero/codex |
| ASYNC_HERO_MAX_TIMEOUT | No | Hard timeout ceiling for individual jobs, in seconds. | 3600 |
| ASYNC_HERO_MAX_WORKERS | No | Global maximum number of concurrent workers. | 1 |
| ASYNC_HERO_MAX_EVENT_BYTES | No | Maximum size of per‑job JSONL event stream, in bytes. | 8388608 |
| ASYNC_HERO_MAX_RESULT_BYTES | No | Maximum size of final result, in bytes. | 2097152 |
| ASYNC_HERO_MAX_STDERR_BYTES | No | Maximum size of per‑job stderr log, in bytes. | 2097152 |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_jobC | Queue one controlled research job and return immediately with its job metadata. |
| start_jobsA | Atomically validate, queue, and immediately return metadata for multiple jobs. |
| get_jobA | Return current metadata and status for one job. |
| get_jobsB | Return current metadata and status for selected jobs. |
| get_resultA | Return persisted job metadata and its result when completed. |
| get_resultsB | Return persisted metadata and results for selected jobs. |
| list_jobsB | List recent jobs, optionally filtered by status. |
| cancel_jobB | Cancel a queued or running job, terminating the worker process tree. |
| cancel_jobsB | Cancel selected queued or running jobs. |
| list_worker_profilesA | List declarative worker profiles and capabilities; optionally reload TOML files. |
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 10 tools
The singular/plural pairs (start_job/start_jobs, get_job/get_jobs, get_result/get_results, cancel_job/cancel_jobs) are clearly distinguished by cardinality, and list_jobs/list_worker_profiles target different resources. The only minor ambiguity is between get_job and get_result, but descriptions clarify that get_result is for completed results.
All tool names follow a consistent verb_noun pattern: start, get, list, cancel, and list_worker_profiles is the only compound noun but still fits the pattern. Singular and plural forms are used systematically.
10 tools is well-scoped for a job queueing and management server. Each tool serves a distinct purpose, and the singular/plural pairs cover both single-item and batch operations without unnecessary bloat.
The surface covers the full job lifecycle: create, read, list, cancel, and retrieve results. A minor gap is the lack of an explicit retry or delete operation, but the core workflow is complete.