Skip to main content
Glama

DZ23 Subagents Universal MCP

CI npm license node

Um projeto. Vários modelos. Uma memória compartilhada.

Roteador MCP self-hosted para delegar tarefas de texto/código a modelos de IA, coordenar especialistas em paralelo e guardar o estado explícito de cada missão. v4.4.1 · MIT · prévia de engenharia · Node.js 22+ · sem dependências npm de runtime.

English · Começar em 60 s · Instalação · Ferramentas · Operação · Arquitetura · Provedores · Segurança · Validação

Para que serve

Claude pode registrar uma missão; Codex, Hermes ou outro cliente pode consultar esse registro e continuar o trabalho. Para isso, ambos precisam usar a mesma instância de memória, project_id e mission_id. A memória não vem automaticamente da conversa privada do harness: ele deve enviar os fatos, decisões e checkpoints.

Se uma chamada ao provider falhar, o roteador classifica o erro, repete apenas falhas temporárias e tenta o próximo alvo elegível com o estado persistido da missão. Não há recuperação de pensamentos internos, tokens não recebidos ou efeitos externos não registrados.

Os subagentes são chamadas independentes de modelo com papéis especializados, não processos com terminal, navegador ou acesso ao repositório. Eles produzem texto/código; o harness aplica patches, executa testes e revisa os resultados sob as próprias permissões.

Related MCP server: BirdEye

O fluxo

Claude / Codex / Hermes / cliente MCP
                 |
     stdio (local) ou HTTP autenticado
                 |
  validação de schema · escopos · rate limit · request_id
                 |
     roteador · orçamento · retry/failover · diversidade
          |                          |
   memória versionada           pool de modelos
   estado / journal / uso       architect / backend / frontend
   checkpoints / contexto       security / QA / devops / reviewer
          |                          |
          +------ resposta e handoff ------+
                       |
           o harness aplica e verifica

O que existe hoje

Área

Implementado nesta versão

MCP

24 ferramentas (11 da 4.0.0 + 13 novas); resources e prompts; revisões 2026-07-28 (cache hints), 2025-11-25 e 2025-06-18; outputSchema nas tools estruturadas; schemas executados; erros JSON-RPC padronizados

Projeto e missões

Leitura segura de pastas permitidas e Git somente leitura; contexto anexado com máscara de segredos; missões assíncronas e em grafo; travas entre harnesses; log de auditoria

Roteamento

A MCP escolhe o modelo: faixa de custo primeiro e, dentro dela, o de melhor histórico para o tipo de tarefa; routing_explain e cost_estimate

Contas antes de API 4.3.0

Faixa account: CLIs oficiais que você já logou (Claude Code, Codex, Gemini CLI e outras) e gateways de conta como o OmniRoute entram antes das APIs por token, com custo 0; account_status mostra o que está logado (opt-in por DZ23_ACCOUNT_PROVIDERS)

Operação 4.2.0

Painel local somente leitura (dashboard); validação de patch em cópia isolada (patch_validate, desligada por padrão)

Transporte

stdio; HTTP JSON opcional (desligado por padrão), sem SSE/sessões/OAuth. HTTP é token-based; OAuth 2.1/OIDC (spec 2026-07-28) não está implementado — para enterprise, use um gateway autenticado na frente do servidor

Segurança HTTP

Token por variável ou arquivo, escopos por token, Host/Origin, rate limit e limites por processo

Delegação

OpenAI-compatible e Anthropic Messages; retry limitado; failover; cooldown por tipo de erro

Roteamento

first, round_robin, diversidade de provider/modelo, custo e latência, com diversidade observada

Consenso

Revisores em alvos distintos e síntese heurística rotulada como não verificada

Custos

Limites de tokens, chamadas e custo por chamada/missão/projeto/dia; preços só por tabela explícita

Providers

Inventário com flags de configuração, catálogo e inferência verificada; verify_model

Memória

Schema versionado, integridade, locks com dono, journal com sequência, contexto em camadas, reparo

Operação

Logs JSONL redigidos, métricas de processo, CLI (doctor, providers, missions, memory repair...)

