DZ23 Subagents Universal MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CUSTOM_MODEL | Yes | Model ID for the custom provider, e.g. qwen3-coder | |
| DZ23_ROTATION | Yes | Model rotation list, e.g. custom:qwen3-coder | |
| CUSTOM_BASE_URL | Yes | Base URL for the custom OpenAI-compatible server, e.g. http://127.0.0.1:11434/v1 | |
| DZ23_ALLOW_PAID | No | Set to false to block paid and low-cost categories. Categories mixed and free-tier may still incur costs. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_modelsA | List configured, policy-eligible routing targets with tier and adapter capabilities. No network calls. |
| provider_inventoryA | Inventory every registered provider with configuration status and credential source, never credential values. No network calls. |
| discover_modelsA | Query provider /models catalogs (cached five minutes). A catalog entry does not prove inference access. |
| health_checkA | Run a tiny real generation on every eligible target in parallel. Requires confirm_billable=true; may consume provider quota or credits. |
| verify_modelA | Run one minimal, non-sensitive generation against provider:model to prove inference access. Requires confirm_billable=true, may consume credits, never runs automatically, never retries or fails over. |
| project_initA | Create or update shared project metadata. Does not clone or read the repository. Use one stable project_id per repository and pass it to every later tool call. |
| mission_statusB | Read mission state and recent journal events. Agent outputs are returned as short previews unless include_outputs=true. |
| memory_checkpointA | Persist a structured handoff checkpoint for another harness or agent. Creates the mission when absent. Use the same project_id and mission_id the task used for delegate, consensus and swarm_run. |
| delegateA | Delegate one advisory text task with bounded retries, failover and mission context. May consume provider credits. Reuse the project_id and mission_id of the current task (from project_init / memory_checkpoint); when omitted, results go to project "default" and a new random mission that mission_status and memory_checkpoint will not find. |
| consensusA | Ask 2-5 independent reviewers and return responses, observed diversity and an optional heuristic synthesis. May consume provider credits. Reuse the project_id and mission_id of the current task (from project_init / memory_checkpoint); when omitted, results go to project "default" and a new random mission that mission_status and memory_checkpoint will not find. |
| swarm_runA | Run up to seven advisory specialists in parallel, then one integrating reviewer. May consume provider credits and take minutes. Reuse the project_id and mission_id of the current task (from project_init / memory_checkpoint); when omitted, results go to project "default" and a new random mission that mission_status and memory_checkpoint will not find. |
| mission_startA | Start a mission in the background and return a job_id immediately. With plan, runs a task graph: nodes whose depends_on are done run in parallel (dependency results passed as untrusted data), failed nodes retry up to max_attempts, nodes after a failure are skipped, progress is saved in dag_state and resume_plan: true skips nodes already done (also after a restart). Without plan, runs a loop where each iteration runs swarm_run with the previous integration as diagnosis; near-identical results switch routing strategy and then stop as failed_safe. Progress is kept in the mission loop_state, never in status, next_action or goal. The job ends completed only when the harness recorded new passing tests (memory_checkpoint) during the job; otherwise awaiting_acceptance. May consume provider credits. Reuse the project_id and mission_id of the current task (from project_init / memory_checkpoint); when omitted, results go to project "default" and a new random mission that mission_status and memory_checkpoint will not find. |
| mission_status_jobA | Status of a mission job. After a server restart pass project_id and mission_id: a job that was still running is reported as orphaned. |
| mission_pauseA | Request a pause; the job stops after the current iteration and can be resumed. |
| mission_resumeA | Resume a paused job as a new job_id with the same goal, roles, criteria and remaining iterations. |
| mission_cancelA | Cancel a running or paused job. A finished job keeps its final status. |
| mission_claimA | Claim a mission for one harness with expiry. While the lease is live, memory_checkpoint, delegate, consensus, swarm_run and mission_start on that mission need its token; others receive mission_busy. Renew by claiming again with lease_token. Leases coordinate cooperating harnesses; they are not authentication. |
| mission_releaseA | Release a lease with the token returned by mission_claim. |
| handoff_exportA | Return a compact Markdown briefing for another harness. |
| mission_listB | Missions with status, goal, next action, loop/graph progress and resource URI. Same data as MCP resources, for harnesses without resources support. |
| playbook_getA | Without name: list the playbooks (the MCP prompts). With name and arguments: the rendered instructions. For harnesses without MCP prompts support. |
| routing_explainA | Which models the server would use for a task type right now, in order, and why others are skipped: cost tier, eligibility, cooldowns, observed success and latency, quota from provider headers. No provider calls. |
| cost_estimateA | Upper bound of calls, tokens and cost (when DZ23_PRICES_FILE has prices) for delegate, consensus or swarm_run before running it. No provider calls. |
| account_statusA | Which AI CLIs (Claude Code, Codex, Gemini CLI, Qwen Code, Copilot CLI, OpenCode, Cursor Agent) are installed and logged in with an account or subscription, and the login command for each. Account providers are used before per-token APIs. No model calls. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit_project | Audit a project with evidence, severity and explicit unknowns. |
| fix_bug | Diagnose a bug and propose a bounded fix without claiming it was executed. |
| review_pull_request | Review a change adversarially for bugs, security and regressions. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Several tools have overlapping purposes: delegate, consensus, and swarm_run all invoke model-based text generation and can consume credits, while mission_status, mission_status_job, and mission_list all report mission-related state. Descriptions clarify the differences, but an agent could plausibly select the wrong tool in ambiguous situations.
Naming conventions are mixed: some tools use verb_noun (list_models, discover_models, verify_model, project_init), some use noun_verb (swarm_run, mission_start, routing_explain, cost_estimate, health_check), and a few use bare nouns (delegate, consensus). All names are snake_case and readable, but the inconsistent ordering and verb placement make the pattern hard to predict.
At 24 tools, the surface is large but not unreasonable given the broad scope covering mission orchestration, delegation, model routing, provider inventory, cost estimation, and health verification. It sits at the heavy end of the acceptable range and could benefit from consolidation.
The tool set covers the main workflows well: mission lifecycle (start, pause, resume, cancel, claim, release, status), delegation modes (delegate, consensus, swarm_run), routing and provider inspection, cost estimation, and health checks. Minor gaps exist, such as no direct mission editing or provider configuration mutation, but these are likely handled outside the MCP surface.