ArgoCD

Exponha toda a API do ArgoCD para LLMs via MCP usando apenas 2 ferramentas geradas automaticamente, alimentadas pela especificação OpenAPI.

Documentação

ArgoCD

argocd-mcp

Toda a API do ArgoCD, exposta a LLMs via MCP.
103+ endpoints. Zero handlers codificados. Dois modos: busca ou ferramentas geradas.

Início RápidoComo FuncionaOAuthOIDCConfiguração


A maioria dos servidores MCP do ArgoCD codifica algumas operações: listar aplicações, sincronizar, obter status. Quando o ArgoCD adiciona um novo recurso, você espera o mantenedor adicioná-lo.

argocd-mcp adota uma abordagem diferente, inspirada no servidor MCP da Cloudflare, que cobre 2500+ endpoints com apenas 2 ferramentas. Ele lê a especificação OpenAPI do ArgoCD na inicialização e expõe cada endpoint por meio de apenas 2 ferramentas: search e execute. Nova versão do ArgoCD? Reinicie o servidor. Pronto.

  • 103+ endpoints da especificação OpenAPI do ArgoCD, zero handlers codificados
  • Dois modos de ferramenta: search (2 meta-ferramentas) ou generated (1 ferramenta tipada por endpoint)
  • Funciona com Claude Desktop, Claude Code, Cursor ou qualquer cliente MCP
  • Sem código por endpoint — a especificação OpenAPI é a fonte da verdade
  • Três modos de autenticação: token estático, OAuth via ArgoCD Dex, ou OAuth via provedor OIDC externo que o ArgoCD confia (ambos fornecem RBAC por usuário)
  • Modo somente leitura — desative todas as operações de escrita com uma única flag
  • Escopo de recursos — restrinja quais recursos do ArgoCD são expostos com ALLOWED_RESOURCES
  • Limitação de taxa — token bucket por usuário para proteger o ArgoCD de chamadas excessivas
  • Modelos de prompt — fluxos de trabalho pré-empacotados para operações comuns (aplicações não saudáveis, diff, rollback, logs)
  • Registro de auditoria — logs JSON estruturados para cada chamada de ferramenta (usuário, método, caminho, status, duração)
  • Anotações MCP — ferramentas anotadas como somente leitura, destrutivas ou idempotentes para categorização adequada no cliente
  • Busca semântica opcional via embeddings Ollama

Como Funciona

Na inicialização, o servidor busca a especificação Swagger do ArgoCD e analisa cada endpoint. Em seguida, expõe-os a LLMs por meio de um dos dois modos:

Modo de busca (padrão, TOOL_MODE=search)

Duas meta-ferramentas lidam com todos os 103+ endpoints. O LLM descobre endpoints pesquisando e depois os chama por meio de um executor genérico.

graph TD
    A[ArgoCD /swagger.json] -->|Fetch at startup| B[Parse Swagger 2.0]
    B --> C[103+ Endpoints in memory]
    C --> D[search_operations]
    C --> E[execute_operation]
    D -->|LLM discovers endpoints| F[Returns method, path, summary, params]
    E -->|LLM calls API| G[Proxies to ArgoCD with user token]

Modo gerado (TOOL_MODE=generated)

Uma ferramenta MCP tipada por endpoint, gerada dinamicamente na inicialização. O LLM chama argocd_application_sync(name, revision) diretamente — sem etapa de busca, sem construção de caminho.

graph TD
    A[ArgoCD /swagger.json] -->|Fetch at startup| B[Parse Swagger 2.0]
    B --> C[103+ Endpoints]
    C -->|Generate per endpoint| D[argocd_application_list]
    C --> E[argocd_application_sync]
    C --> F[argocd_cluster_get]
    C --> G[... 100+ more tools]
    D & E & F & G -->|Typed params, 1 call| H[Proxies to ArgoCD]

Qual modo escolher?