Não entregue esta prévia como um SaaS multitenant ou como execução autônoma completa de projetos. Limites, contadores e orçamento são por processo. Veja Arquitetura. O nome Universal descreve o objetivo de portabilidade; não é certificação de compatibilidade com todos os hosts.

Começar no computador

Clone o repositório e, na pasta do projeto:

node --version
npm run check
npm test
node scripts/install-harness.mjs all
node src/index.js doctor

Não é necessário npm install: o código usa apenas módulos nativos do Node.js 22+. O campo private: true em package.json só impede publicação acidental no npm.

Linux/macOS: bash scripts/install-local.sh cria .env se ausente, preserva uma configuração existente, executa a regressão e gera snippets.

Windows (PowerShell): powershell -ExecutionPolicy Bypass -File scripts\install-windows.ps1 realiza as mesmas etapas.

Já tem 2.2.x ou 3.0.0 instalado? Siga o roteiro de atualização: levantar o ambiente e o diretório de estado de cada harness, backup completo, pasta nova, revisão do .env, config validate/doctor e substituição das entradas nos harnesses.

O repositório contém somente .env.example, com todos os provedores cadastrados (chave vazia) e todas as variáveis suportadas: copie para .env e preencha só as chaves que tiver. O processo lê o .env da instalação, não o do projeto do harness. Exemplo inicial com um servidor local que você precisa iniciar:

DZ23_ROTATION=custom:qwen3-coder
CUSTOM_BASE_URL=http://127.0.0.1:11434/v1
CUSTOM_MODEL=qwen3-coder
DZ23_ALLOW_PAID=false

Para nuvem: configure a chave em privado, rode discover_models, confirme com verify_model (confirm_billable: true) e só então acrescente provider:model à rotação.

Qualquer API, sem editar código

Provedor fora do catálogo entra pelo próprio .env — qualquer endpoint compatível com OpenAI ou Anthropic:

DZ23_PROVIDERS=minhaapi
DZ23_MINHAAPI_BASE_URL=https://api.exemplo.com/v1
DZ23_MINHAAPI_API_KEY=sk-...
DZ23_MINHAAPI_MODEL=modelo-padrao
DZ23_MINHAAPI_PROTOCOL=openai     # ou anthropic
DZ23_MINHAAPI_TIER=mixed          # paid | low-cost | mixed | free-tier | local
DZ23_ROTATION=minhaapi:modelo-padrao

Dá para declarar quantos quiser (DZ23_PROVIDERS=a,b,c), cada um com seu protocolo, tier e modelo. TIER=local dispensa chave e aceita HTTP em loopback/rede privada. Detalhes e exemplos em docs/PROVIDERS_QUALQUER_API.md.

Custos e orçamento

free-first apenas ordena categorias. DZ23_ALLOW_PAID=false bloqueia paid e low-cost, inclusive alvos explícitos e, sem DZ23_ROTATION, modelos que não sejam o padrão do provider. Também bloqueia mixed (OpenRouter, Gemini, Mistral, Together, Ollama cloud e outros que cobram alguns modelos), exceto provider:modelo listados em DZ23_FREE_MODELS ou modelos :free do OpenRouter: declare ali só modelos realmente gratuitos na sua conta. Modelos :cloud servidos por um Ollama local também contam como mixed, e free-tier pode cobrar acima da cota grátis. doctor mostra cada alvo como eligible ou skipped(motivo). Para limitar gasto, defina uma tabela de preços (DZ23_PRICES_FILE) e limites como DZ23_MAX_DAILY_COST_USD, DZ23_MAX_MISSION_COST_USD ou DZ23_MAX_MISSION_CALLS; com limite de custo, chamadas de custo desconhecido são negadas por padrão (DZ23_COST_POLICY). O orçamento é verificado antes de cada chamada, inclusive retries, revisores e health_check. health_check e verify_model exigem confirm_billable: true. Preços nunca são inventados: sem tabela, o custo aparece como unknown. Configure também limites de gasto no fornecedor. Detalhes em Operação.

Conectar o harness

node scripts/install-harness.mjs all gera snippets para revisão, sem editar as configurações existentes de Claude/Codex:

config/generated/claude_code_add_command.txt
config/generated/codex_config.snippet.toml
config/generated/claude_desktop_config.snippet.json
  • Claude Code: rode o comando de claude_code_add_command.txt (claude mcp add -s user dz23-subagents -- ...) e confira com claude mcp get dz23-subagents.

  • Codex: substitua a tabela [mcp_servers.dz23-subagents] de ~/.codex/config.toml pelo snippet, que inclui startup_timeout_sec = 30 e tool_timeout_sec = 900; nunca crie uma segunda tabela.

  • Hermes e outros clientes precisam mapear command, args e transporte stdio ao próprio formato.

Ao atualizar, substitua a entrada existente em cada harness; não mantenha duas. Guia completo · Prompt para o harness

CLI operacional

node src/index.js doctor --json
node src/index.js config validate
node src/index.js providers
node src/index.js missions list
node src/index.js memory repair
node src/index.js health --yes

Nenhum comando imprime segredos; health exige --yes porque pode cobrar e memory repair --apply exige --yes. Códigos de saída: 0, 1, 2 e 78.

Exemplo de uso pela IA

Use o MCP dz23-subagents. Registre o projeto minha-app e a missão m-001. Consulte o inventário sem expor segredos. Delegue análises de backend, frontend e QA com swarm_run, estratégia provider_diversity, limite de três agentes. Revise as propostas antes de editar arquivos. Execute os testes localmente. Salve decisões, critérios e o próximo passo com memory_checkpoint.

Outro harness conecta à mesma memória, chama mission_status com os mesmos IDs, confere Git/arquivos/testes por conta própria e continua.

Testes e publicação

npm run check
npm test
npm run check:release
npm run check:public

CI roda lint, testes em Linux/Windows com Node 22/24, contratos MCP por fixtures, relatório de cobertura e auditoria dos arquivos públicos. Os testes usam apenas fixtures locais, sem credenciais. Publicar no GitHub descreve a primeira publicação e as atualizações.

Contribuir

Leia CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md e ROADMAP. Relatórios devem separar fixtures, testes locais e validação real de provedores. Sem benchmarks comparativos, não alegamos que o produto seja mais rápido ou melhor que outros roteadores.

Licença

MIT, com o aviso de copyright DZ23 original preservado em LICENSE. As marcas dos clientes e provedores pertencem aos respectivos titulares; não há alegação de afiliação ou endosso. A licença do código não fornece créditos de API.

Available Tools

24 tools
account_statusAccount providers statusA
Read-onlyIdempotent

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.

Inputs: refresh.

consensusConsensus reviewA

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.

Inputs: prompt (required), detail, models, context, +13 more.

cost_estimateEstimate call costA
Read-onlyIdempotent

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.

Inputs: tool, roles, models, prompt, +4 more.

delegateDelegate advisory taskA

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.

Inputs: prompt (required), goal, role, cache, +12 more.

discover_modelsDiscover modelsA
Read-only

Query provider /models catalogs (cached five minutes). A catalog entry does not prove inference access.

Inputs: refresh, provider, cache_only.

handoff_exportExport mission handoffA
Read-onlyIdempotent

Return a compact Markdown briefing for another harness.

Inputs: mission_id (required), project_id (required).

health_checkHealth check (billable)A

Run a tiny real generation on every eligible target in parallel. Requires confirm_billable=true; may consume provider quota or credits.

Inputs: confirm_billable (required).

list_modelsList routing targetsA
Read-onlyIdempotent

List configured, policy-eligible routing targets with tier and adapter capabilities. No network calls.

Inputs: no named parameters.

memory_checkpointMemory 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.

Inputs: mission_id (required), project_id (required), goal, merge, +16 more.

mission_cancelCancel asynchronous missionA

Cancel a running or paused job. A finished job keeps its final status.

Inputs: job_id (required).

mission_claimClaim mission leaseA

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.

Inputs: identity (required), mission_id (required), project_id (required), lease_ms, +1 more.

mission_listList missionsB
Read-onlyIdempotent

Missions with status, goal, next action, loop/graph progress and resource URI. Same data as MCP resources, for harnesses without resources support.

Inputs: limit, cursor, project_id.

mission_pausePause asynchronous missionA

Request a pause; the job stops after the current iteration and can be resumed.

Inputs: job_id (required).

mission_releaseRelease mission leaseA

Release a lease with the token returned by mission_claim.

Inputs: token (required), mission_id (required), project_id (required), identity.

mission_resumeResume asynchronous missionA

Resume a paused job as a new job_id with the same goal, roles, criteria and remaining iterations.

Inputs: job_id (required).

mission_startStart asynchronous missionA

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.

Inputs: goal (required), plan, roles, mission_id, +6 more.

mission_statusMission statusB
Read-onlyIdempotent

Read mission state and recent journal events. Agent outputs are returned as short previews unless include_outputs=true.

Inputs: mission_id (required), project_id (required), events_limit, include_outputs.

mission_status_jobAsynchronous mission statusA
Read-onlyIdempotent

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.

Inputs: job_id (required), mission_id, project_id.

playbook_getGet playbookA
Read-onlyIdempotent

Without name: list the playbooks (the MCP prompts). With name and arguments: the rendered instructions. For harnesses without MCP prompts support.

Inputs: name, arguments.

project_initInitialize project memoryA
Idempotent

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.

Inputs: project_id (required), branch, workspace, repository.

provider_inventoryProvider inventoryA
Read-onlyIdempotent

Inventory every registered provider with configuration status and credential source, never credential values. No network calls.

Inputs: no named parameters.

routing_explainExplain model routingA
Read-onlyIdempotent

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.

Inputs: role, target, task_type.

swarm_runParallel specialist swarmA

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.

Inputs: goal (required), roles, detail, context, +15 more.

verify_modelVerify model inference (billable)A

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.

Inputs: target (required), confirm_billable (required), timeout_ms, max_output_tokens.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 24 tools

    Disambiguation3/5

    Most tools have distinct roles across missions, delegation, model routing, providers, and costs. However, mission_status vs. mission_status_job, mission_list vs. mission_status, and discover_models vs. list_models/provider_inventory/routing_explain overlap enough to cause hesitation. Descriptions help, but an agent must read carefully to choose correctly.

    Naming Consistency3/5

    All names use snake_case and the mission_* prefix helps group lifecycle tools, but the conventions are mixed: verb_noun (verify_model, list_models, cost_estimate), noun_verb (playbook_get, mission_resume, memory_checkpoint), noun_noun (provider_inventory, health_check, account_status), and bare verbs/nouns (delegate, consensus). The pairing of mission_status and mission_status_job is especially irregular. It remains readable, but not predictable.

    Tool Count3/5

    At 24 tools, the server is at the heavy end for its orchestration scope. Many tools are meaningful, but several could be consolidated (mission_status/mission_status_job, discover_models/list_models, verify_model/health_check). The count is borderline rather than clearly well-scoped.

    Completeness4/5

    The surface covers mission lifecycle, delegation patterns, model discovery and verification, routing explanation, provider inventory, cost estimation, project metadata, memory checkpoints, and handoff export. Minor gaps exist around cleanup/deletion of missions or projects and direct memory retrieval beyond status/journal events. These are workable omissions rather than dead ends.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      A local-first mission control for AI agent harnesses, providing a unified MCP gateway for shared memory, task queue, and encrypted secrets across multiple agents.
      2 npm
      2
      MIT
    • A
      license
      Not graded
      quality
      A
      maintenance
      Provides a provider-agnostic MCP server that coordinates structured multi-agent workflows, owning task claims, action logs, handoffs, and server-side health gates for coding agents. It enables tracked specs, tasks, reviews, and verified completion across Claude Code, Codex CLI, Cursor, Grok Build, and OpenCode.
      29 npm
      MIT
    • A
      license
      Not graded
      quality
      A
      maintenance
      Enables AI coding providers to run structured multi-agent workflows with document-backed specifications, tracked tasks, handoffs, health gates, and completion evidence. It exposes MCP tools for coordinating use cases, specs, implementation, review, and repair across supported providers.
      29 npm
      MIT