BuscaGerado
Ferramentas registradas2103+
Round-trips do LLM2 (busca → execução)1 (chamada direta)
Tipagem de parâmetrosStrings JSON brutasParâmetros individuais tipados
Uso de contextoBaixo (~200 tokens)Maior (mitigado pelo carregamento adiado do cliente)
Melhor paraClientes leves, contexto limitadoClaude Code, Claude Desktop, Cursor

Clientes como Claude Code e Claude Desktop suportam carregamento adiado de ferramentas — eles só carregam definições de ferramentas no contexto quando necessário, então as 103+ ferramentas não consomem a janela de contexto antecipadamente.


Início Rápido

Helm Chart (Kubernetes)

helm install argocd-mcp oci://ghcr.io/matthisholleville/charts/argocd-mcp \
  --set argocd.baseURL=https://argocd.example.com \
  --set argocd.token=your-token

Veja todas as opções de configuração em charts/argocd-mcp/values.yaml.

Token Estático (simples)

Melhor para desenvolvimento local, CI/CD ou configurações de usuário único. Usa um token de API estático do ArgoCD.

Claude Code

claude mcp add argocd -s user -- \
  docker run --rm -i \
  -e ARGOCD_BASE_URL=https://argocd.example.com \
  -e ARGOCD_TOKEN=your-token \
  ghcr.io/matthisholleville/argocd-mcp:latest

Claude Desktop

Adicione ao seu config MCP do Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "argocd": {
      "command": "docker",
      "args": ["run", "--rm", "-i",
        "-e", "ARGOCD_BASE_URL=https://argocd.example.com",
        "-e", "ARGOCD_TOKEN=your-token",
        "ghcr.io/matthisholleville/argocd-mcp:latest"
      ]
    }
  }
}

OAuth via ArgoCD Dex (RBAC por usuário)

Melhor para configurações multiusuário e produção. Cada usuário autentica com sua própria identidade via Dex integrado do ArgoCD. Nenhum token estático necessário — o id_token do Dex do usuário é encaminhado ao ArgoCD, que aplica suas políticas RBAC por usuário.

Passo 1: Inicie o servidor

docker run -p 8080:8080 \
  -e ARGOCD_BASE_URL=https://argocd.example.com \
  -e MCP_TRANSPORT=http \
  -e AUTH_MODE=oauth \
  -e DEX_CLIENT_ID=argo-cd-cli \
  -e SERVER_BASE_URL=http://localhost:8080 \
  ghcr.io/matthisholleville/argocd-mcp:latest

Passo 2: Conecte seu cliente MCP

Claude Code

claude mcp add --transport http --callback-port 9382 argocd http://localhost:8080/mcp

Em seguida, execute /mcp dentro do Claude Code para autenticar via navegador.

Claude Desktop

O Claude Desktop requer uma URL publicamente acessível (o redirecionamento OAuth passa por claude.ai). Exponha o servidor via proxy reverso ou ngrok e defina SERVER_BASE_URL de acordo. No modo oidc, esse callback não é uma URL de loopback, então também precisa estar na lista de permissões: OIDC_ALLOWED_REDIRECT_URIS=https://claude.ai/api/mcp/auth_callback.

Adicione a URL pública como um servidor MCP remoto em Configurações > Conectores (ex.: https://mcp.example.com/mcp). O Claude Desktop lida com o fluxo OAuth automaticamente.

Requisito: configuração do Dex do ArgoCD

O cliente Dex argo-cd-cli precisa das URLs de callback dos seus clientes MCP registradas como URIs de redirecionamento. Adicione uma substituição de staticClients no seu dex.config do ArgoCD:

staticClients:
  - id: argo-cd-cli
    name: Argo CD CLI
    public: true
    redirectURIs:
      - http://localhost
      - http://localhost:8085/auth/callback
      - http://localhost:9382/callback
      - https://claude.ai/api/mcp/auth_callback
URI de redirecionamentoUsado por
http://localhostCLI do ArgoCD (argocd login --sso)
http://localhost:8085/auth/callbackCLI do ArgoCD (legado)
http://localhost:9382/callbackClaude Code (--callback-port 9382)
https://claude.ai/api/mcp/auth_callbackClaude Desktop

O ArgoCD registra automaticamente argo-cd-cli na inicialização e o antepõe à lista de clientes. O Dex usa a última definição quando há IDs duplicados, então nossa substituição vence com segurança (ref).

Nota: O cliente argo-cd-cli é público (sem segredo), então esta substituição é segura — ao contrário de substituir argo-cd, que tem um segredo interno (ref).

Como funciona nos bastidores:

  • O servidor MCP atua como um proxy OAuth para o Dex do ArgoCD
  • Usa o cliente público argo-cd-cli (sem necessidade de segredo)
  • O id_token do Dex (com aud: argo-cd-cli) é trocado no campo access_token e encaminhado como Bearer para o ArgoCD
  • O ArgoCD valida o token contra o JWKS do Dex e aplica RBAC por usuário
  • Cada usuário só vê as aplicações e recursos aos quais tem acesso

OAuth via provedor OIDC externo (sem Dex)

Para instâncias do ArgoCD configuradas com oidc.config em vez de dex.config: o ArgoCD fala diretamente com o provedor de identidade e não executa Dex, então /api/dex/* não responde nada e AUTH_MODE=oauth não consegue completar um fluxo. AUTH_MODE=oidc faz proxy para esse mesmo provedor, e o RBAC por usuário funciona exatamente como no modo Dex.

As duas configurações são mutuamente exclusivas no ArgoCD (oidc.config vence e o Dex nunca é servido), então escolha o modo que corresponde à sua instância:

ArgoCD temModoProvedor
dex.configoauthDex integrado do ArgoCD
oidc.configoidcseu IdP, diretamente
docker run -p 8080:8080 \
  -e ARGOCD_BASE_URL=https://argocd.example.com \
  -e MCP_TRANSPORT=http \
  -e AUTH_MODE=oidc \
  -e SERVER_BASE_URL=http://localhost:8080 \
  ghcr.io/matthisholleville/argocd-mcp:latest

Nenhum issuer ou client id é necessário: o servidor lê o próprio /api/v1/settings do ArgoCD na inicialização e usa o provedor que ele declara, preferindo cliClientID sobre clientID quando ambos estão definidos. Substitua com OIDC_ISSUER + OIDC_CLIENT_ID (ambos juntos) para apontar para outra coisa. A conexão do cliente é idêntica ao modo Dex.

Requisito: configuração do provedor de identidade

O client id deve ser um público que o ArgoCD aceita. O ArgoCD valida o aud do id_token recebido contra seu oidc.config clientID / cliClientID. Um token emitido para qualquer outro cliente é rejeitado com failed to verify the token, que é o motivo pelo qual o servidor usa como padrão o cliente que o próprio ArgoCD anuncia.

Registre uma URI de redirecionamento nessa aplicação:

{SERVER_BASE_URL}/oauth/callback

Clientes MCP vinculam uma porta de loopback que não pode ser pré-registrada. O Dex aceita qualquer redirecionamento de loopback para um cliente público (RFC 8252), que é o motivo pelo qual o modo oauth não precisa desse tratamento, mas a maioria dos provedores exige correspondência exata e o rejeitaria.

Então, no modo oidc, este servidor é o alvo de redirecionamento registrado: ele carrega o redirect_uri e o state do cliente através do parâmetro state upstream (assinado com HMAC, então nenhum deles pode ser adulterado no navegador) e depois retransmite o código de volta para o loopback que o cliente vinculou. Os callbacks do cliente não precisam de registro algum.

Como o provedor agora só vê o callback deste servidor, sua própria lista de permissões de URIs de redirecionamento não limita mais onde um código de autorização pode terminar, e este servidor precisa fazer isso sozinho. Ele aceita redirecionamentos de loopback (RFC 8252, o que os clientes MCP vinculam) e rejeita todo o resto; um cliente que chama de volta para uma URL pública fixa, ex.: https://claude.ai/api/mcp/auth_callback para a integração hospedada do claude.ai, precisa ser listado em OIDC_ALLOWED_REDIRECT_URIS. Somente a assinatura não seria suficiente: a assinatura prova que este servidor emitiu o estado, não que o destino é seguro.

Defina OIDC_PROXY_CALLBACK=false para passar o redirect_uri do cliente diretamente, para um provedor que tolera redirecionamentos de loopback. Cada callback do cliente então precisa ser registrado.

Clientes confidenciais: se a aplicação para a qual o ArgoCD aponta exigir um segredo de cliente (a maioria dos tipos de aplicação web exige), passe-o como OIDC_CLIENT_SECRET. Ele é adicionado no lado do servidor na troca de tokens, então os clientes MCP ainda se registram como públicos e nunca o veem. Clientes públicos/PKCE (ex.: uma aplicação registrada especificamente para uso CLI e referenciada pelo ArgoCD como cliClientID) não precisam de segredo.

Grupos para RBAC: o ArgoCD solicita a declaração de grupos por meio de seu próprio requestedIDTokenClaims. Provedores que só emitem uma declaração mediante solicitação precisam do mesmo deste servidor, caso contrário, todo usuário cai em policy.default:

-e OIDC_REQUESTED_ID_TOKEN_CLAIMS='{"id_token":{"groups":{"essential":true}}}'

Os escopos são obtidos do próprio requestedScopes do ArgoCD quando são descobertos, pois os provedores discordam sobre quais escopos existem (nem Entra ID nem Google Workspace têm groups). Eles caem para openid profile email groups quando o ArgoCD não declara nenhum, e OIDC_SCOPES substitui ambos. openid é obrigatório de qualquer forma: sem ele, o provedor não emite id_token, então a inicialização rejeita um conjunto de escopos que o omita e a troca de tokens falha com 502 em vez de entregar ao cliente um token opaco que daria 401 em toda chamada ao ArgoCD.

Observe que nenhum offline_access é solicitado, então não há token de atualização e os clientes reautenticam quando o id_token expira. Adicione-o por meio de OIDC_SCOPES para um provedor que o aceite.

Como funciona nos bastidores:

  • O servidor MCP atua como um proxy OAuth para o provedor, descoberto via {issuer}/.well-known/openid-configuration, cujo issuer deve corresponder ao solicitado
  • /oauth/callback é o alvo de redirecionamento do provedor e retransmite o código para o próprio callback do cliente, que é validado contra loopback mais OIDC_ALLOWED_REDIRECT_URIS
  • O id_token do provedor é trocado no campo access_token e encaminhado como Bearer para o ArgoCD
  • O ArgoCD valida contra o JWKS do provedor e aplica RBAC por usuário
  • A inicialização falha ruidosamente quando o ArgoCD anuncia uma configuração Dex em vez disso, apontando para AUTH_MODE=oauth
  • O estado do callback é assinado com uma chave por processo, a menos que OIDC_STATE_KEY esteja definido, então executar mais de uma réplica exige essa chave compartilhada

Busca Semântica (opcional)

Ative a busca vetorial com Ollama para melhores resultados em consultas de linguagem natural:

docker compose up --build -d  # Starts Ollama + argocd-mcp with embeddings

Defina EMBEDDINGS_ENABLED=true, OLLAMA_URL e EMBEDDINGS_MODEL (padrão para nomic-embed-text).


Modo Somente Leitura (opcional)

Defina DISABLE_WRITE=true para impedir qualquer ação disruptiva no seu cluster. Quando ativado:

  • Os endpoints de escrita estão ocultos — as operações POST, PUT, PATCH, DELETE são filtradas do índice de busca, para que o LLM nunca as descubra.
  • A execução de escrita é bloqueada — mesmo que um chamador monte manualmente uma requisição execute_operation com um método de escrita, ela é rejeitada.
  • As operações de leitura funcionam normalmenteGET, HEAD, OPTIONS não são afetadas.

Isso é ideal para ambientes de produção, demonstrações ou qualquer configuração em que você queira que LLMs observem, mas nunca modifiquem, seus recursos do ArgoCD.

# Claude Code
claude mcp add argocd -s user -- \
  docker run --rm -i \
  -e ARGOCD_BASE_URL=https://argocd.example.com \
  -e ARGOCD_TOKEN=your-token \
  -e DISABLE_WRITE=true \
  ghcr.io/matthisholleville/argocd-mcp:latest

Escopo de Recursos (opcional)

Defina ALLOWED_RESOURCES para restringir quais tipos de recursos do ArgoCD o LLM pode descobrir e chamar. Isso filtra tanto os resultados da busca quanto bloqueia a execução de endpoints fora do escopo.

# Only expose application and version endpoints
ALLOWED_RESOURCES=ApplicationService,VersionService

Combina com DISABLE_WRITE:

# Read-only access to applications only
DISABLE_WRITE=true
ALLOWED_RESOURCES=ApplicationService

Tags de recursos disponíveis (a partir da especificação OpenAPI do ArgoCD):

TagEndpoints
AccountService6
ApplicationService31
ApplicationSetService6
CertificateService3
ClusterService7
GPGKeyService4
NotificationService3
ProjectService12
RepoCredsService8
RepositoryService17
SessionService3
SettingsService2
VersionService1

A correspondência não diferencia maiúsculas de minúsculas (applicationservice funciona).


Modo de Ferramentas Geradas (opcional)

Defina TOOL_MODE=generated para criar uma ferramenta MCP por endpoint do ArgoCD na inicialização. Em vez de buscar e depois executar, o LLM chama diretamente ferramentas tipadas:

# Claude Code
claude mcp add argocd -s user -- \
  docker run --rm -i \
  -e ARGOCD_BASE_URL=https://argocd.example.com \
  -e ARGOCD_TOKEN=your-token \
  -e TOOL_MODE=generated \
  ghcr.io/matthisholleville/argocd-mcp:latest
Como funcionam as ferramentas geradas

O operationId de cada endpoint é convertido em um nome de ferramenta em snake_case com o prefixo argocd_:

operationIdNome da ferramenta
ApplicationService_Syncargocd_application_sync
ClusterService_Getargocd_cluster_get
ApplicationSetService_Listargocd_application_set_list

Os parâmetros são tipados individualmente — nenhum JSON bruto é necessário para casos comuns:

argocd_application_sync(
  name:      "frontend"      ← path param (required)
  revision:  "HEAD"          ← body param, flattened
  dryRun:    true            ← body param, flattened
  strategy:  '{"apply":{}}'  ← nested object stays JSON string
)

As ferramentas são anotadas com dicas MCP (readOnlyHint, destructiveHint, idempotentHint) para que clientes como o Claude Desktop as categorizem corretamente (leitura vs escrita/exclusão).

DISABLE_WRITE e ALLOWED_RESOURCES são aplicados na inicialização — ferramentas proibidas simplesmente não são geradas. O LLM não consegue nem vê-las.


Limitação de Taxa (opcional)

Proteja o ArgoCD de chamadas de API excessivas definindo RATE_LIMIT. Apenas execute_operation é limitado por taxa — a busca é local e não é afetada.

RATE_LIMIT=10              # 10 requests/sec per user
RATE_LIMIT_BURST=20        # allow short bursts up to 20
Como funciona a limitação de taxa

A limitação de taxa usa um token bucket por usuário. Cada usuário recebe um bucket que é reabastecido a RATE_LIMIT tokens por segundo, com um máximo de RATE_LIMIT_BURST tokens. Quando o bucket está vazio, as requisições são rejeitadas até que os tokens sejam reabastecidos.

Modo de autenticaçãoChave do bucketComportamento
OAuthEmail do usuário do JWTCada usuário tem um limite independente
Token estáticoChave compartilhada "static-token"Todos os clientes compartilham um bucket

Nota: No modo de token estático, um LLM agressivo pode privar outros clientes. Prefira o modo OAuth em configurações de produção multiusuário.

Quando uma requisição é limitada por taxa:

  • A chamada nunca chega ao ArgoCD — rejeitada antes do proxy
  • Uma entrada de log de auditoria é emitida com blocked: true
  • O LLM recebe um erro claro: "rate limit exceeded: too many requests, please slow down"

Se RATE_LIMIT_BURST não for definido, ele assume o valor de RATE_LIMIT. Defina RATE_LIMIT=0 (ou omita) para desabilitar completamente a limitação de taxa.


Modelos de Prompt

Fluxos de trabalho pré-empacotados para operações comuns do ArgoCD. Clientes MCP (Claude Desktop, Cursor) mostram esses prompts como selecionáveis em sua interface.

PromptDescriçãoArgumentos
unhealthy-appsEncontra todos os apps com saúde degradada ou status fora de sincronia
sync-statusVisão geral estilo dashboard de todos os apps
app-diffMostra o que mudaria na sincronizaçãoappName (obrigatório)
rollbackMostra o histórico e faz rollback para uma revisão anteriorappName (obrigatório)
app-logsBusca e analisa logs de contêinerappName (obrigatório), container (opcional)

Cada prompt guia o LLM por um fluxo de trabalho passo a passo usando search_operations e execute_operation. Nenhuma ferramenta adicional é necessária.


Log de Auditoria

O log de auditoria está habilitado por padrão. Cada chamada search_operations e execute_operation emite uma entrada de log JSON estruturada para o stderr:

{"time":"2026-03-22T10:00:00Z","level":"INFO","msg":"audit","tool":"execute_operation","method":"GET","path":"/api/v1/applications","blocked":false,"duration_ms":142,"status_code":200,"user":"alice@example.com"}

Cada entrada inclui:

  • toolsearch_operations ou execute_operation
  • user — email do token OAuth (vazio no modo de token estático)
  • method / path — a chamada de API do ArgoCD (execute) ou query (search)
  • status_code — código de resposta HTTP upstream
  • blockedtrue se a chamada foi rejeitada por DISABLE_WRITE ou ALLOWED_RESOURCES
  • duration_ms — tempo de ida e volta em milissegundos
  • error — mensagem de erro (registrada no nível ERROR quando presente)

Defina AUDIT_LOG=false para desabilitar.


Métricas

As métricas do Prometheus são expostas em GET /metrics sempre que MCP_TRANSPORT=http (não há superfície HTTP no modo stdio, então nada para coletar lá). Ao contrário do log de auditoria, as métricas estão sempre ativas e não podem ser desabilitadas: elas não carregam identidade de usuário, apenas um conjunto de rótulos limitado tool/status, então não há motivo de volume ou privacidade para desativá-las.

MétricaTipoRótulosDescrição
mcp_tool_calls_totalContadortool, statusTotal de chamadas de ferramentas. status é ok, blocked (rejeitado por DISABLE_WRITE, ALLOWED_RESOURCES ou RATE_LIMIT), ou error (uma chamada com falha, ou uma rejeitada durante a validação da requisição, ex., um parâmetro obrigatório ausente)
mcp_tool_duration_secondsHistogramatoolLatência de chamadas de ferramentas concluídas (a ida e volta até o ArgoCD). Chamadas com blocked e rejeitadas por validação nunca chegam ao ArgoCD e são intencionalmente excluídas — caso contrário, elas inflariam o histograma para perto de 0 e distorceriam p95/p99 da latência real, especialmente sob forte limitação de taxa. Com buckets de até 120s, operações lentas (syn​c, rollout) não colapsam em +Inf

tool é search_operations / execute_operation no modo de busca padrão, ou o nome da ferramenta gerada (ex., argocd_application_sync) em TOOL_MODE=generated.

curl http://localhost:8080/metrics | grep mcp_tool_
Exemplo de PromQL
# Call rate by tool, last 5 minutes
sum by (tool) (rate(mcp_tool_calls_total[5m]))

# p95 latency
histogram_quantile(0.95, sum by (le, tool) (rate(mcp_tool_duration_seconds_bucket[5m])))

# Error ratio
sum(rate(mcp_tool_calls_total{status="error"}[5m])) / sum(rate(mcp_tool_calls_total[5m]))

Configuração

VariávelObrigatóriaPadrãoDescrição
ARGOCD_BASE_URLSimURL do servidor ArgoCD
ARGOCD_TOKENQuando AUTH_MODE=tokenToken da API do ArgoCD
AUTH_MODENãotokentoken (estático), oauth (Dex do ArgoCD) ou oidc (provedor externo, sem Dex)
DEX_CLIENT_IDQuando AUTH_MODE=oauthargo-cd-cliID do cliente Dex
SERVER_BASE_URLQuando AUTH_MODE=oauth, ou oidc com OIDC_PROXY_CALLBACKhttp://localhost:8080 no modo oauth, nenhum no oidcURL pública deste servidor. No modo de proxy-callback oidc, é o URI de redirecionamento registrado no provedor, então não tem padrão e a inicialização falha sem ele
OIDC_ISSUERNãolido do ArgoCDURL do emissor do provedor. Defina junto com OIDC_CLIENT_ID
OIDC_CLIENT_IDNãolido do ArgoCDID do cliente. Deve ser uma audiência que o ArgoCD aceite
OIDC_CLIENT_SECRETPara clientes confidenciaisAdicionado no lado do servidor na troca de token
OIDC_SCOPESNãorequestedScopes do ArgoCD, senão openid profile email groupsEscopos separados por espaços. Deve incluir openid
OIDC_PROXY_CALLBACKNãotrueRegistre {SERVER_BASE_URL}/oauth/callback no provedor e repasse os códigos aos clientes, em vez de registrar o callback de cada cliente
OIDC_REQUESTED_ID_TOKEN_CLAIMSNãoParâmetro JSON claims da requisição, ex., {"id_token":{"groups":{"essential":true}}}
OIDC_ALLOWED_REDIRECT_URISNãoLista separada por vírgulas de valores de redirect_uri de clientes não-loopback a aceitar. Loopback é sempre aceito; qualquer outra coisa é rejeitada
OIDC_STATE_KEYCom mais de 1 réplicaSegredo compartilhado (mín. 32 caracteres) com o qual o estado do callback é assinado. Se não definido, gera uma chave por processo, que só funciona com uma única réplica
ARGOCD_SPEC_URLNão{base}/swagger.jsonSubstituir URL da especificação
MCP_TRANSPORTNãostdiostdio ou http
MCP_ADDRNão:8080Endereço de escuta HTTP
ARGOCD_TLS_INSECURENãofalsePular verificação de certificado TLS (defina true para certificados autoassinados)
TOOL_MODENãosearchsearch (2 meta-ferramentas) ou generated (1 ferramenta por endpoint)
DISABLE_WRITENãofalseBloquear todas as operações de escrita (POST, PUT, PATCH, DELETE)
ALLOWED_RESOURCESNãoLista separada por vírgulas de tags de recursos a expor (ex., ApplicationService,VersionService)
RATE_LIMITNão0 (desabilitado)Máx. de execute_operation requisições por segundo por usuário
RATE_LIMIT_BURSTNãoigual a RATE_LIMITTamanho máximo de rajada antes da limitação
AUDIT_LOGNãotrueLog de auditoria JSON estruturado para cada chamada de ferramenta
EMBEDDINGS_ENABLEDNãofalseHabilitar busca vetorial Ollama
OLLAMA_URLNãohttp://localhost:11434/apiURL da API Ollama
EMBEDDINGS_MODELNãonomic-embed-textModelo de embeddings Ollama

Compilar a partir do código-fonte

make build
ARGOCD_BASE_URL=https://argocd.example.com ARGOCD_TOKEN=xxx ./bin/argocd-mcp

Licença

MIT