Harness

oficial

Acesse e interaja com dados da plataforma Harness, incluindo pipelines, repositórios, logs e registros de artefatos.

GitHub

104

Experimente este MCPPatrocinado

O que você pode fazer com Harness MCP?

Listar recursos do Harness — Peça à sua IA para listar organizações, projetos, pipelines ou outros recursos usando harness_list.
Recuperar detalhes do recurso — Obtenha detalhes completos de qualquer recurso do Harness, como um pipeline ou serviço, via harness_get.
Criar novos recursos — Instrua sua IA a criar pipelines, serviços ou outras entidades com harness_create.
Descoberta entre projetos — Peça execuções ou recursos com falha em todos os projetos; o agente navega dinamicamente pela hierarquia da conta.
Autenticação multiusuário — Em implantações compartilhadas, cada sessão pode autenticar com sua própria chave de API do Harness via cabeçalho x-harness-api-key.

Documentação

Servidor MCP Harness 2.0

Um servidor MCP (Model Context Protocol) que dá aos agentes de IA acesso completo à plataforma Harness.io por meio de 11 ferramentas consolidadas e 255 tipos de recursos.

Por que usar este servidor MCP

A maioria dos servidores MCP mapeia uma ferramenta por endpoint de API. Para uma plataforma tão ampla quanto a Harness, isso significa mais de 240 ferramentas — e os LLMs pioram na seleção de ferramentas à medida que a quantidade aumenta. As janelas de contexto ficam cheias de esquemas, e cada novo endpoint significa novo código.

Este servidor é construído de forma diferente:

11 ferramentas, 255 tipos de recursos. Um sistema de despacho baseado em registro roteia harness_list, harness_get, harness_create, etc. para qualquer recurso da Harness — pipelines, serviços, ambientes, organizações, projetos, feature flags, dados de custo e muito mais. O LLM escolhe entre 11 ferramentas em vez de centenas.
Cobertura completa da plataforma. 41 conjuntos de ferramentas padrão abrangendo CI/CD, GitOps, Feature Flags, Gerenciamento de Custos na Nuvem, Testes de Segurança, Engenharia de Caos, DevOps de Banco de Dados, Portal Interno de Desenvolvedores, Cadeia de Suprimentos de Software, Gerenciamento de Infraestrutura como Código, Gerenciamento de Releases, Governança, Substituições de Serviço, Grafo de Conhecimento e muito mais. Cobertura opcional de Ansible e avaliação de observabilidade está disponível quando necessário.
Fluxos de trabalho multi-projeto prontos para uso. Os agentes descobrem organizações e projetos dinamicamente — sem necessidade de variáveis de ambiente codificadas. Pergunte "mostrar execuções com falha em todos os projetos" e o agente pode navegar por toda a hierarquia da conta.
35 modelos de prompt. Prompts pré-construídos para fluxos de trabalho comuns: construir e implantar aplicativos de ponta a ponta, depurar pipelines com falha, revisar métricas DORA, triar vulnerabilidades, otimizar custos na nuvem, auditar controle de acesso, planejar lançamentos de feature flags, revisar pull requests, aprovar pipelines pendentes e muito mais.
Funciona em qualquer lugar. Transporte Stdio para clientes locais (Claude Desktop, Cursor, Devin Desktop), transporte HTTP para implantações remotas/compartilhadas, pronto para Docker e Kubernetes.
Início sem configuração. Basta fornecer uma chave de API da Harness. O ID da conta é extraído automaticamente de tokens PAT e SAT, os padrões de organização/projeto são opcionais e a filtragem de conjuntos de ferramentas permite expor apenas o que você precisa.
Extensível por design. Adicionar um novo recurso da Harness significa adicionar um arquivo de dados declarativo — sem novo registro de ferramenta, sem alterações de esquema, sem atualizações de prompt.

Pré-requisitos

Antes de instalar ou executar o servidor, você precisa de uma chave de API da Harness:

Faça login na sua conta Harness
Vá para Meu Perfil → Chaves de API → + Nova Chave de API
Crie um novo Token sob a chave de API — isso gera um PAT ou SAT no formato <prefix>.<accountId>.<tokenId>.<secret>
Salve o token em um local seguro — você precisará dele na próxima etapa

Para instruções detalhadas, consulte o Início Rápido da API Harness.

Início Rápido

Opção 0: MCP Harness Hospedado

Se sua conta Harness tiver o serviço MCP hospedado habilitado, os clientes que suportam servidores MCP remotos podem se conectar diretamente ao endpoint gerenciado em vez de executar o servidor localmente.

Importante: O serviço MCP hospedado usa OAuth da Plataforma Harness, não HARNESS_API_KEY. Ele também deve ser habilitado/configurado por conta pelo Suporte Harness antes que o endpoint possa ser usado.

Consulte MCP Harness Hospedado para exemplos de configuração.

Opção 1: npx (Recomendado)

Sem instalação necessária — basta executar:

HARNESS_API_KEY=pat.xxx.xxx.xxx npx harness-mcp-v2@latest

Ou configure a chave de API no seu cliente de IA (consulte Configuração do Cliente abaixo).

# Stdio transport (default — for Claude Desktop, Cursor, Devin Desktop, etc.)
HARNESS_API_KEY=pat.xxx npx harness-mcp-v2

# HTTP transport (for remote/shared deployments)
HARNESS_API_KEY=pat.xxx npx harness-mcp-v2 http --port 8080

Nota: O ID da conta é extraído automaticamente de tokens PAT e SAT (pat.<accountId>... ou sat.<accountId>...), então HARNESS_ACCOUNT_ID só é necessário para chaves de API sem um segmento de conta embutido.

Opção 2: Instalação Global

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Opção 3: Compilar a partir do Código Fonte

Para desenvolvimento ou personalização:

git clone https://github.com/harness/mcp-server.git
cd mcp-server
pnpm install
pnpm build

# Run
pnpm start              # Stdio transport
pnpm start:http         # HTTP transport
pnpm inspect            # Test with MCP Inspector

Pacote do Diretório MCP da Anthropic

O manifesto do pacote MCPB está em [mcp-directory/](mcp-directory/), e o ícone do pacote 512×512 é rastreado em [icon.png](icon.png) na raiz do repositório. O arquivo empacotado contém manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json no nível raiz e node_modules/ de produção.

Para manter o arquivo pequeno, compile pacotes MCPB a partir de um diretório de preparação:

pnpm prepare:mcpb

O diretório de preparação é gravado em dist/mcpb/ com dependências de produção instaladas a partir de npm-shrinkwrap.json usando o layout plano do npm. O CLI oficial fixado do MCPB valida e cria dist/harness-mcp-server-<version>.mcpb.

Tags de versão correspondentes a v*.*.* publicam esse pacote no Release correspondente do GitHub automaticamente. Para preencher um release existente sem republicar o npm, execute o workflow Release manualmente com sua entrada release_tag (por exemplo, v3.2.20). O workflow faz checkout e compila essa tag exata antes de substituir apenas seu ativo MCPB versionado.

Uso via CLI

harness-mcp-v2 [stdio|http] [--port <number>]

Options:
  --port <number>  Port for HTTP transport (default: 3000, or PORT env var)
  --help           Show help message and exit
  --version        Print version and exit

O transporte padrão é stdio se não for especificado. Use http para implantações remotas/compartilhadas.

Transporte HTTP

Ao executar em modo HTTP, o servidor expõe:

Endpoint	Método	Descrição
`/mcp`	`POST`	Endpoint MCP JSON-RPC (solicitações de inicialização + sessão)
`/mcp`	`GET`	Stream SSE para mensagens iniciadas pelo servidor (progresso, elicitação)
`/mcp`	`DELETE`	Encerrar uma sessão MCP ativa
`/mcp`	`OPTIONS`	Preflight CORS
`/health`	`GET`	Verificação de saúde — retorna `{ "status": "ok", "sessions": <count> }`
`/.well-known/oauth-protected-resource`	`GET`	Metadados RFC 9728 quando `HARNESS_MCP_MODE=oauth`
`/.well-known/oauth-protected-resource/mcp`	`GET`	Metadados RFC 9728 cientes de caminho para o recurso padrão `/mcp`

O transporte HTTP opera em modo baseado em sessão. Uma nova sessão MCP é criada em initialize, o servidor retorna um cabeçalho mcp-session-id, e solicitações subsequentes para essa sessão devem incluir o mesmo cabeçalho.

Restrições operacionais no modo HTTP:

Defina HARNESS_MCP_AUTH_TOKEN para implantações compartilhadas ou remotamente acessíveis de usuário único e multi-usuário. Quando definido, toda solicitação POST, GET e DELETE para /mcp deve incluir Authorization: Bearer <token>.
O modo OAuth aceita tokens de acesso HarnessID em vez de HARNESS_MCP_AUTH_TOKEN e pode vincular a um endereço não-loopback sem a exclusão não autenticada.
Vínculos não-loopback de usuário único e multi-usuário exigem HARNESS_MCP_AUTH_TOKEN por padrão. Para executar não autenticado em uma interface não-loopback mesmo assim, defina HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true explicitamente.
POST /mcp sem mcp-session-id deve ser uma solicitação initialize.
POST /mcp, GET /mcp e DELETE /mcp para sessões existentes exigem o cabeçalho mcp-session-id.
GET /mcp é usado para notificações SSE (atualizações de progresso e prompts de elicitação).
Sessões ociosas são removidas após MCP_SESSION_TTL_MS milissegundos quando nenhuma solicitação ou stream SSE está ativo (padrão 1800000, ou 30 minutos).
GET /health é o único endpoint não-MCP.
O tamanho do corpo da solicitação é limitado por HARNESS_MAX_BODY_SIZE_MB (padrão 10 MB).
Defina x-harness-pipeline-version: 0 ou 1 na solicitação initialize para selecionar recursos de pipeline V0 ou V1 para essa sessão HTTP.
Defina x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all na solicitação initialize para escolher um limite de aprovação automática por sessão mais rigoroso. O servidor limita esse valor ao HARNESS_AUTO_APPROVE_RISK no nível de implantação, então uma sessão pode reduzir, mas não expandir, o teto de aprovação configurado.

Modo OAuth HarnessID

Defina HARNESS_MCP_MODE=oauth para permitir que clientes MCP remotos descubram o HarnessID e concluam o Código de Autorização OAuth 2.1 com PKCE. O modo OAuth está disponível apenas com transporte HTTP. Os padrões de produção do HarnessID, recurso MCP e roteamento de API estão embutidos:

HARNESS_MCP_MODE=oauth

Isso usa como padrão o emissor https://id.harness.io/idp/realms/HarnessIDP, recurso https://mcp.harness.io/mcp, cliente OAuth mcp-client e base da API Harness https://mcp.harness.io/cli. Substitua-os apenas para QA, desenvolvimento local ou outro ambiente Harness.

HARNESS_API_KEY não deve ser definido neste modo. HARNESS_MCP_OAUTH_JWKS_URI usa como padrão <issuer>/protocol/openid-connect/certs, e HARNESS_ACCOUNT_ID é desnecessário porque a conta vem do token.

O servidor publica metadados de recurso protegido RFC 9728 e retorna este desafio quando um cliente não autenticou:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.harness.io/.well-known/oauth-protected-resource/mcp"

Ele valida a assinatura RS256 do token de acesso HarnessID, iss, expiração e sub usando o endpoint JWKS configurado, e verifica se o token foi emitido para HARNESS_MCP_OAUTH_CLIENT_ID por meio da declaração azp. HARNESS_MCP_OAUTH_RESOURCE é o identificador de recurso protegido RFC 9728 usado para descoberta e desafios. Os tokens de acesso HarnessID atuais usam aud: account em vez da URL MCP, então o recurso não é comparado com aud.

O ID da conta vem da declaração HARNESS_MCP_OAUTH_ACCOUNT_CLAIM do token (account_id por padrão), que o escopo organization do HarnessID preenche. Cada sessão armazena o token de acesso do chamador e o encaminha para a API Harness como Authorization: Bearer, então o RBAC da Harness e os registros de auditoria refletem o usuário conectado em vez de um PAT compartilhado. A sessão está vinculada ao sub e à conta com a qual foi criada: uma solicitação posterior pode carregar um token atualizado, mas um para um usuário ou conta diferente é rejeitado.

Os clientes normalmente precisam apenas da URL do recurso MCP:

{
  "mcpServers": {
    "harness": {
      "url": "https://mcp.harness.io/mcp"
    }
  }
}

O cliente lê os metadados do recurso protegido, descobre HARNESS_MCP_OAUTH_ISSUER e então usa os metadados RFC 8414 desse servidor de autorização. Se o cliente não suportar registro dinâmico de cliente, use o ID de cliente pré-registrado mcp-client.

Consulte OAuth HarnessID para um servidor MCP auto-hospedado para a lista de verificação do Keycloak de QA e comandos de validação.

Modo Multi-Usuário

Defina HARNESS_MCP_MODE=multi-user para implantações HTTP compartilhadas onde cada cliente autentica como um usuário Harness diferente. Neste modo:

HARNESS_API_KEY não deve ser definido na configuração do servidor — o servidor não mantém credenciais Harness.
Cada sessão deve fornecer x-harness-api-key na solicitação initialize. x-harness-account-id é necessário apenas quando a chave de API não incorpora um segmento de conta.
As sessões também podem fornecer cabeçalhos x-harness-org e x-harness-project para definir o escopo padrão dessa sessão.
A chave de API Harness flui para cada chamada de API Harness dessa sessão, então a trilha de auditoria na Harness reflete o usuário real.
HARNESS_MCP_AUTH_TOKEN é independente e ainda pode ser usado como uma camada adicional de gate de transporte.

# Health check
curl http://localhost:3000/health

# MCP initialize request (capture mcp-session-id response header)
# In multi-user mode, x-harness-api-key is required on initialize.
# x-harness-account-id is needed only for API keys without an embedded account segment.
curl -i -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "x-harness-api-key: $HARNESS_API_KEY" \
  -H "x-harness-account-id: $HARNESS_ACCOUNT_ID" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

# Subsequent MCP request (use returned session ID)
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "mcp-session-id: <session-id>" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

# Terminate session
curl -X DELETE http://localhost:3000/mcp \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "mcp-session-id: <session-id>"

HARNESS_MCP_ALLOWED_HOSTS controla a validação do cabeçalho Host para proteção contra rebinding de DNS, e o CORS limita origens de navegador. Nenhum deles é autenticação; use HARNESS_MCP_AUTH_TOKEN ou um gateway/proxy reverso autenticado para controle de acesso.

Configuração do Cliente

Nota: HARNESS_ORG e HARNESS_PROJECT são opcionais. Eles definem o ID da organização e o ID do projeto usados quando não especificados por chamada de ferramenta. Os agentes podem descobrir organizações e projetos dinamicamente usando harness_list(resource_type="organization") e harness_list(resource_type="project"). Os nomes obsoletos HARNESS_DEFAULT_ORG_ID e HARNESS_DEFAULT_PROJECT_ID ainda são aceitos para compatibilidade retroativa.

MCP Harness Hospedado

A Harness também suporta um endpoint MCP hospedado para contas que têm o serviço gerenciado habilitado. Isso é útil quando você quer um endpoint MCP remoto compartilhado em vez de executar npx harness-mcp-v2 ou auto-hospedar o transporte HTTP você mesmo.

Importante: A autenticação MCP hospedada usa Harness Platform OAuth. Ela não usa HARNESS_API_KEY na configuração do cliente. A disponibilidade do MCP hospedado é configurada por conta Harness, então você precisará trabalhar com o Suporte Harness para habilitar/configurar a configuração antes de usá-lo.

O endpoint hospedado https://mcp.harness.io/mcp é um serviço gerenciado. A configuração MCP do lado do cliente em Claude, Cursor ou Cowork não pode substituir para qual ambiente Harness ele roteia. Para Harness0 ou outro ambiente Harness SaaS privado, peça ao Suporte Harness para habilitar/configurar o MCP hospedado para esse ambiente, ou execute o servidor local/self-hosted e defina HARNESS_BASE_URL para o host Harness de destino.

Exemplo de MCP hospedado:

{
  "mcpServers": {
    "harness-prod1-mcp": {
      "url": "https://mcp.harness.io/mcp",
      "auth": {
        "CLIENT_ID": "mcp-client"
      }
    }
  }
}

Exemplo com entradas hospedadas e locais:

{
  "mcpServers": {
    "harness-hosted": {
      "url": "https://mcp.harness.io/mcp",
      "auth": {
        "CLIENT_ID": "mcp-client"
      }
    },
    "harness-local": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Solução de problemas npx ENOENT ou node: No such file or directory

Isso é uma falha de inicialização do processo do cliente, não uma falha de autenticação Harness. O servidor MCP ainda não foi iniciado, então alterar HARNESS_API_KEY não afetará spawn npx ENOENT.

Aplicativos GUI (Cursor, Claude Desktop, Devin Desktop, VS Code) nem sempre herdam o PATH do seu shell, então eles podem falhar ao encontrar npx ou node após um recarregamento de configuração. Corrija isso usando caminhos absolutos e definindo explicitamente PATH no bloco env:
{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}
Encontre seus caminhos com which npx e which node em um terminal e, em seguida, certifique-se de que o diretório que contém node esteja incluído no valor PATH acima. Locais comuns:

Homebrew (macOS): /opt/homebrew/bin/npx

nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (execute nvm which current para encontrar o caminho exato)

Node do sistema: /usr/local/bin/npx

Claude Desktop (`claude_desktop_config.json`)

npx (instalação zero)

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

node (instalação local)

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Claude Code (via `claude mcp add`)

npx (instalação zero)

claude mcp add harness -- npx harness-mcp-v2

node (instalação local)

npm install -g harness-mcp-v2
claude mcp add harness -- harness-mcp-v2

Em seguida, defina HARNESS_API_KEY no seu ambiente ou arquivo .env.

Cursor (`.cursor/mcp.json`)

npx (instalação zero, recomendado para configurações locais do Cursor)

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Execute which npx em um terminal e use esse caminho completo para command; inclua o diretório de which node no início de PATH.

node (instalação local)

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Execute which harness-mcp-v2 após npm install -g harness-mcp-v2 e use esse caminho completo para command; inclua o diretório de which node no início de PATH.

Devin Desktop (`~/.windsurf/mcp.json`)

npx (instalação zero)

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

node (instalação local)

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Usando uma compilação local a partir do código-fonte?

Substitua o comando pelo caminho para o seu index.js compilado:

{
  "command": "node",
  "args": ["/absolute/path/to/harness-mcp-v2/build/index.js", "stdio"]
}

MCP Gateway

O servidor MCP Harness é totalmente compatível com MCP Gateways — proxies reversos que fornecem autenticação centralizada, governança, roteamento de ferramentas e observabilidade em vários servidores MCP. Como o servidor implementa o protocolo MCP padrão com transportes stdio e HTTP, ele funciona atrás de qualquer gateway compatível com MCP sem alterações de código.

Por que usar um gateway?

Gerenciamento centralizado de credenciais — sem chaves de API nas configurações do agente
Governança e registro de auditoria para todas as chamadas de ferramentas entre equipes
Endpoint único para agentes em vez de N conexões para N servidores MCP
Controle de acesso — restrinja quais equipes podem usar quais ferramentas

Docker MCP Gateway

Registre o servidor na sua configuração do Docker MCP Gateway:

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx"
      }
    }
  }
}

Portkey

Adicione o servidor MCP Harness ao seu Portkey MCP Gateway para governança empresarial, rastreamento de custos e roteamento multi-LLM:

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx"
      }
    }
  }
}

LiteLLM

Adicione à sua configuração de proxy LiteLLM:

mcp_servers:
  - name: harness
    command: npx
    args:
      - harness-mcp-v2
    env:
      HARNESS_API_KEY: "pat.xxx.xxx.xxx"

Envoy AI Gateway

O servidor funciona com o suporte MCP do Envoy AI Gateway via transporte HTTP:

# Start the server in HTTP mode
HARNESS_API_KEY=pat.xxx.xxx.xxx npx harness-mcp-v2 http --port 8080

Em seguida, configure o Envoy para rotear para http://localhost:8080/mcp como um backend MCP upstream.

Kong

Use o plugin AI MCP Proxy do Kong para expor o servidor MCP Harness através da sua infraestrutura de gateway Kong existente.

Outros Gateways

Qualquer gateway que suporte a especificação MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, etc.) pode fazer proxy deste servidor. Para gateways baseados em stdio, use o transporte padrão. Para gateways baseados em HTTP, inicie o servidor com transporte http e aponte o gateway para o endpoint /mcp.

Docker

Compile e execute o servidor como um contêiner Docker:

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

# Or run directly with env vars
docker run --rm -p 3000:3000 \
  -e HARNESS_API_KEY=pat.xxx.xxx.xxx \
  -e HARNESS_ACCOUNT_ID=your-account-id \
  harness-mcp-server

O contêiner executa em modo HTTP na porta 3000 por padrão com uma verificação de saúde integrada.

Kubernetes

Implante em um cluster Kubernetes usando os manifestos fornecidos:

# 1. Edit the Secret with your real credentials
#    k8s/secret.yaml — replace HARNESS_API_KEY and HARNESS_ACCOUNT_ID

# 2. Apply all manifests
kubectl apply -f k8s/

# 3. Verify the deployment
kubectl -n harness-mcp get pods

# 4. Port-forward for local testing
kubectl -n harness-mcp port-forward svc/harness-mcp-server 3000:80
curl http://localhost:3000/health

A implantação executa 2 réplicas com sondas de prontidão/atividade, limites de recursos e contexto de segurança não-root. O Service expõe a porta 80 internamente (direcionando para a porta 3000 do contêiner).

Configuração

O servidor carrega automaticamente variáveis de ambiente de um arquivo .env na raiz do projeto, se existir. Copie .env.example para .env e preencha seus valores. As variáveis de ambiente também podem ser definidas via seu shell ou configuração do cliente MCP.

Variável	Obrigatório	Padrão	Descrição
`HARNESS_MCP_MODE`	Não	`single-user`	Modo de implantação: `single-user` (chave de API compartilhada), `multi-user` (HTTP com chaves de API por sessão) ou `oauth` (HTTP com validação de token de acesso HarnessID)
`HARNESS_API_KEY`	Sim*	--	Token de acesso pessoal do Harness ou token de conta de serviço. Obrigatório no modo `single-user`. NÃO deve ser definido nos modos `multi-user` ou `oauth`, onde cada sessão traz sua própria credencial
`HARNESS_ACCOUNT_ID`	Não	(do PAT/SAT)	Identificador da conta Harness. Extraído automaticamente dos tokens PAT/SAT no modo de usuário único; sessões multiusuário podem fornecer o próprio via `x-harness-account-id` quando a chave de API não incorpora um
`HARNESS_BASE_URL`	Não	`https://app.harness.io` (`https://mcp.harness.io/cli` no modo OAuth)	URL base da API/interface do Harness. O modo OAuth roteia pelo proxy MCP `/cli` hospedado por padrão; outros modos usam a API SaaS do Harness diretamente
`HARNESS_MCP_OAUTH_ISSUER`	Não	`https://id.harness.io/idp/realms/HarnessIDP`	Emissor HarnessID correspondido exatamente contra a declaração `iss` do token de acesso
`HARNESS_MCP_OAUTH_RESOURCE`	Não	`https://mcp.harness.io/mcp`	URL pública canônica do MCP publicada como identificador de recurso RFC 9728
`HARNESS_MCP_OAUTH_JWKS_URI`	Não	`<issuer>/protocol/openid-connect/certs`	Endpoint JWKS do HarnessID usado para validar assinaturas de token de acesso RS256
`HARNESS_MCP_OAUTH_CLIENT_ID`	Não	`mcp-client`	Cliente HarnessID para o qual o token de acesso deve ser emitido, verificado contra a declaração `azp` do token
`HARNESS_MCP_OAUTH_ACCOUNT_CLAIM`	Não	`account_id`	Declaração do token de acesso que carrega o ID da conta Harness, preenchida pelo escopo `organization` do HarnessID
`HARNESS_MCP_OAUTH_SCOPES`	Não	`openid profile email organization`	Escopos separados por espaço anunciados nos metadados de recurso protegido RFC 9728
`HARNESS_FME_API_KEY`	Não	--	Credencial opcional de usuário único/autohospedado FME/Split Admin usada para recursos `fme_` somente no modo legado (`workspace_id`). O FME legado não está disponível no modo OAuth, portanto os tokens HarnessID nunca são enviados para `api.split.io`; use o escopo nativo do Harness `org_id`+`project_id` em vez disso. Não deve ser definido nos modos `multi-user` ou `oauth`
`HARNESS_FME_BASE_URL`	Não	`https://api.split.io`	URL base da API Admin Split/FME usada por recursos `fme_` somente no modo legado (`workspace_id`). URLs HTTP exigem `HARNESS_ALLOW_HTTP=true` para desenvolvimento local. O modo nativo do Harness (`org_id`+`project_id`) ignora isso e usa o padrão `HARNESS_API_KEY`/`HARNESS_BASE_URL` em vez disso
`HARNESS_ORG`	Não	--	ID da organização. Usado quando `org_id` não é especificado por chamada de ferramenta. Se omitido, `org_id` deve ser fornecido explicitamente. Agentes também podem descobrir organizações dinamicamente via `harness_list(resource_type="organization")`
`HARNESS_PROJECT`	Não	--	ID do projeto. Usado quando `project_id` não é especificado por chamada de ferramenta. Agentes também podem descobrir projetos dinamicamente via `harness_list(resource_type="project")`
`HARNESS_API_TIMEOUT_MS`	Não	`30000`	Tempo limite de solicitação HTTP em milissegundos
`HARNESS_MAX_RETRIES`	Não	`3`	Número de tentativas para falhas transitórias (429, 5xx)
`HARNESS_MAX_BODY_SIZE_MB`	Não	`10`	Tamanho máximo do corpo da solicitação HTTP em MB para transporte `http`
`HARNESS_RATE_LIMIT_RPS`	Não	`10`	Limitação de solicitações do lado do cliente (solicitações por segundo) para APIs do Harness
`LOG_LEVEL`	Não	`info`	Nível de verbosidade do log: `debug`, `info`, `warn`, `error`
`HARNESS_TOOLSETS`	Não	(padrões)	Lista de conjuntos de ferramentas separada por vírgulas. Vazio carrega os conjuntos de ferramentas padrão. Suporta `+name` para incluir explicitamente conjuntos de ferramentas opcionais e `-name` para remover padrões (veja Filtragem de Conjuntos de Ferramentas)
`HARNESS_READ_ONLY`	Não	`false`	Bloquear todas as operações de mutação (criar, atualizar, excluir, executar). Apenas listar e obter são permitidos. Útil para ambientes compartilhados/demonstração
`HARNESS_AUTO_APPROVE_RISK`	Não	`none`	Limite de aprovação automática baseado em risco para fluxos de trabalho autônomos. Operações com risco igual ou inferior a este prosseguem sem confirmação. Valores: `none`, `low_write`, `medium_write`, `high_write`, `all`. Veja Elicitação
`HARNESS_SKIP_ELICITATION`	Não	`false`	Obsoleto — use `HARNESS_AUTO_APPROVE_RISK=all` em vez disso. Mantido para compatibilidade retroativa
`HARNESS_ALLOW_HTTP`	Não	`false`	Permitir `HARNESS_BASE_URL` não HTTPS. Por padrão, o servidor impõe HTTPS por segurança. Defina como `true` apenas para desenvolvimento local contra uma instância Harness sem TLS
`HARNESS_PIPELINE_VERSION`	Não	`0`	(Alfa) Versão do YAML de pipeline. `0` carrega o tipo de recurso `pipeline` e exclui `pipeline_v1`; `1` carrega `pipeline_v1` e exclui `pipeline`. Sessões HTTP podem substituir isso no momento da inicialização com `x-harness-pipeline-version: 0` ou `1`
`HARNESS_MCP_ALLOWED_HOSTS`	Não	--	Nomes de host separados por vírgulas permitidos pela validação de cabeçalho Host do transporte HTTP. `mcp.harness.io` é permitido por padrão para binds de localhost; adicione domínios de proxy/personalizados aqui
`HARNESS_MCP_AUTH_TOKEN`	Não	--	Token Bearer estático exigido nas rotas HTTP `/mcp` quando definido. Obrigatório por padrão para binds de usuário único e multiusuário fora de loopback. Deve ser desdefinido no modo `oauth`
`HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP`	Não	`false`	Permitir explicitamente transporte HTTP não autenticado em binds fora de loopback. Use apenas atrás de outro controle autenticado
`HARNESS_MCP_TRUST_PROXY`	Não	`0`	Número de saltos de proxy reverso / balanceador de carga a confiar para resolução de IP do cliente (Express `trust proxy`). Defina para a contagem de proxies na frente do servidor para que a limitação de taxa por IP use o cliente real em vez do par de soquete do proxy
`HARNESS_MCP_LOG_FILE`	Não	`~/.claude/harness-mcp.log`	Arquivo usado para diagnósticos de desconexão/queda do stdio quando o stderr pode não estar mais disponível
`HARNESS_LOG_UNSAFE_BODIES`	Não	`false`	Incluir corpos brutos de solicitação/resposta nos logs. Desativado por padrão, pois os corpos podem conter segredos; ative apenas para depuração local
`HARNESS_AUDIT_FILE`	Não	--	Anexar eventos de auditoria a um arquivo JSON delimitado por nova linha para coleta local durável
`HARNESS_AUDIT_WEBHOOK_URL`	Não	--	Endpoint HTTPS que recebe eventos de auditoria em lote. URLs HTTP exigem `HARNESS_ALLOW_HTTP=true` para desenvolvimento local
`HARNESS_AUDIT_WEBHOOK_TOKEN`	Não	--	Token Bearer opcional enviado ao webhook de auditoria
`HARNESS_AUDIT_WEBHOOK_BATCH_SIZE`	Não	`10`	Número de eventos de auditoria a agrupar antes do flush do webhook
`HARNESS_AUDIT_WEBHOOK_FLUSH_MS`	Não	`5000`	Tempo máximo para reter eventos de auditoria antes do flush do webhook
`OTEL_EXPORTER_OTLP_ENDPOINT`	Não	--	Habilita spans de auditoria OpenTelemetry quando os pacotes opcionais OpenTelemetry estão instalados
`HARNESS_SEARCH_PROVIDER`	Não	`local`	Backend de busca semântica: `local` (embeddings ONNX em processo, padrão), `remote` (serviço de busca externo via HTTP, necessário para modo multi-usuário), ou `none` (desabilitar busca semântica, voltar apenas para scatter-gather por palavras-chave). Use `none` em ambientes isolados ou quando o carregamento do modelo na inicialização for indesejável
`HARNESS_SEARCH_SERVICE_URL`	Não	--	URL base do serviço de busca remoto quando `HARNESS_SEARCH_PROVIDER=remote` (ex.: `http://search-svc:8080`). Necessário ao usar o provedor `remote`
`HARNESS_SEARCH_SERVICE_HEADERS`	Não	--	Objeto JSON de cabeçalhos enviados com cada requisição ao serviço de busca remoto. Suporta qualquer esquema de autenticação: `{"Authorization":"Bearer tok"}`, `{"x-api-key":"key"}`, ou múltiplos cabeçalhos internos de serviço para serviço
`HARNESS_HF_CACHE_DIR`	Não	`/tmp/hf-cache`	Diretório para o cache do modelo `@huggingface/transformers` usado pelo provedor de busca `local`. A imagem Docker pré-carrega o modelo em `/app/.cache/hf` para evitar downloads em tempo de execução. Defina para um caminho de volume persistente em implantações de produção
`HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY`	Não	`3`	Máximo de downloads simultâneos de blobs de log emitidos por `harness_diagnose` ao buscar logs de etapas com falha. Aumente apenas se a latência de diagnóstico for dominada pelo tempo de parede da busca de logs e o pod tiver folga de memória

Pesquisa Semântica

harness_search usa roteamento semântico para reduzir chamadas de API do tipo scatter-gather antes de distribuí-las para o Harness. Três provedores de pesquisa estão disponíveis:

Provedor	Quando usar
`local` (padrão)	Modo stdio de usuário único. Executa `all-MiniLM-L6-v2` em processo via `@huggingface/transformers`. Baixa o modelo de ~23 MB no primeiro uso; execuções subsequentes usam o cache.
`remote`	Modo HTTP multiusuário (hospedado pelo Harness). Delega incorporação e recuperação a um serviço de pesquisa externo. O isolamento de locatário é aplicado via `tenant_id` — conhecimento/documentação estáticos usam `global`, dados de entidade por conta usam o ID da conta.
`none`	Desativa a pesquisa semântica completamente; volta para scatter-gather por palavras-chave em todos os tipos de recurso.

Configuração do provedor remoto:

HARNESS_SEARCH_PROVIDER=remote
HARNESS_SEARCH_SERVICE_URL=http://search-svc:8080

# Auth — any scheme via HARNESS_SEARCH_SERVICE_HEADERS (JSON object):
HARNESS_SEARCH_SERVICE_HEADERS='{"Authorization":"Bearer <token>"}'   # standard bearer
HARNESS_SEARCH_SERVICE_HEADERS='{"x-api-key":"<key>"}'               # API key header
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<svc-token>"}'   # internal service-to-service
# Multiple headers (e.g. service mesh + tenant routing):
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<tok>","x-tenant":"<id>"}'
# No auth (service mesh / mTLS handles it):
# omit HARNESS_SEARCH_SERVICE_HEADERS entirely

Testando o provedor remoto localmente com o serviço stub incluído (sem dependências externas):

# 1. Create a venv and install FastAPI
python3 -m venv .venv-stub
.venv-stub/bin/pip install fastapi uvicorn

# 2. Start the stub (in-memory, cosine similarity, corpus + tenant filtering)
.venv-stub/bin/uvicorn stub-search-service:app --port 8082

# 3. Build the MCP server
pnpm build

# 4. Run the integration smoke test
node test-remote-provider.mjs
# Expected output:
#   available: true
#   indexed 2 docs
#   entity search results: pipeline:ts-test score=... corpus=entities
#   knowledge search results: schema:trigger score=...
#   all-corpus search results: (merged, sorted by score)
#   isolation check (other-acct, should be empty): PASS

# 5. Tear down
kill $(lsof -ti :8082)

O stub (stub-search-service.py) implementa o mesmo contrato de /v1/health, /v1/ingest e /v1/search que o serviço de pesquisa de produção. Ele usa uma incorporação simples do tipo bag-of-chars, portanto nenhum download de modelo é necessário — os resultados são semanticamente plausíveis, mas não têm qualidade de produção.

Aplicação de HTTPS

HARNESS_BASE_URL deve usar HTTPS por padrão. Se você definir uma URL não HTTPS (por exemplo, http://localhost:8080), o servidor se recusará a iniciar com:

HARNESS_BASE_URL must use HTTPS (got "http://..."). If you need HTTP for local development, set HARNESS_ALLOW_HTTP=true.

Registro de Auditoria

Todas as operações de API do Harness despachadas pelo registro (list, get, create, update, delete e execute) emitem eventos de auditoria estruturados quando sumidouros de auditoria estão configurados. Eventos de mutação incluem o caminho de confirmação usado por elicitação ou aprovação automática quando um contexto de confirmação está presente; eventos de leitura atualmente omitem metadados de confirmação. Ferramentas de descoberta de metadados e esquema locais que ignoram o registro, como harness_describe e harness_schema, não fazem parte deste fluxo de auditoria. Um sumidouro de stderr é registrado por padrão, mas passa pelo logger normal e obedece a LOG_LEVEL; configure sumidouros de arquivo ou webhook para coleta de auditoria durável:

HARNESS_AUDIT_FILE anexa eventos JSON delimitados por nova linha para coleta local.
HARNESS_AUDIT_WEBHOOK_URL envia lotes de { "events": [...] } para um webhook HTTPS, opcionalmente com HARNESS_AUDIT_WEBHOOK_TOKEN. Lotes com falha são reenfileirados com capacidade limitada e eventualmente descartados com um aviso, em vez de bloquear a execução da ferramenta.
OTEL_EXPORTER_OTLP_ENDPOINT habilita spans de auditoria quando as dependências opcionais do OpenTelemetry estão instaladas. O sumidouro reutiliza um provedor de tracer existente quando um está registrado; caso contrário, ele inicializa um exportador OTLP independente.

Cada evento inclui o nome da ferramenta, tipo de recurso, operação, identificadores, carimbo de data/hora, risco, resultado, método/caminho HTTP, duração e método de confirmação quando aplicável. Sumidouros de auditoria são telemetria de melhor esforço; problemas de entrega são registrados e nunca reproduzem ou alteram a operação subjacente da API do Harness. Para detalhes de configuração do OTel e atributos de span, consulte specs/005-otel-audit-sink.md.

Referência de Ferramentas

O servidor expõe 11 ferramentas MCP. A maioria das ferramentas de API aceita org_id e project_id como substituições opcionais — se omitidos, eles voltam para HARNESS_ORG e HARNESS_PROJECT. harness_describe é apenas metadados locais e não usa escopo de org/projeto.

Suporte a URL: A maioria das ferramentas voltadas para API aceita um parâmetro url — cole uma URL da interface do Harness e o servidor extrai automaticamente org, projeto, tipo de recurso, ID do recurso, ID do pipeline e ID da execução. harness_describe não aceita url.

Suporte a escopo: Tipos de recurso com variantes de conta/org/projeto expõem supportedScopes em harness_describe. Passe resource_scope quando precisar de um nível específico:

resource_scope: "account" envia apenas accountIdentifier.
resource_scope: "org" envia accountIdentifier e orgIdentifier.
resource_scope: "project" envia identificadores de conta, org e projeto.

Recursos atuais com múltiplos escopos incluem connector, service, environment, infrastructure, secret, file_store, template, policy e policy_set. Se resource_scope for omitido, o registro usa o escopo padrão do recurso e os padrões configurados, exceto que recursos marcados como escopo opcional podem omitir org/projeto, a menos que sejam passados explicitamente. URLs do Harness também podem definir o escopo automaticamente quando o caminho contém contexto de nível de conta ou projeto.

Saída estruturada: Cada ferramenta declara um outputSchema do MCP. harness_list normaliza respostas do Harness semelhantes a listas em conteúdo estruturado em formato de objeto, para que clientes estritos possam validá-lo: arrays de nível superior se tornam { "items": [...], "total": <count>, "page": <page> }, e chaves de wrapper comuns, como content, data, body, objects ou features, são elevadas para items quando necessário. A resposta de texto ainda contém o payload JSON compacto retornado a todos os clientes.

Ferramenta	Descrição
`harness_describe`	Descubra tipos de recursos, operações e campos disponíveis. Nenhuma chamada de API — retorna metadados do registro local.
`harness_schema`	Busque definições exatas de esquemas YAML/JSON e exemplos para criar/atualizar recursos. Esquemas de pipelines/templates são incluídos; esquemas de conectores, ambientes, serviços, segredos e infraestrutura são esquemas de entidades cientes de escopo, buscados de snapshots incluídos ou da NG `/yaml-schema`; esquemas de `release_process` e `release_activity` são buscados ao vivo do RMG `/api/yamlSchema`. Suporta aprofundamento via `path`.
`harness_list`	Liste recursos de um determinado tipo com filtragem, pesquisa e paginação.
`harness_get`	Obtenha um único recurso pelo seu identificador.
`harness_create`	Crie um novo recurso. Suporta pipelines inline e remotos (baseados em Git). Solicita confirmação do usuário via elicitação.
`harness_update`	Atualize um recurso existente. Suporta pipelines inline e remotos (baseados em Git). Solicita confirmação do usuário via elicitação.
`harness_delete`	Exclua um recurso. Solicita confirmação do usuário via elicitação. Destrutivo.
`harness_execute`	Execute uma ação em um recurso (executar/repetir pipeline, importar pipeline do Git, alternar flag, sincronizar app). Solicita confirmação do usuário via elicitação. Para execuções de pipeline, use o fluxo de trabalho de entrada em tempo de execução abaixo (suporta expansão abreviada de `branch`/`tag`/`pr_number`/`commit_sha`).
`harness_search`	Pesquise em todos os tipos de recursos do Harness com uma única consulta. Usa roteamento semântico (embeddings ONNX locais `all-MiniLM-L6-v2`, 384 dimensões) para prever tipos de recursos relevantes a partir de um corpus `knowledge` indexado na inicialização — normalmente reduzindo de ~163 tipos para 1–8 antes do scatter-gather. Recorre ao scatter-gather completo por palavras-chave quando a confiança semântica é baixa. A resposta inclui `semantic_routed` e `types_skipped` quando o roteamento é acionado. Veja `docs/search-guidelines.md` para saber como tornar novos tipos de recursos detectáveis.
`harness_diagnose`	Diagnostique recursos `pipeline`, `connector`, `delegate` e `gitops_application` (aliases: `execution` -> `pipeline`, `gitops_app` -> `gitops_application`). Para pipelines, retorna tempos de estágio/etapa e detalhes de falha; para conectores/delegados/apps GitOps, retorna sinais direcionados de saúde e solução de problemas.
`harness_status`	Obtenha um painel de saúde do projeto em tempo real — execuções recentes, taxas de falha e links diretos.

Fluxo de Trabalho de Consulta de Esquema

Use harness_schema antes de criar ou atualizar recursos baseados em YAML para que os agentes possam copiar nomes de campos e restrições exatos em vez de adivinhar a partir de prosa.

Esquemas incluídos incluem pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 e agent-pipeline.
Esquemas de entidades incluem connector, environment, service, secret e infrastructure. Eles são cientes de escopo (account, org ou project) e exigem org_id/project_id quando o escopo selecionado os exigir.
Definições de Release Management (release_process, release_activity) buscam JSON Schema ao vivo do RMG /api/yamlSchema (não incluído). Passe scope, org_id e project_id ao definir escopo para organização ou projeto.
Snapshots de entidades fornecidos são usados primeiro quando correspondem à conta em tempo de execução; caso contrário, a ferramenta recorre à API NG /yaml-schema do Harness e armazena o resultado em cache.
Omita path para um resumo de campos/seções e, em seguida, passe um path separado por pontos para inspecionar uma definição aninhada.

Exemplos:

{ "resource_type": "pipeline", "path": "pipeline.stages" }

{
  "resource_type": "connector",
  "scope": "project",
  "org_id": "default",
  "project_id": "payments"
}

Os mantenedores podem atualizar os snapshots de entidades fornecidos com pnpm sync-entity-schemas quando os esquemas YAML de entidades do Harness mudarem.

Exemplos de Ferramentas

Descubra quais recursos estão disponíveis:

{ "resource_type": "pipeline" }

Liste organizações na conta:

{ "resource_type": "organization" }

Liste projetos em uma organização:

{ "resource_type": "project", "org_id": "default" }

Liste pipelines em um projeto:

{ "resource_type": "pipeline", "search_term": "deploy", "size": 10 }

Obtenha um serviço específico:

{ "resource_type": "service", "resource_id": "my-service-id" }

Execute um pipeline:

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "my-pipeline",
  "inputs": { "tag": "v1.2.3" },
  "wait": true
}

Alterne um feature flag:

{
  "resource_type": "feature_flag",
  "action": "toggle",
  "resource_id": "new_checkout_flow",
  "enable": true,
  "environment": "production"
}

Pesquise em todos os tipos de recursos:

{ "query": "payment-service" }

Diagnostique uma execução por ID (modo resumo — padrão):

{ "execution_id": "abc123XYZ" }

Diagnostique a partir de uma URL do Harness:

{ "url": "https://app.harness.io/ng/account/.../pipelines/myPipeline/executions/abc123XYZ/pipeline" }

Diagnostique a conectividade do conector:

{ "resource_type": "connector", "resource_id": "my_github_connector" }

Diagnostique a saúde do delegate:

{ "resource_type": "delegate", "resource_id": "delegate-us-east-1" }

Diagnostique um aplicativo GitOps (com opções):

{
  "resource_type": "gitops_application",
  "resource_id": "checkout-app",
  "options": { "agent_id": "gitops-agent-1" }
}

Obtenha o relatório de execução mais recente de um pipeline:

{ "pipeline_id": "my-pipeline" }

Modo de diagnóstico completo com YAML e logs de etapas com falha:

{ "execution_id": "abc123XYZ", "summary": false }

Modo resumo com logs habilitados (o melhor dos dois mundos):

{ "execution_id": "abc123XYZ", "include_logs": true }

Obtenha o status de saúde do projeto:

{ "org_id": "default", "project_id": "my-project", "limit": 5 }

Liste esquemas de banco de dados filtrados por tipo de migração:

{ "resource_type": "database_schema", "migration_type": "Liquibase" }

Liste instâncias de banco de dados para um esquema:

{ "resource_type": "database_instance", "dbschema_id": "my_schema" }

Obtenha o pipeline de autoria LLM resolvido para um esquema e instância:

{ "resource_type": "database_llm_authoring_pipeline", "resource_id": "my_schema", "dbinstance_id": "prod_db" }

Liste nomes de objetos de snapshot (ex.: tabelas) para uma instância de esquema:

{
  "resource_type": "database_snapshot_object",
  "dbschema_id": "my_schema",
  "dbinstance_id": "prod_db",
  "object_type": "Table"
}

Obtenha metadados completos de snapshot para objetos nomeados específicos:

{
  "resource_type": "database_snapshot_object",
  "resource_id": "prod_db",
  "params": {
    "dbschema_id": "my_schema",
    "object_type": "Table",
    "object_names": ["users", "orders"]
  }
}

Fluxo de Trabalho de Execução de Pipeline (Recomendado)

Para pipelines v0, use esta sequência para reduzir erros de entrada em tempo de execução:

Descubra entradas de tempo de execução obrigatórias

harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
O template retornado mostra espaços reservados <+input> que precisam de valores.

Escolha a estratégia de entrada

Variáveis simples: passe pares chave-valor planos inputs (por exemplo, {"branch":"main","env":"prod"}).
Entradas complexas/estruturais: use input_set_ids (blocos de codebase/build de CI e entradas de template aninhadas são melhor tratadas assim).

Chaves abreviadas de codebase de CI (somente execução de pipeline):

Chave abreviada	Estrutura expandida
`branch`	`build.type=branch`, `build.spec.branch=<value>`
`tag`	`build.type=tag`, `build.spec.tag=<value>`
`pr_number`	`build.type=PR`, `build.spec.number=<value>`
`commit_sha`	`build.type=commitSha`, `build.spec.commitSha=<value>`

Restrição: a expansão abreviada é ignorada quando inputs.build já está presente (o build explícito vence).

Execute a execução

harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)
Para pipelines baseados em Git cujo YAML deve ser carregado de uma branch não padrão, passe params.pipeline_branch (enviado ao Harness como branch). Este seletor de definição explícito tem precedência sobre o alias params.branch. inputs.branch seleciona independentemente a branch do codebase de CI:
```
{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}
```

Opcional: combine ambos

Use input_set_ids para a forma base e inputs para substituições simples.

Para pipelines v1:

Busque harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>"). Para pipelines baseados em Git, passe branch_name, connector_ref e repo_name através de params.
Use cada inputs[].details.name retornado como uma chave de nível superior em harness_execute.inputs.
Execute harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}). O servidor envolve esses valores sob uma raiz YAML inputs: e envia o corpo inputs_yaml da API. Se os campos obrigatórios não forem resolvidos, a ferramenta retorna um erro de pré-validação com as chaves esperadas e conjuntos de entrada sugeridos. Você pode inspecionar os mapeamentos abreviados disponíveis com harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Execução Dinâmica de Pipeline

Use pipeline_dynamic_execution.run quando um agente ou sistema externo gera o YAML completo do pipeline v0 em tempo de execução e precisa executá-lo contra um shell de pipeline Harness existente. Isso não substitui o pipeline.run normal: o pipeline v0 salvo já deve existir, o Allow Dynamic Execution no nível da conta e do pipeline deve estar habilitado, e o chamador precisa de permissões de Edição e Execução no pipeline.

{
  "resource_type": "pipeline_dynamic_execution",
  "action": "run",
  "resource_id": "deploy_app",
  "body": {
    "yaml": "pipeline:\n  identifier: deploy_app\n  name: Deploy App\n  stages: []"
  },
  "params": {
    "module_type": "CD",
    "notes": "agent-generated dynamic run",
    "notify_only_user": true
  }
}

Restrições:

body deve ser um objeto com um campo yaml. Corpos de string brutos são rejeitados pelo schema público harness_execute.
body.yaml pode ser uma string YAML ou um objeto de pipeline JSON; o JSON é serializado para YAML antes da solicitação.
Os placeholders de <+input> em tempo de execução não são resolvidos por esta API. Envie YAML totalmente resolvido.
Conjuntos de entrada, execução seletiva de estágios, repetição e gatilhos não são suportados pelo endpoint de execução dinâmica.
A ação é high_write e usa o caminho normal de confirmação/aprovação automática. A resposta projeta o envelope da API para { "execution_id": "...", "status": "..." } e inclui um link de execução openInHarness quando os dados de escopo estão disponíveis.

Se o Harness rejeitar a execução como não habilitada, verifique tanto a configuração Allow Dynamic Execution no nível da conta quanto o alternador no nível do pipeline em Pipeline -> Advanced Options -> Dynamic Execution Settings.

Forense de Entrada de Execução

Use execution_inputs após uma execução para inspecionar o YAML de entrada mesclado que produziu uma execução específica. Isso é útil quando uma falha depende da mesclagem de conjuntos de entrada, branches de conjuntos de entrada com suporte a Git ou valores de gatilho/tempo de execução que são difíceis de reconstruir apenas pela página de execução.

{
  "resource_type": "execution_inputs",
  "resource_id": "PLAN_EXECUTION_ID",
  "params": {
    "resolve_expressions": true,
    "resolve_expressions_type": "RESOLVE_ALL_EXPRESSIONS"
  }
}

A resposta de get é projetada para:

executionId - o ID de execução do plano de resource_id.
inputSetYaml - YAML de entrada de tempo de execução mesclado usado para a execução, ou null.
inputSetTemplateYaml - modelo de entrada no momento da execução, ou null.
resolvedYaml - YAML resolvido por expressão quando resolve_expressions=true, caso contrário, geralmente null.
inputSetDetails - conjuntos de entrada salvos que contribuíram como pares { identifier, name }.
inputSetBranchName - branch de origem para conjuntos de entrada com suporte a Git, ou null.

execution_inputs é somente leitura e de baixo risco. Se resolve_expressions for omitido, o servidor omite os parâmetros de consulta da API e o Harness usa seu modo de resolução UNKNOWN padrão.

Modo de Espera de Execução de Pipeline

Para pipeline.run, pipeline.retry e pipeline_v1.run, passe wait: true para permitir que o servidor faça polling até que a execução atinja um status terminal. Isso mantém o lançamento do pipeline e a verificação de status em uma única chamada de ferramenta, em vez de pedir ao cliente ou LLM para executar um loop de polling.

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "inputs": { "branch": "main" },
  "wait": true,
  "wait_timeout_seconds": 900,
  "wait_poll_interval_seconds": 5
}

Comportamento do modo de espera:

O tempo limite padrão é de 600 segundos; a faixa permitida é de 10 segundos a 7200 segundos.
O intervalo inicial de polling é de 3 segundos, com backoff de 1,5x e limite máximo de 30 segundos.
Em caso de sucesso ou falha, a resposta inclui campos como execution_id, execution_status, execution_terminal, execution_elapsed_ms e execution_poll_count.
Se o tempo limite expirar, o gatilho original ainda foi bem-sucedido; a resposta inclui execution_timed_out: true e _wait.hint com o último status observado.
Se o polling falhar após o gatilho ser bem-sucedido, a resposta inclui _wait.error e uma dica de recheck. Não execute novamente o pipeline às cegas, a menos que você tenha confirmado que a primeira execução não está em andamento.
Os status terminais de falha incluem _diagnose_hint apontando para harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Peça ao AI DevOps Agent para criar um pipeline:

{
  "prompt": "Create a pipeline that builds a Go app with Docker and deploys to Kubernetes",
  "action": "CREATE_PIPELINE"
}

Atualize um serviço por meio de linguagem natural:

{
  "prompt": "Add a sidecar container for logging",
  "action": "UPDATE_SERVICE",
  "conversation_id": "prev-conversation-id",
  "context": [{ "type": "yaml", "payload": "<existing service YAML>" }]
}

Modos de Armazenamento de Pipeline

Os pipelines do Harness podem ser armazenados de três maneiras:

Modo	Descrição	Quando usar
Inline	YAML do pipeline armazenado no Harness	Padrão. Configuração mais simples, sem necessidade de Git.
Remoto (Git Externo)	YAML do pipeline armazenado em GitHub, GitLab, Bitbucket, etc.	Equipes que usam pipeline-as-code com suporte a Git com um provedor externo.
Remoto (Harness Code)	YAML do pipeline armazenado em um repositório Harness Code	Equipes que usam o hosting Git integrado do Harness.

Criar um pipeline inline (padrão):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: My Pipeline\n  identifier: my_pipeline\n  stages:\n    - stage:\n        name: Build\n        type: CI\n        spec:\n          execution:\n            steps:\n              - step:\n                  type: Run\n                  name: Echo\n                  spec:\n                    command: echo hello"
  }
}

Criar um pipeline remoto (Git Externo — ex.: GitHub):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Add deploy pipeline via MCP"
  }
}

Criar um pipeline remoto (Harness Code — sem necessidade de conector):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Build App\n  identifier: build_app\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/build-app.yaml",
    "commit_msg": "Add build pipeline via MCP"
  }
}

Atualizar um pipeline remoto:

// harness_update
{
  "resource_type": "pipeline",
  "resource_id": "deploy_service",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages:\n    - stage:\n        name: Deploy\n        type: Deployment"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Update deploy pipeline via MCP",
    "last_object_id": "abc123",
    "last_commit_id": "def456"
  }
}

Importar um pipeline de um repositório Git externo:

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline",
    "pipeline_description": "Imported from GitHub"
  }
}

Importar um pipeline de um repositório Harness Code:

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline"
  }
}

Criar um conector:

{
  "resource_type": "connector",
  "body": { "connector": { "name": "My Docker Hub", "identifier": "my_docker", "type": "DockerRegistry" } }
}

Excluir um gatilho:

{
  "resource_type": "trigger",
  "resource_id": "nightly-trigger",
  "pipeline_id": "my-pipeline"
}

Listar conjuntos de entrada para um pipeline:

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline"
}

Obter um conjunto de entrada específico:

{
  "resource_type": "input_set",
  "resource_id": "prod-inputs",
  "pipeline_id": "my-pipeline"
}

Criar um conjunto de entrada:

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production"
}

Atualizar um conjunto de entrada:

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production\n      - name: replicas\n        type: String\n        value: \"3\""
}

Excluir um conjunto de entrada:

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline"
}

Tipos de Recursos

255 tipos de recursos organizados em 41 conjuntos de ferramentas. Cada tipo de recurso suporta um subconjunto de operações CRUD e ações de execução opcionais.

Plataforma

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`organization`	x	x	x	x	x
`project`	x	x	x	x	x

Pipelines

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`pipeline`	x	x	x	x	x	`run`, `retry`
`pipeline_v1` (Alpha)	x	x	x	x	x	`run`
`pipeline_dynamic_execution`						`run`
`execution`	x	x				`interrupt`
`execution_inputs`		x
`trigger`	x	x	x	x	x
`pipeline_summary`		x
`input_set`	x	x	x	x	x
`runtime_input_template`		x
`runtime_input_template_v1`		x
`pipeline_resolved_yaml`		x
`approval_instance`	x					`approve`, `reject`

Ambos os tipos de recursos YAML de pipeline estão disponíveis quando o conjunto de ferramentas de pipelines está habilitado. HARNESS_PIPELINE_VERSION e o cabeçalho de inicialização HTTP x-harness-pipeline-version selecionam a preferência de versão padrão; eles não ocultam a outra versão.

Agentes de IA

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`agent`	x	x	x	x	x
`agent_run`	x

Serviços

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`service`	x	x	x	x	x

Ambientes

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`environment`	x	x	x	x	x	`move_configs`

Conectores

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`connector`	x	x	x	x	x	`test_connection`
`connector_catalogue`	x

Infraestrutura

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`infrastructure`	x	x	x	x	x	`move_configs`

Segredos

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`secret`	x	x

Logs de Execução

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`execution_log`		x

Trilha de Auditoria

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`audit_event`	x	x

Delegados

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`delegate`	x	x
`delegate_token`	x	x	x		x	`revoke`, `get_delegates`

Repositórios de Código

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Ações de Execução
`repository`	x	x	x	x
`branch`	x	x	x		x
`commit`	x	x	x			`diff`, `diff_stats`
`file_content`	x	x				`blame`
`tag`	x		x		x
`repo_rule`	x	x
`space_rule`	x	x

A criação de commit confirma uma ou mais ações de arquivo diretamente por meio da API Harness Code, sem clonagem. Passe body.title, body.branch e body.actions; cada ação é CREATE, UPDATE, DELETE ou MOVE, e UPDATE requer o SHA do blob atual.

A lista de file_content retorna todos os caminhos em uma ref; get retorna o conteúdo do arquivo ou diretório (omita ou passe path vazio para a raiz do repositório; caminhos aninhados mantêm as barras). Omita git_ref para usar o branch padrão do repositório — não adivinhe main.

Registros de Artefatos

Tipo de Recurso	Listar	Obter
`registry`	x	x
`artifact`	x
`artifact_version`	x
`artifact_file`	x

File Store

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`file_store`	x	x	x	x	x	`list_children`

file_store gerencia arquivos e pastas do Harness File Store por meio das ferramentas genéricas. Ele suporta escopo de conta, organização e projeto; passe resource_scope="account"|"org"|"project" ou cole uma URL do Harness File Store para que o servidor possa derivar o escopo e os IDs.

Chamadas comuns:

# List the account-level File Store.
harness_list(resource_type="file_store", resource_scope="account")

# Create a folder at the current scope root.
harness_create(resource_type="file_store", body={
  name: "scripts",
  type: "FOLDER",
  parent_identifier: "Root"
})

# Upload a UTF-8 script file. Use content_base64 instead for binary data.
harness_create(resource_type="file_store", body={
  name: "deploy.sh",
  type: "FILE",
  parent_identifier: "Root",
  content: "#!/usr/bin/env bash\n./deploy",
  mime_type: "text/x-shellscript",
  file_usage: "SCRIPT"
})

# Rename metadata without replacing file content.
harness_update(resource_type="file_store", resource_id="deploy_script", body={
  name: "deploy-prod.sh",
  type: "FILE",
  parent_identifier: "Root"
})

# List first-level children of a folder. This is a read-risk execute action.
harness_execute(resource_type="file_store", action="list_children",
  resource_id="scripts_folder", params={folder_name: "scripts"})

Restrições do corpo multipart:

Criar/atualizar aceitam JSON body, depois convertem para multipart/form-data para /ng/api/file-store.
name, type (FILE ou FOLDER) e parent_identifier são obrigatórios; use o literal "Root" apenas para a raiz do escopo selecionado.
A criação de FILE exige exatamente um de content (string UTF-8) ou content_base64 (base64 válido e não vazio). A atualização de FILE pode omitir o conteúdo para atualizações apenas de metadados, ou fornecer exatamente um campo de conteúdo para substituir o conteúdo.
A criação/atualização de FOLDER deve omitir content e content_base64.
file_usage opcional deve ser MANIFEST_FILE, CONFIG ou SCRIPT; metadados escalares opcionais, como description, mime_type, path e tags, devem ser strings.
O conteúdo do upload é limitado a 100 MB. Os prompts de confirmação ocultam as pré-visualizações de content, content_base64 e contentBase64 antes da elicitação.

list_children aceita tanto a forma abreviada (resource_id mais params.folder_name, ou params.file_store_id/params.folder_identifier mais params.folder_name) quanto um FileStoreNode completo body com identifier, name e type: "FOLDER". Corpos completos usam parentIdentifier em camelCase do Harness; a forma abreviada pode usar params.parent_identifier.

Templates

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`template`	x	x	x	x	x

As operações de template usam os caminhos do serviço de Template do Harness (/template/api/templates...). Criar e atualizar exigem a string YAML completa do template em body.template_yaml ou body.yaml; version_label tem como alvo uma versão específica para atualizar/excluir, enquanto excluir sem version_label exclui todas as versões.

Dashboards

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`dashboard`	x	x
`dashboard_data`		x

Database DevOps

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir
`database_schema`	x	x	x	x	x
`database_instance`	x	x	x	x	x
`database_snapshot_object`	x	x
`database_llm_authoring_pipeline`		x

Gerenciamento de Infraestrutura como Código (IaCM)

Os recursos do IaCM são habilitados por padrão e, em sua maioria, têm escopo de projeto. Comece com iacm_workspace para encontrar identificadores de workspace e, em seguida, use esse workspace_id para recursos de workspace, custos e diffs de atividade. Use iacm_variable_set para conjuntos de variáveis reutilizáveis no escopo de conta, organização ou projeto. O registro de provedores tem escopo de conta.

iacm_module abrange escopo de conta, organização e projeto. Ele usa como padrão o registro da conta; cada operação (listar, obter, criar, atualizar) envia os mesmos parâmetros de consulta scope_org / scope_project, portanto, um módulo que você criar será detectável no escopo em que foi criado. Selecione o escopo com resource_scope="account" | "org" | "project" mais org_id/project_id. O escopo é opcional: quando resource_scope é omitido, org_id/project_id se aplicam somente se você os passar explicitamente — os padrões configurados de HARNESS_ORG/HARNESS_PROJECT não são aplicados, portanto, uma configuração de projeto ambiente não pode registrar silenciosamente um módulo de conta sob um projeto. Os campos org/project do próprio corpo de um módulo localizam seu conector Git e não estão relacionados a esse escopo de visibilidade.

A criação/atualização de iacm_workspace retorna apenas { policy_evaluation } — continue com harness_get para buscar o workspace. A criação/atualização de iacm_variable_set e iacm_module retorna o próprio recurso. A criação de iacm_provider retorna apenas { id } — continue com harness_get; a atualização é somente orientada a versão (POST/PUT /providers/{id}/version) — não há PUT de metadados. Gravações de versão podem retornar um corpo vazio; o HarnessClient normaliza isso para { status: "SUCCESS", message: "No content" }.

A atualização de conjunto de variáveis é HTTP PUT com coleções de substituição completa — sempre faça harness_get primeiro e depois faça PUT do corpo completo desejado (terraform_variables / environment_variables são obrigatórios na atualização; omitir/vazio limpa conectores e arquivos de variáveis). A atualização de módulo também é PUT — prefira obter-depois-put para campos opcionais. Gravações são medium_write e exigem confirmação (elicitação ou confirm: true).

O RBAC de conjunto de variáveis e registro de provedores (iac_variableset_*, iac_providerregistry_*) está atualmente Experimental no Harness — as verificações de acesso sempre permitem até que o iac-server ative a aplicação. O RBAC do registro de módulos (iac_registry_view / iac_registry_edit) está Ativo e aplicável. O MCP sempre encaminha o PAT/SAT do chamador sem alterações.

Tipo de Recurso	Listar	Obter	Criar	Atualizar
`iacm_workspace`	x	x	x	x
`iacm_variable_set`	x	x	x	x
`iacm_resource`	x
`iacm_module`	x	x	x	x
`iacm_provider`	x	x	x	x
`iacm_workspace_costs`	x
`iacm_activity_resource_change`	x

Fluxo de trabalho típico:

harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") para encontrar o workspace.
harness_create / harness_update em iacm_workspace para criar do zero ou a partir de um template (associated_template), ou atualizar um workspace existente — a resposta é apenas { policy_evaluation }.
harness_get(resource_type="iacm_workspace", workspace_id="...") para buscar o workspace criado/atualizado.
harness_list / harness_create / harness_update em iacm_variable_set (opcionalmente com resource_scope) para conjuntos de variáveis reutilizáveis de Terraform/env — a resposta é o recurso VariableSet.
harness_list / harness_create / harness_update em iacm_module para o registro de módulos (name + system obrigatórios; adicione resource_scope com org_id/project_id para um módulo com escopo de organização ou projeto) — a resposta é o recurso de módulo.
harness_list / harness_create / harness_update em iacm_provider para o registro de provedores da conta (body.type obrigatório para criar; criar retorna apenas { id } — depois harness_get; atualizar cria/atualiza apenas versões) — a atualização de versão pode retornar sucesso vazio.
harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") para inspecionar recursos Terraform, saídas e fontes de dados.
harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") para revisar entradas de custo por execução.
harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") para inspecionar diffs de recursos antes/depois para uma atividade de plan, apply ou destroy.

As respostas de listagem do IaCM expõem page_count como a contagem apenas da página atual (exceto iacm_variable_set, que não é paginado). Quando has_more for verdadeiro, continue solicitando a próxima página baseada em 1 e some as contagens das páginas se precisar de um total.

Portal Interno de Desenvolvedores (IDP)

Tipo de Recurso	Listar	Obter	Executar Ações
`idp_entity`	x	x
`scorecard`	x	x
`scorecard_check`	x	x
`scorecard_stats`		x
`scorecard_check_stats`		x
`idp_score`	x	x
`idp_workflow`	x		`execute`
`idp_tech_doc`	x

Pull Requests

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`pull_request`	x	x	x	x		`close`, `merge`
`pr_reviewer`	x		x			`submit_review`
`pr_comment`			x	x	x
`pr_check`	x
`pr_activity`	x

Use harness_execute(resource_type="pull_request", action="close", ...) para uma operação explícita de fechamento. harness_update também aceita body.state (open ou closed) e roteia mudanças de estado para o endpoint dedicado de estado de PR do Harness Code; envie edições de título/descrição em uma chamada de atualização separada.

Use harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) para ler comentários de PR. Use pr_comment para operações de escrita de comentários.

Gerenciamento de Releases

Os recursos de Gerenciamento de Releases (RMG) são habilitados por padrão. Os recursos de definição (release_process, release_activity) suportam listar/obter/criar/atualizar/excluir com body.yaml; chame harness_schema(resource_type="release_process"|"release_activity") antes de criar/atualizar. Os recursos de execução monitoram releases em andamento — a maioria das operações de listagem exige release_id (UUID de harness_list resource_type=release, ou o slug de URL da interface como identifier-1.0.0-abc). Cole uma URL de release do RMG em harness_list para preencher automaticamente release_id.

As chamadas do RMG usam ${HARNESS_BASE_URL}/gateway/rmg com escopo de conta por meio do cabeçalho Harness-Account. O escopo de organização/projeto usa escopo baseado em cabeçalho quando org_id/project_id são fornecidos. release_execution_phase é somente listagem — use o campo identifier de cada item de fase como params.phase_identifier ao chamar harness_get nos recursos de entrada/saída da fase (não chame harness_get no próprio release_execution_phase). A filtragem de status da lista de releases é aplicada no lado do cliente apenas na página atual; continue paginando com os mesmos filtros quando os resultados puderem abranger várias páginas.

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir
`release_process`	x	x	x	x	x
`release_activity`	x	x	x	x	x
`release`	x	x
`release_execution_phase`	x
`release_execution_task`	x
`release_execution_activity`	x
`release_input`		x
`release_execution_phase_input`		x
`release_execution_phase_output`		x
`release_execution_activity_input`		x
`release_execution_activity_output`		x

Fluxo de trabalho típico:

harness_list(resource_type="release_process", org_id="...", project_id="...") para descobrir definições de processos de orquestração.
harness_schema(resource_type="release_process") (ou release_activity) antes de criar/atualizar; em seguida, harness_create / harness_update com body.yaml.
harness_list(resource_type="release", org_id="...", project_id="...") para encontrar versões ativas ou recentes (padrão de 30 dias de retrospectiva; opcional filters.status, filters.search_term, filters.days_back).
harness_get(resource_type="release", release_id="...") para detalhes da versão.
harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) para status da fase; mesmo release_id para release_execution_task e release_execution_activity.
harness_get em release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output ou release_execution_activity_input usando release_id mais params.phase_identifier / params.activity_identifier / activity_execution_id conforme documentado em cada recurso.

Vibração

O conjunto de ferramentas vibe habilitado por padrão cobre o contrato BFF do Vibe Orchestrator sob ${HARNESS_BASE_URL}/vibe/v1. Ele usa a conexão Harness existente e o cabeçalho da conta, sem adicionar parâmetros de consulta de conta/org/projeto ou campos de escopo aos corpos das solicitações. A equipe validou o fluxo Vibe usando autenticação por chave de API Harness (PAT/SAT), portanto, nenhuma configuração de adesão é necessária para sessões padrão. Os documentos OpenAPI selecionados descrevem autenticação de sessão/bearer; o modo OAuth do servidor encaminha o token bearer da sessão atual. Regressões automatizadas verificam ambos os caminhos de cabeçalho; a autenticação de gateway permanece sujeita à configuração do ambiente de destino.

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`vibe_project`			x			`prepare`, `deploy`
`vibe_app_lifecycle`		x				`events`

A API suporta dois caminhos de entrada. Mantenha estas formas de solicitação nativas da API:

Fonte disponível para o agente de codificação	Fluxo da API
Link/conector de repositório GitHub	`harness_create` com `resource_type="vibe_project"` e `body.mode` mais os campos específicos do modo. O contrato nomeia `github_link` e `github_connector`, mas não define suas formas de campos de URL, branch ou conector; esses campos são encaminhados ao backend sem inventar um mapeamento.
Arquivo ZIP	Chame `prepare` com o nome do aplicativo e metadados do arquivo, envie os bytes para o destino assinado retornado e, em seguida, chame `deploy`.
Diretório de origem local	O agente de codificação arquiva o código-fonte do espaço de trabalho pretendido em um ZIP localmente e, em seguida, segue o fluxo ZIP. Um caminho local ou contexto conversacional não é um upload de origem suportado pela API.

Ao empacotar um diretório, inclua o código-fonte, manifestos, lockfiles, configuração e edições não confirmadas pretendidas necessárias para construí-lo. Exclua credenciais, .git, dependências instaladas e artefatos gerados. O empacotamento e o upload assinado acontecem onde os arquivos estão acessíveis; um servidor MCP hospedado não pode ler o diretório local do agente de codificação.

Para um ZIP existente, prepare o upload:

{
  "resource_type": "vibe_project",
  "action": "prepare",
  "body": {
    "name": "demo-app",
    "file": {
      "path": "app.zip",
      "size_bytes": 12345,
      "content_type": "application/zip"
    }
  }
}

Passe isso para harness_execute. O tamanho deve descrever o ZIP real; size_bytes, content_type e md5 são opcionais e anuláveis. Campos adicionais de preparação são preservados para validação do backend, conforme permitido pelo OpenAPI. A preparação retorna projectId, sourceId e upload, incluindo o uploadUrl, method, headers e expiresAt de cada arquivo. Envie os bytes do arquivo diretamente usando essa URL assinada, método e cabeçalhos; preserve a URL exatamente e não adicione credenciais Harness à solicitação de armazenamento. A ação de preparação não lê nem envia arquivos locais.

Após um upload bem-sucedido, faça a implantação explicitamente:

{
  "resource_type": "vibe_project",
  "action": "deploy",
  "resource_id": "<projectId returned by prepare>"
}

Para importações JSON, use o id retornado. A implantação também aceita body: {"project_id": "<Vibe app id>"} ou params.app_id; o campo de transmissão da API é snake_case project_id mesmo que a preparação retorne camelCase projectId. O project_id de nível superior da ferramenta genérica é um identificador de escopo Harness e nunca é usado como o ID do aplicativo Vibe. Importação e preparação criam o aplicativo/fonte; nenhum inicia a implantação. Gravações não são repetidas automaticamente, e a implantação usa a política de confirmação de alto risco existente.

Leia o progresso com harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Ele retém URLs de aplicativos, estágios de execução, subetapas, falhas, linhas de log e detalhes do analisador de build. A ação de execução events aceita resource_id ou params.app_id e consome o endpoint SSE como um lote finito: até 20 eventos JSON ou cinco segundos após a conexão, com um limite de resposta de 1 MiB. Esses limites pertencem ao endpoint Vibe. O HARNESS_API_TIMEOUT_MS da conexão também limita o consumo de conexão e fluxo juntos; a expiração retorna um erro de tempo limite. Um lote concluído retorna events e stop_reason (end, event_limit ou duration_limit) e fecha o fluxo. Nem falhas de conexão inicial nem fluxos interrompidos são repetidos. Eventos são diffs transitórios sem cursor de reprodução documentado; use o get de ciclo de vida para um instantâneo autoritativo. Ambas as leituras de ciclo de vida estão disponíveis no modo somente leitura.

Feature Flags

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`fme_workspace`	x
`fme_environment`	x	x	x	x	x
`fme_feature_flag`	x	x	x	x	x	`kill`, `restore`, `reallocate`, `archive`, `unarchive`
`fme_feature_flag_definition`	x	x	x	x	x	`kill`, `restore`, `reallocate`
`fme_rollout_status`	x
`fme_rule_based_segment`	x	x	x		x
`fme_rule_based_segment_definition`	x			x		`enable`, `disable`, `change_request`
`fme_traffic_type`	x
`fme_identity`			x	x
`fme_standard_segment`	x	x
`fme_segment_keys`	x			x
`fme_segment`	x	x	x	x	x
`fme_segment_definition`	x	x	x	x	x	`list_keys`, `add_keys`, `remove_keys`
`fme_metric`	x	x	x	x	x
`fme_event_type`	x	x

Recursos FME (Split.io) — recursos fme_* suportam escopo de modo duplo: chamadas legadas passam workspace_id e atingem a API Split.io (api.split.io); chamadas mais recentes passam org_id+project_id juntos e atingem endpoints nativos Harness (padrão HARNESS_API_KEY/HARNESS_BASE_URL, mesma autenticação que qualquer outro recurso harness_*). Passar ambos workspace_id e org_id/project_id na mesma chamada, ou misturar org_id com project_id sozinho, é um erro — escolha um modo por chamada. Cada operação abaixo está disponível no modo legado, inalterada, a menos que o recurso seja marcado como somente nativo Harness. A cobertura do modo nativo Harness é atualmente mais restrita:

fme_workspace — sem equivalente nativo no Harness; apenas legado (usado para descobrir valores de workspace_id).
fme_environment — modo duplo list (workspace_id ou org_id+project_id). get/create/update/delete são apenas nativos do Harness (/fme/api/v4/environments) — o MCP nunca teve um contrato workspace_id para essas operações. A lista nativa usa offset/limit opcionais (máx. 100; harness_list size mapeia para limit); o envelope {data, limit, offset, totalCount} é promovido para items/total. Create/update nativos usam isProduction (production aceito como alias). Update nativo é JSON Merge Patch; name e isProduction não podem ser limpos. Nome com máx. 15 caracteres.
fme_feature_flag — modo duplo, ambos os ramos totalmente conectados. Nativo do Harness (org_id+project_id): list/get/create/delete acessam /fme/api/v4/feature-flags (corpo para create: name, trafficType, description/tags/owners opcionais, por CreateFeatureFlagRequest); update envia um merge-patch para /fme/api/v4/feature-flags/{name}; archive/unarchive acessam /fme/api/v4/feature-flags/{name}/archive|unarchive (apenas comment opcional — sem title, por ArchiveUnarchiveRequest); kill/restore/reallocate acessam /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate com environment_id como parâmetro de consulta (comment/title opcionais, por FeatureFlagDefinitionActionRequest).
fme_feature_flag_definition — get/create/update permanecem em modo duplo (workspace_id ou org_id+project_id). list/delete/kill/restore/reallocate são apenas nativos do Harness (org_id+project_id) — o MCP nunca teve um contrato workspace_id para essas operações. A lista nativa exige feature_flag_name e usa offset/limit (padrão 100, máx. 100); não aceita environment_id. Delete e execute exigem environment_id. Kill/restore/reallocate são as mesmas ações que em fme_feature_flag. O corpo de get/create/update corresponde ao legado (treatments, defaultTreatment, defaultRule, rules/baselineTreatment/trafficAllocation/comment opcionais), além de title opcional no modo nativo do Harness. Update nativo é JSON Merge Patch.
fme_rollout_status — list em modo duplo. Passe org_id+project_id (preferido) ou o workspace_id obsoleto. A paginação nativa usa offset/limit (máx. 100; harness_list size mapeia para limit); os resultados são promovidos para items/total. Cada item tem id, name e description opcional.
fme_rule_based_segment — (Obsoleto — veja fme_segment.) O modo nativo do Harness é rejeitado em todas as operações (list/get/create/delete) — use fme_segment em vez disso; este recurso suporta apenas o contrato legado workspace_id.
fme_rule_based_segment_definition — (Obsoleto — veja fme_segment_definition.) O modo nativo do Harness é rejeitado em todas as operações/ações (list/update/enable/disable/change_request) — use fme_segment_definition em vez disso (sem equivalente enable/disable/change_request lá); este recurso suporta apenas o contrato legado workspace_id/environment_id.
fme_traffic_type — list em modo duplo. Passe org_id+project_id (preferido) ou o workspace_id obsoleto. A paginação nativa usa offset/limit (máx. 100; harness_list size mapeia para limit); os resultados são promovidos para items/total. Cada item tem id e name (sem displayAttributeId).
fme_identity — create/update ainda não foram implementados se org_id+project_id forem passados juntos; caso contrário, prossegue como uma chamada legada normal.
fme_standard_segment — obsoleto. O workspace_id legado ainda acessa o Split v2. O nativo do Harness é rejeitado — use fme_segment.
fme_segment_keys — list/update permanecem legados (workspace_id / environment_id+segment_name). O nativo do Harness (org_id+project_id) é rejeitado — use fme_segment_definition execute list_keys/add_keys/remove_keys.
fme_segment — Apenas nativo (org_id+project_id). CRUD. list/get/update/delete exigem segment_type: STANDARD | LARGE | RULE_BASED. Corpo de create: name, trafficType, segmentType; description, tags, owners opcionais.
fme_segment_definition — Apenas nativo. CRUD mais execute list_keys/add_keys/remove_keys. Update é apenas de descrição. Delete falha com hasDependents enquanto houver chaves.
fme_metric — Apenas nativo do Harness (sem suporte legado workspace_id). list/get/create/update/delete estão conectados a /fme/api/v4/metrics (o harness_list size de list mapeia para limit). create exige spread mesmo que o backend CreateMetricRequest o mantenha opcional (padrão PER) — um contrato mais estrito apenas do lado do MCP, já que omiti-lo muda silenciosamente a semântica de uma métrica RATE. update é JSON Merge Patch; name/trafficType são imutáveis e não aceitos. delete é um hard delete permanente (sem arquivamento/restauração) — classificado como destructive.
fme_event_type — Apenas nativo do Harness (sem suporte legado workspace_id). Somente leitura: list/get estão conectados a /fme/api/v4/event-types; id é o nome do evento. Apenas tipos de evento com eventos nos últimos 30 dias são visíveis; get retorna 404 para um tipo de evento fora do escopo de tipo de tráfego do workspace solicitante, ou ocioso por mais de 30 dias. Filtros de lista: name (substring), traffic_type (por ID ou nome), offset/limit (harness_list size mapeia para limit). Use isso para descobrir IDs reais de tipos de evento antes de referenciar um em fme_metric's baseEventTypes/filterEventType ou filtro event_type_ids, em vez de adivinhar um ID.

Em modo de usuário único/self-hosted, a autenticação em modo legado usa um token Bearer de HARNESS_FME_API_KEY, com fallback para um HARNESS_API_KEY não-placeholder. HARNESS_FME_API_KEY pode ser uma chave de admin legada do Split ou um PAT/SAT do Harness com direito FME, mas é rejeitado no modo multi-user para que implantações compartilhadas não possam substituir a credencial de cada usuário de sessão. Credenciais de OAuth hospedado/roteamento de serviço para APIs da plataforma Harness não autenticam solicitações diretas ao Split.io. fme_feature_flag suporta gerenciamento completo do ciclo de vida no modo legado: create (exige traffic_type_id), list, get, update de metadados, delete e ações de execute kill/restore/reallocate/archive/unarchive. Use fme_traffic_type para descobrir IDs de tipos de tráfego, fme_identity para criar/atualizar atributos de identidade e fme_standard_segment / fme_segment_keys para inspecionar segmentos padrão e adicionar chaves de membros. fme_rule_based_segment fornece CRUD para segmentos de direcionamento, enquanto fme_rule_based_segment_definition gerencia regras de segmento específicas do ambiente com fluxos de aprovação de solicitação de alteração e habilitação/desabilitação.

GitOps

Tipo de Recurso	List	Get	Create	Update	Delete	Ações de Execute
`gitops_agent`	x	x
`gitops_argo_project`	x
`gitops_app_project_mapping`	x		x	x	x	`import`
`gitops_autocreate_log`	x
`gitops_application`	x	x				`sync`
`gitops_cluster`	x	x
`gitops_repository`	x	x
`gitops_applicationset`	x	x
`gitops_repo_credential`	x	x
`gitops_app_event`	x
`gitops_pod_log`		x
`gitops_managed_resource`	x
`gitops_resource_action`	x
`gitops_dashboard`		x
`gitops_app_resource_tree`		x
`gitops_cluster_link`	x		x		x

Chaos Engineering

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`chaos_experiment`	x	x	x		x	`run`, `stop`
`chaos_experiment_run`		x
`chaos_experiment_variable`	x
`chaos_component_variable`		x
`chaos_input_set`	x	x	x	x	x
`chaos_experiment_template`	x	x			x	`create_from_template`, `list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_probe`	x	x	x		x	`enable`, `verify`, `get_manifest`
`chaos_probe_in_run`	x
`chaos_probe_template`	x	x			x	`get_variables`
`chaos_infrastructure`	x
`chaos_k8s_infrastructure`	x	x	x			`check_health`
`chaos_enabled_infrastructure`	x
`chaos_environment`	x
`chaos_hub`	x	x	x	x	x
`chaos_hub_fault`	x
`chaos_fault`	x	x			x	`get_variables`, `get_yaml`
`chaos_fault_template`	x	x			x	`list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_fault_experiment_run`	x
`chaos_action`	x	x	x		x	`get_manifest`
`chaos_action_template`	x	x			x	`list_revisions`, `get_variables`, `compare_revisions`
`chaos_loadtest`	x	x	x	x	x	`run`, `stop`
`chaos_service`	x	x	x	x	x	`list_experiment_runs`, `list_load_tests`
`chaos_application_map`	x	x
`discovered_agent`	x
`discovered_namespace`	x
`discovered_service`	x
`discovered_network_map`	x
`chaos_guard_condition`	x	x			x
`chaos_guard_rule`	x	x			x	`enable`
`chaos_recommendation`	x	x
`chaos_risk`	x	x
`chaos_dr_test`	x		x
`scanned_risk`	x	x				`occurrences`, `summary_by_service`
`chaos_risk_rule`	x	x
`chaos_risk_scan`	x	x	x	x	x	`retry`, `abort`, `report`, `report_download`, `heatmap`

Gerenciamento de Custos na Nuvem (CCM)

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`cost_perspective`	x	x	x	x	x
`cost_breakdown`	x
`cost_timeseries`	x
`cost_summary`	x	x
`cost_recommendation`	x	x				`update_state`, `override_savings`, `create_jira_ticket`, `create_snow_ticket`
`cost_anomaly`	x
`cost_anomaly_summary`		x
`cost_category`	x	x
`cost_account_overview`		x
`cost_filter_value`	x
`cost_recommendation_stats`		x
`cost_recommendation_detail`		x
`cost_commitment`		x
`ai_budget`	x	x	x	x	x
`ai_budget_overview`		x
`ai_budget_consumption`	x
`ai_budget_override_request`	x	x	x			`approve`, `reject`

Insights de Engenharia de Software (SEI)

Os recursos de SEI são consolidados para eficiência de tokens. Use os parâmetros metric ou aspect para DORA, detalhes de equipe/árvore organizacional e insights de IA.

Tipo de Recurso	Listar	Obter	Executar Ações
`sei_metric`	x
`sei_productivity_metric`		x
`sei_dora_metric`		x	Passe `metric`: deployment_frequency, change_failure_rate, mttr, lead_time, ou *_drilldown
`sei_team`	x	x
`sei_team_detail`	x		Passe `aspect`: integrations, developers, integration_filters
`sei_org_tree`	x	x
`sei_org_tree_detail`	x	x	Passe `aspect`: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
`sei_business_alignment`	x	x	Passe `aspect`: feature_metrics, feature_summary, drilldown para obter
`sei_ai_usage`	x	x	Passe `aspect`: metrics, breakdown, summary, top_languages
`sei_ai_adoption`	x	x	Passe `aspect`: metrics, breakdown, summary
`sei_ai_impact`		x	Passe `aspect`: pr_velocity, rework
`sei_ai_raw_metric`	x

Garantia de Segurança da Cadeia de Suprimentos de Software (SCS)

Tipo de Recurso	Listar	Obter
`scs_artifact_source`	x
`artifact_security`	x	x
`scs_artifact_component`	x
`scs_artifact_remediation`		x
`scs_chain_of_custody`		x
`scs_compliance_result`	x
`code_repo_security`	x	x
`scs_sbom`		x

Cofre de Evidências

O Cofre de Evidências armazena atestações in-toto (evidências de SDLC). A listagem suporta escopo de conta/org/projeto via resource_scope. Filtros singulares de texto livre (pipeline, artefato isolado, gitoid) usam search_term; uma restrição adicional de Nome usa filters.subject_name; o digest do conteúdo do assunto usa filters.subject_digest. A obtenção pesquisa por gitoid_sha256 e requer org_id/project_id (da linha da lista). O download (ação harness_execute download) retorna um download_url com tempo limitado — sempre mostre esse link ao usuário. Requer o feature flag SCS_EVIDENCE_VAULT.

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`attestation`	x	x				`download`

Orquestração de Testes de Segurança (STO)

Tipo de Recurso	Listar	Criar	Executar Ações
`security_issue`	x
`security_issue_filter`	x
`security_exemption`	x	x	`approve`, `reject`
`remediation_diff`	x

A criação de security_exemption é uma operação high_write. O servidor deriva requester_id do PAT autenticado, define exemptFutureOccurrences=true e usa o padrão de duration_days para 30 quando não fornecido. Para listar isenções, passe um tamanho de página pequeno e explícito (por exemplo, filters: { "status": "Pending", "size": 5 }) e siga o _nextPageHint retornado em cada resposta.

Fluxo de trabalho de execução de isenção de segurança:

Use harness_list com resource_type="security_exemption" e um status explícito, como Pending, Approved, Rejected, Expired ou Canceled.
Use harness_execute com action="approve" e um body.scope obrigatório: CURRENT, ACCOUNT, ORG ou PROJECT. CURRENT aprova no escopo existente da isenção; os outros escopos usam o endpoint de promoção do STO internamente. O servidor preenche automaticamente body.approver_id a partir do usuário autenticado quando omitido; body.comment é opcional.
Use action="reject" para rejeitar uma isenção. body.approver_id também é preenchido automaticamente quando omitido.
Não há ação de execução separada para promote. Use action="approve" com um body.scope não CURRENT quando o resultado solicitado for aprovação no escopo de conta, organização ou projeto.

Controle de Acesso

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir
`user`	x	x
`user_group`	x	x	x	x	x
`service_account`	x	x	x		x
`role`	x	x	x		x
`role_assignment`	x		x
`resource_group`	x	x	x		x
`permission`	x

Governança

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir
`policy`	x	x	x	x	x
`policy_set`	x	x	x	x	x
`policy_evaluation`	x	x

Congelamento de Implantação

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`freeze_window`	x	x	x	x	x	`toggle_status`
`global_freeze`		x				`manage`

Substituições de Serviço

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`service_override`	x	x	x	x	x

Configurações

Tipo de Recurso	Listar	Obter	Criar	Atualizar	Excluir	Executar Ações
`setting`	x

Prompts do MCP

DevOps

Prompt	Descrição	Parâmetros
`build-deploy-app`	Fluxo de trabalho CI/CD de ponta a ponta: escaneie um repositório git, gere pipeline de CI (build & push de imagem Docker), descubra ou gere manifests K8s, crie pipeline de CD e faça deploy — com nova tentativa automática em falhas de CI (até 5 tentativas) e falhas de CD (até 3 tentativas com permissão do usuário). Quando as tentativas se esgotam, fornece links profundos da UI do Harness para todos os recursos criados para investigação manual.	`repoUrl` (obrigatório), `imageName` (obrigatório), `projectId` (opcional), `namespace` (opcional)
`debug-pipeline-failure`	Analise uma execução com falha: aceita um ID de execução, ID de pipeline ou URL do Harness. Obtém detalhamento de estágio/etapa, detalhes da falha, informações do delegate e logs da etapa com falha via `harness_diagnose`, e então fornece análise de causa raiz e correções sugeridas. Segue automaticamente falhas encadeadas de pipeline.	`executionId` (opcional), `projectId` (opcional)
`pipeline_summarizer`	Busque e resuma TODOS os logs de etapas de uma execução de pipeline. Usa `harness_diagnose` com `include_logs: true, include_all_step_logs: true` para obter o log de cada etapa e apresenta uma tabela com Nome da Etapa, Status, Duração e O Que Aconteceu (resumo baseado em log). NÃO pula nenhuma etapa.	`executionId` (opcional), `projectId` (opcional)
`create-pipeline`	Gere um novo YAML de pipeline a partir de requisitos em linguagem natural, revisando recursos existentes para contexto	`description` (obrigatório), `projectId` (opcional)
`create-agent`	Construa interativamente um agente de IA do Harness — verifique agentes existentes (detectando o formato de spec `agent.uses` atual vs. o legado `agent.step.group.steps` ao atualizar), colete requisitos, gere a spec do agente no formato apropriado, confirme com o usuário e então crie ou atualize via `harness_create`/`harness_update`	`agent_name` (obrigatório), `task_description` (obrigatório), `org_id` (opcional), `project_id` (opcional)
`onboard-service`	Conduza o onboarding de um novo serviço com ambientes e um pipeline de deploy	`serviceName` (obrigatório), `projectId` (opcional)
`dora-metrics-review`	Revise métricas DORA (frequência de deploy, taxa de falha de mudança, MTTR, lead time) com classificação Elite/Alto/Médio/Baixo e recomendações de melhoria	`teamRefId` (opcional), `dateStart` (opcional), `dateEnd` (opcional)
`setup-gitops-application`	Guie o onboarding de um aplicativo GitOps — verifique agente, cluster, repositório e crie o aplicativo	`agentId` (obrigatório), `projectId` (opcional)
`chaos-resilience-test`	Projete um experimento de caos para testar a resiliência do serviço com injeção de falhas, sondas e resultados esperados	`serviceName` (obrigatório), `projectId` (opcional)
`feature-flag-rollout`	Planeje e execute um rollout progressivo de feature flag entre ambientes com portões de segurança	`flagIdentifier` (obrigatório), `projectId` (opcional)
`migrate-pipeline-to-template`	Analise um pipeline existente e extraia templates reutilizáveis de estágio/etapa	`pipelineId` (obrigatório), `projectId` (opcional)
`delegate-health-check`	Verifique conectividade do delegate, saúde, status do token e solucione problemas de infraestrutura	`projectId` (opcional)
`developer-portal-scorecard`	Revise scorecards de IDP para serviços e identifique lacunas para melhorar a experiência do desenvolvedor	`projectId` (opcional)
`pending-approvals`	Encontre execuções de pipeline aguardando aprovação, mostre detalhes e ofereça aprovar ou rejeitar	`projectId` (opcional), `orgId` (opcional), `pipelineId` (opcional)

FinOps

Prompt	Descrição	Parâmetros
`optimize-costs`	Analise dados de custo de nuvem, apresente recomendações e anomalias, priorizadas por economia potencial	`projectId` (opcional)
`cloud-cost-breakdown`	Aprofunde-se nos custos de nuvem por serviço, ambiente ou cluster com análise de tendências e detecção de anomalias	`perspectiveId` (opcional), `projectId` (opcional)
`commitment-utilization-review`	Analise a utilização de instâncias reservadas e planos de economia para encontrar desperdícios e otimizar compromissos	`projectId` (opcional)
`cost-anomaly-investigation`	Investigue anomalias de custo — determine causa raiz, recursos impactados e remediação	`projectId` (opcional)
`rightsizing-recommendations`	Revise e priorize recomendações de redimensionamento, opcionalmente crie tickets no Jira ou ServiceNow	`projectId` (opcional), `minSavings` (opcional)

DevSecOps

Prompt	Descrição	Parâmetros
`security-review`	Revise problemas de segurança em recursos do Harness e sugira remediações por severidade	`projectId` (opcional), `severity` (opcional, padrão: `critical,high`)
`vulnerability-triage`	Faça triagem de vulnerabilidades de segurança em pipelines e artefatos, priorize por severidade e explorabilidade	`projectId` (opcional), `severity` (opcional)
`sbom-compliance-check`	Audite SBOM e postura de conformidade para artefatos — riscos de licença, violações de política, vulnerabilidades de componentes	`artifactId` (opcional), `projectId` (opcional)
`supply-chain-audit`	Auditoria de segurança de cadeia de suprimentos de software de ponta a ponta — proveniência, cadeia de custódia, conformidade de política	`projectId` (opcional)
`security-exemption-review`	Revise isenções de segurança pendentes e tome decisões de aprovação ou rejeição em lote	`projectId` (opcional)
`bulk-exemption-create`	Crie isenções de segurança justificadas para múltiplos problemas de STO com orientação explícita de escopo e duração	`projectId` (obrigatório), `exemption_type` (obrigatório), `reason` (obrigatório), filtros de problemas (opcional)
`access-control-audit`	Audite permissões de usuário, contas com privilégios excessivos e atribuições de função para aplicar o princípio do menor privilégio	`projectId` (opcional), `orgId` (opcional)

Harness Code

Prompt	Descrição	Parâmetros
`code-review`	Revisar um pull request — analisar diff, commits, verificações e comentários para fornecer feedback estruturado sobre bugs, segurança, desempenho e estilo	`repoId` (obrigatório), `prNumber` (obrigatório), `projectId` (opcional)
`pr-summary`	Gerar automaticamente um título e descrição de PR a partir do histórico de commits e diff de uma branch	`repoId` (obrigatório), `sourceBranch` (obrigatório), `targetBranch` (opcional, padrão: main), `projectId` (opcional)
`branch-cleanup`	Analisar branches em um repositório e recomendar branches obsoletas ou mescladas para exclusão	`repoId` (obrigatório), `projectId` (opcional)

Recursos MCP

URI do Recurso	Descrição	Tipo MIME
`pipeline:///{pipelineId}`	Definição YAML de pipeline	`application/x-yaml`
`pipeline:///{orgId}/{projectId}/{pipelineId}`	YAML de pipeline (com escopo explícito)	`application/x-yaml`
`executions:///recent`	Resumos das últimas 10 execuções de pipeline	`application/json`
`schema:///pipeline`	Esquema JSON de pipeline Harness	`application/schema+json`
`schema:///template`	Esquema JSON de template Harness	`application/schema+json`
`schema:///trigger`	Esquema JSON de trigger Harness	`application/schema+json`
`schema:///pipeline_v1` (Alpha)	Esquema JSON de pipeline Harness V1 (formato simplificado de stages/steps)	`application/schema+json`
`schema:///agent-pipeline`	Esquema JSON de pipeline de agente de IA Harness	`application/schema+json`
`agent-docs:///legacy-format`	Referência de formato de spec de agente legado (`agent.step.group.steps` / `PLUGIN_TASK`), lida pelo prompt `create-agent` ao atualizar um agente existente em formato legado	`text/markdown`

Filtragem de Conjuntos de Ferramentas

Por padrão, 41 de 45 conjuntos de ferramentas estão habilitados. Quatro conjuntos de ferramentas são opt-in e excluídos dos padrões:

ansible — Harness Ansible (inventários, playbooks, hosts, atividade). Opt-in porque é escopado por projeto e adiciona conceitos que muitos usuários não precisam.
autonomous_work — Harness de Desenvolvimento (trabalho autônomo). Opt-in; veja a descrição do conjunto de ferramentas para escopo.
observability-evaluations — Regras de avaliação de telemetria de produção agendadas. Opt-in porque depende do plano de controle de pontuação implantado.
registries-v3 — Harness Artifact Registry v3 (pacotes, versões, arquivos, metadados, varreduras, exceções de firewall). Opt-in até que gravações v3 sejam lançadas, para que agentes não precisem desambiguar entre registros/artefatos v1 e pacotes/versões v3.

Adicionando conjuntos de ferramentas com prefixo `+`

Use o prefixo + para incluir explicitamente conjuntos de ferramentas opt-in junto com todos os padrões:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Removendo conjuntos de ferramentas padrão

Use o prefixo - para excluir conjuntos de ferramentas que você não precisa:

# Remove chaos and ccm from defaults
HARNESS_TOOLSETS=-chaos,-ccm

Combinando + e -

# Add Ansible, remove chaos
HARNESS_TOOLSETS=+ansible,-chaos

Lista de permissões explícita

Uma lista explícita separada por vírgulas (sem prefixos) substitui os padrões completamente. Apenas os conjuntos de ferramentas listados são habilitados:

# Only expose pipelines, services, and connectors
HARNESS_TOOLSETS=pipelines,services,connectors

Nomes de conjuntos de ferramentas disponíveis:

Conjunto de Ferramentas	Tipos de Recursos
`platform`	organização, projeto
`pipelines`	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
`agents`	agente, execução_de_agente
`services`	serviço
`environments`	ambiente
`connectors`	conector, catálogo_de_conectores
`infrastructure`	infraestrutura
`secrets`	segredo
`logs`	log_de_execução
`audit`	evento_de_auditoria
`delegates`	delegado, token_de_delegado
`repositories`	repositório, branch, commit, conteúdo_de_arquivo, tag, regra_de_repo, regra_de_espaço
`registries`	registro, artefato, versão_de_artefato, arquivo_de_artefato
`file_store`	file_store
`templates`	template
`dashboards`	dashboard, dados_de_dashboard
`idp`	idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc
`pull-requests`	pull_request, pr_reviewer, pr_comment, pr_check, pr_activity
`feature-flags`	fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition, fme_metric, fme_event_type
`gitops`	gitops_agent, gitops_argo_project, gitops_app_project_mapping, gitops_autocreate_log, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree, gitops_cluster_link
`chaos`	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
`ccm`	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
`sei`	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
`scs`	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
`evidence-vault`	atestação
`sto`	security_issue, security_issue_filter, security_exemption, remediation_diff
`dbops`	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
`autonomous_work` (opt-in)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
`access_control`	usuário, grupo_de_usuários, conta_de_serviço, função, atribuição_de_função, grupo_de_recursos, permissão
`governance`	policy, policy_set, policy_evaluation
`freeze`	freeze_window, global_freeze
`overrides`	service_override
`settings`	configuração
`knowledge-graph`	kg_queryable_type_summary, kg_grammar, hql_query
`semantic-layer`	kg_type, kg_related_type
`ai-evals`	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval
`observability-evaluations` (opt-in)	observability_evaluation_rule
`iacm`	iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_provider, iacm_workspace_costs, iacm_activity_resource_change
`ansible` (opt-in)	ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity
`registries-v3` (opt-in)	package_v3, version_v3, file_v3, registry_metadata_v3, package_metadata_v3, version_metadata_v3, file_metadata_v3, metadata_key_v3, metadata_value_v3, artifact_scan_v3, bulk_scan_evaluation_v3, firewall_exception_v3, firewall_exception_version_v3
`release-management`	release_process, release_activity, release, release_execution_phase, release_execution_task, release_execution_activity, release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_input, release_execution_activity_output
`vibe`	vibe_project, vibe_app_lifecycle

Arquitetura

                 +------------------+
                 |   AI Agent       |
                 |  (Claude, etc.)  |
                 +--------+---------+
                          |  MCP (stdio or HTTP)
                 +--------v---------+
                |    MCP Server     |
                | 11 Generic Tools  |
                 +--------+---------+
                          |
                 +--------v---------+
                |    Registry       |  <-- Declarative resource definitions
                | 45 Toolsets (41 default) |
                |  255 Resource Types|
                 +--------+---------+
                          |
                 +--------v---------+
                 |  HarnessClient    |  <-- Auth, retry, rate limiting
                 +--------+---------+
                          |  HTTPS
                 +--------v---------+
                 |  Harness REST API |
                 +-------------------+

Como Funciona

Ferramentas são verbos genéricos: harness_list, harness_get, etc. Elas aceitam um parâmetro resource_type que roteia para o endpoint correto da API.
O Registro mapeia cada resource_type para um ResourceDefinition — uma estrutura de dados declarativa que especifica o método HTTP, caminho da URL, mapeamentos de parâmetros de caminho/consulta e lógica de extração de resposta.
Despacho resolve a definição do recurso, constrói a requisição HTTP (substituição de caminho, parâmetros de consulta, injeção de conta/org/projeto ciente de resource_scope), chama a API Harness por meio de HarnessClient e extrai os dados relevantes da resposta.
Filtragem de conjunto de ferramentas (HARNESS_TOOLSETS) controla quais definições de recursos são carregadas no registro na inicialização.
Saída estruturada é declarada com MCP outputSchema; harness_list converte arrays e wrappers comuns de listas em structuredContent em formato de objeto para clientes estritos.
Links profundos são automaticamente anexados às respostas, fornecendo URLs diretos da interface Harness para cada recurso.
Modo compacto remove metadados verbosos dos resultados de listas, mantendo apenas campos acionáveis (identidade, status, tipo, timestamps, links profundos) para minimizar o uso de tokens.

Adicionando um Novo Tipo de Recurso

Crie um novo arquivo em src/registry/toolsets/ ou adicione um recurso a um conjunto de ferramentas existente:

// src/registry/toolsets/my-module.ts
import type { ToolsetDefinition } from "../types.js";

export const myModuleToolset: ToolsetDefinition = {
  name: "my-module",
  displayName: "My Module",
  description: "Description of the module",
  resources: [
    {
      resourceType: "my_resource",
      displayName: "My Resource",
      description: "What this resource represents",
      toolset: "my-module",
      scope: "project",                    // "project" | "org" | "account"
      identifierFields: ["resource_id"],
      listFilterFields: ["search_term"],
      operations: {
        list: {
          method: "GET",
          path: "/my-module/api/resources",
          queryParams: { search_term: "search", page: "page", size: "size" },
          responseExtractor: (raw) => raw,
          description: "List resources",
        },
        get: {
          method: "GET",
          path: "/my-module/api/resources/{resourceId}",
          pathParams: { resource_id: "resourceId" },
          responseExtractor: (raw) => raw,
          description: "Get resource details",
        },
      },
    },
  ],
};

Em seguida, importe-o em src/registry/index.ts e adicione-o ao array ALL_TOOLSETS. Nenhuma alteração é necessária nos arquivos de ferramentas.

Desenvolvimento

# Build
pnpm build

# Watch mode
pnpm dev

# Type check
pnpm typecheck

# Run tests
pnpm test

# Watch tests
pnpm test:watch

# Interactive MCP Inspector
pnpm inspect

# Refresh generated README counts from the built registry
pnpm docs:generate

# Verify README counts and clone instructions are current
pnpm docs:check

# Sync and verify JSON Schemas used by harness_schema
pnpm sync-schemas
pnpm check-schema-coverage

Estrutura do Projeto

src/
  index.ts                          # Entrypoint, transport setup
  config.ts                         # Env var validation (Zod)
  client/
    harness-client.ts               # HTTP client (auth, retry, rate limiting)
    types.ts                        # Shared API types
  registry/
    index.ts                        # Registry class + dispatch logic
    types.ts                        # ResourceDefinition, ToolsetDefinition, etc.
    toolsets/                        # One file per toolset (declarative data)
      platform.ts
      pipelines.ts
      services.ts
      ccm.ts
      access-control.ts
      ...
  tools/                            # 11 generic MCP tools
    harness-list.ts
    harness-get.ts
    harness-create.ts
    harness-update.ts
    harness-delete.ts
    harness-execute.ts
    harness-search.ts
    harness-diagnose.ts
    harness-describe.ts
    harness-status.ts
    harness-schema.ts

  resources/                        # MCP resource providers
    pipeline-yaml.ts
    execution-summary.ts
  prompts/                          # MCP prompt templates
    build-deploy-app.ts             # DevOps: end-to-end build & deploy workflow
    debug-pipeline.ts               # DevOps: debug failed executions
    create-pipeline.ts              # DevOps: generate pipeline from requirements
    onboard-service.ts              # DevOps: onboard new service
    dora-metrics.ts                 # DevOps: DORA metrics review
    setup-gitops.ts                 # DevOps: GitOps application setup
    chaos-resilience.ts             # DevOps: chaos experiment design
    feature-flag-rollout.ts         # DevOps: progressive flag rollout
    migrate-to-template.ts          # DevOps: extract templates from pipeline
    delegate-health.ts              # DevOps: delegate health check
    developer-scorecard.ts          # DevOps: IDP scorecard review
    optimize-costs.ts               # FinOps: cost optimization
    cloud-cost-breakdown.ts         # FinOps: cost deep-dive
    commitment-utilization.ts       # FinOps: RI/savings plan analysis
    cost-anomaly.ts                 # FinOps: anomaly investigation
    rightsizing.ts                  # FinOps: rightsizing recommendations
    security-review.ts              # DevSecOps: security issue review
    vulnerability-triage.ts         # DevSecOps: vulnerability triage
    sbom-compliance.ts              # DevSecOps: SBOM compliance audit
    supply-chain-audit.ts           # DevSecOps: supply chain audit
    exemption-review.ts             # DevSecOps: exemption approval
    access-control-audit.ts         # DevSecOps: access control audit
    code-review.ts                  # Harness Code: PR code review
    pr-summary.ts                   # Harness Code: auto-generate PR summary
    branch-cleanup.ts               # Harness Code: stale branch cleanup
    pending-approvals.ts            # Approvals: find and act on pending approvals
  utils/
    cli.ts                          # CLI arg parsing (transport, port)
    errors.ts                       # Error normalization
    logger.ts                       # stderr-only logger
    progress.ts                     # MCP progress & logging notifications
    rate-limiter.ts                 # Client-side rate limiting
    deep-links.ts                   # Harness UI deep link builder
    response-formatter.ts           # Consistent MCP response formatting
    compact.ts                      # Compact list output for token efficiency
tests/
  config.test.ts                    # Config schema validation tests
  utils/
    response-formatter.test.ts
    deep-links.test.ts
    errors.test.ts
  registry/
    registry.test.ts                # Registry loading, filtering, dispatch tests

Elicitação

As ferramentas de escrita (harness_create, harness_update, harness_delete, harness_execute) usam elicitação MCP para solicitar confirmação do usuário quando o risco da ação assim o exigir — apenas operações medium_write, high_write e destructive. Criações/atualizações/leituras de baixo risco (ex.: pipeline.create, pipeline.update, hql_query.run) prosseguem silenciosamente sem prompt. Quando um prompt é exibido, o usuário vê o que está prestes a acontecer e aceita ou recusa, dando aprovação real com supervisão humana para as operações que realmente alteram ou executam coisas.

Como funciona:

O LLM chama uma ferramenta de escrita com risco medium_write+ (ex.: harness_delete, harness_execute pipeline.run). Criações/atualizações/leituras de baixo risco não exibem prompt.
O servidor envia uma solicitação de elicitação ao cliente com um resumo da operação e uma caixa de seleção confirm (marcada por padrão).
O usuário vê os detalhes e clica em Aceitar (com confirm marcado) ou Recusar / Cancelar.
Se aceito com confirm: true, a operação prossegue. Se aceito com confirm desmarcado, recusado ou cancelado, é bloqueado e o LLM é informado (uma recusa explícita é autoritativa e não é contornada por confirm: true na chamada da ferramenta).

Suporte do cliente:

Cliente	Suporte a Elicitação
Cursor	Sim
VS Code (Copilot)	Sim
Claude Desktop	Ainda não
Devin Desktop	Ainda não
MCP Inspector	Sim

O comportamento da elicitação varia conforme o risco da operação quando o suporte do cliente está ausente:

Nível de Risco	Cliente suporta elicitação	`confirm: true` passado	Comportamento
`read`, `low_write`	qualquer	qualquer	Prossegue silenciosamente — nenhum prompt é exibido (`confirm` não tem efeito neste nível de risco)
`medium_write`, `high_write`, `destructive`	Sim	qualquer	Solicita ao usuário. Prossegue somente se o usuário aceitar com `confirm: true` (o padrão do schema). Uma recusa explícita, cancelamento ou aceite com `confirm: false` (usuário desmarcou a caixa) é autoritativo e não é contornado por `confirm: true` na chamada da ferramenta. Um aceite sem o campo `confirm` é tratado como falha do cliente em exibir um prompt utilizável — recuperável tentando novamente com `confirm: true`
`medium_write`, `high_write`, `destructive`	Não	Não	BLOQUEAR (retornar erro com dica para tentar novamente com `confirm: true`)
`medium_write`, `high_write`, `destructive`	Não	Sim	Prossegue (aceite explícito para automação não interativa)
qualquer (até `HARNESS_AUTO_APPROVE_RISK`)	qualquer	qualquer	Aprova automaticamente sem solicitar

Se elicitInput falhar em tempo de execução (erro de transporte, método não suportado) para uma operação medium_write+, a chamada é bloqueada a menos que o chamador passe confirm: true. confirm: true é respeitado como fallback quando o cliente não conseguiu exibir um prompt ou retornou um aceite degenerado ({action: "accept"} sem o campo de confirmação), mas não substitui uma recusa/cancelamento explícito de um cliente que completou o handshake de elicitação.

Modo Autônomo

Modo autônomo significa que o servidor prossegue com todas as operações — incluindo escritas e ações destrutivas — sem solicitar confirmação. Ative-o definindo:

HARNESS_AUTO_APPROVE_RISK=all

Este é o teto no nível de implantação: uma vez definido, sessões individuais não podem escalar além dele (embora possam escolher um limite mais rigoroso por sessão via cabeçalho x-harness-auto-approve-risk).

Ou na configuração do seu cliente MCP:

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "HARNESS_AUTO_APPROVE_RISK": "all"
      }
    }
  }
}

Autonomia parcial: Você também pode aprovar automaticamente apenas até um nível de risco específico enquanto ainda solicita confirmação para operações de maior risco:

# Auto-approve reads and low-risk writes; prompt for medium_write, high_write, destructive
HARNESS_AUTO_APPROVE_RISK=low_write

# Auto-approve up to high-risk writes; only prompt for destructive operations
HARNESS_AUTO_APPROVE_RISK=high_write

Valor	O que é aprovado automaticamente
`none` (padrão)	Nada — nenhum limite de aprovação automática
`low_write`	Leituras + escritas de baixo risco
`medium_write`	Leituras + escritas de baixo e médio risco
`high_write`	Leituras + escritas de baixo, médio e alto risco
`all`	Tudo, incluindo operações destrutivas

Aviso do modo autônomo: HARNESS_AUTO_APPROVE_RISK=all pula a confirmação para todas as operações, incluindo harness_delete. Use com cautela e considere combinar com HARNESS_TOOLSETS para restringir quais tipos de recursos estão disponíveis.

Nota de migração: HARNESS_SKIP_ELICITATION=true ainda é suportado e mapeia para HARNESS_AUTO_APPROVE_RISK=all. Um aviso de depreciação é registrado no stderr. Se ambos forem definidos, HARNESS_AUTO_APPROVE_RISK tem precedência.

Segurança

Segredos nunca são expostos. O tipo de recurso secret retorna apenas metadados (nome, tipo, escopo) — valores de segredos nunca são incluídos em nenhuma resposta.
Operações que exigem confirmação usam elicitação quando disponível. Quando uma ação de escrita ou execução tem risco medium_write, high_write ou destructive, harness_create, harness_update, harness_delete e harness_execute tentam elicitação MCP antes de prosseguir (veja Elicitação). Ações de baixo risco (read, low_write — ex.: pipeline.create, pipeline.update, hql_query.run) prosseguem silenciosamente sem prompt.
Risco médio e acima falham de forma fechada. Se a confirmação não puder ser obtida para operações medium_write, high_write ou destructive, elas são bloqueadas em vez de executadas às cegas. Substitua com HARNESS_AUTO_APPROVE_RISK para fluxos de trabalho autônomos.
CORS restrito à mesma origem. O transporte HTTP permite apenas requisições de mesma origem, prevenindo ataques CSRF de sites maliciosos direcionados ao servidor MCP no localhost.
Limitação de taxa HTTP. O transporte HTTP aplica 60 requisições por minuto por IP para prevenir inundação de requisições.
Limitação de taxa da API. O cliente da API Harness aplica um limite de 10 requisições/segundo para evitar atingir limites de taxa upstream.
Limites de paginação aplicados. Consultas de listas são limitadas a 10.000 itens no total e 100 por página para prevenir esgotamento de memória.
Tentativas com backoff. Falhas transitórias (HTTP 429, 5xx) são tentadas novamente com backoff exponencial e jitter.
Vinculação ao localhost. O transporte HTTP vincula-se a 127.0.0.1 por padrão — não acessível pela rede.
Sem registro em stdout. Todos os logs vão para stderr para evitar corromper o transporte JSON-RPC stdio.

Habilidades Complementares

O servidor MCP Harness combina bem com Harness Skills — uma coleção de habilidades prontas do Claude Code (comandos de barra) projetadas para fluxos de trabalho comuns do Harness. Instale-os junto com este servidor MCP para obter automação de alto nível como /deploy, /rollback, /triage e muito mais sem escrever prompts personalizados.

Solução de Problemas & Armadilhas Comuns

Sintoma	Causa provável	O que fazer
`HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...`	A chave de API não está em um formato com escopo de conta suportado (`pat.<accountId>...` ou `sat.<accountId>...`), então o ID da conta não pode ser inferido	Defina `HARNESS_ACCOUNT_ID` explicitamente
`Unknown transport: "..."` na inicialização	Argumento de transporte CLI não suportado	Use apenas `stdio` ou `http`
`Invalid HARNESS_TOOLSETS: ...` na inicialização	Um ou mais nomes de conjuntos de ferramentas não são reconhecidos	Use apenas nomes de Filtragem de Conjuntos de Ferramentas (correspondência exata)
HTTP `mcp-session-id header is required...`	Uma solicitação de sessão foi enviada sem o cabeçalho de sessão	Envie `initialize` primeiro e, em seguida, inclua `mcp-session-id` em `POST/GET/DELETE /mcp`
HTTP `Session not found...`	A sessão expirou após `MCP_SESSION_TTL_MS` milissegundos ociosos ou já foi encerrada	Execute novamente `initialize` para criar uma nova sessão e tente novamente com o novo cabeçalho
HTTP `405 Method Not Allowed` em `/mcp`	Método não suportado para o endpoint MCP	Use apenas `POST`, `GET`, `DELETE` ou `OPTIONS`
HTTP `Invalid request`	Corpo JSON inválido ou corpo da solicitação excedeu `HARNESS_MAX_BODY_SIZE_MB`	Valide o tamanho/formato do payload JSON; aumente `HARNESS_MAX_BODY_SIZE_MB` se necessário
`Unknown resource_type "..."` das ferramentas	O tipo de recurso está com erro de digitação ou foi filtrado via `HARNESS_TOOLSETS`	Chame `harness_describe` (com `search_term` opcional) para descobrir tipos válidos
`Missing required field "... for path parameter ..."`	Uma chamada com escopo de projeto/org está sem identificadores	Defina `HARNESS_ORG`/`HARNESS_PROJECT` ou passe `org_id`/`project_id` por chamada de ferramenta
`resource_scope "org" requires org_id...` ou `resource_scope "project" requires project_id...`	Um recurso de múltiplos escopos foi forçado ao escopo org/projeto sem identificadores suficientes	Passe os `org_id`/`project_id` ausentes, configure `HARNESS_ORG`/`HARNESS_PROJECT` ou use `resource_scope: "account"` quando suportado
`Read-only mode is enabled ... operations are not allowed`	`HARNESS_READ_ONLY=true` bloqueia criar/atualizar/excluir/executar	Defina `HARNESS_READ_ONLY=false` se operações de escrita forem pretendidas
A execução do pipeline falha na pré-validação com entradas obrigatórias não resolvidas	O `inputs` fornecido não cobriu os placeholders de tempo de execução obrigatórios	Busque `runtime_input_template`, forneça chaves simples ausentes ou use `input_set_ids` para entradas estruturais
A abreviação de CI do pipeline (`branch`, `tag`, `pr_number`, `commit_sha`) não foi aplicada	`inputs.build` já foi fornecido, então a expansão da abreviação foi intencionalmente ignorada	Remova `inputs.build` para usar a expansão da abreviação, ou mantenha a estrutura completa explícita de `build`
A execução do pipeline carregou a revisão YAML errada	A definição do pipeline é armazenada no Git e a execução não especificou o branch desejado do pipeline	Passe `params.pipeline_branch` na ação `run`; isso mapeia para `branch` do Harness
`wait: true` retornou `_wait.error`	O gatilho do pipeline foi bem-sucedido, mas a sondagem no lado do servidor falhou	Verifique novamente o `execution_id` com `harness_get(resource_type="execution", ...)` antes de decidir se deve executar novamente
`wait: true` retornou `execution_timed_out: true`	A execução não atingiu um status terminal antes de `wait_timeout_seconds`	Use o `execution_id` retornado para verificar novamente o status; aguarde um status terminal antes de executar `harness_diagnose`
Os logs de execução estão vazios ou os downloads de blobs retornam 403	As URLs de blobs de logs hospedados pelo Harness exigem o caminho de cliente/auth do Harness configurado, especialmente para hosts internos ou autogerenciados	Mantenha `HARNESS_BASE_URL` apontado para o host Harness de destino e use `harness_get(resource_type="execution_log", ...)` ou `harness_diagnose(..., include_logs=true)` em vez de contornar o cliente MCP
`Operation declined by user` / `Operation cancelled by user`	O usuário recusou ou cancelou o diálogo de confirmação de elicitação — autoritativo	Verifique os detalhes da operação com o usuário; `confirm: true` não contorna uma recusa explícita. O usuário deve aceitar o prompt
`Operation blocked: the client could not surface a usable confirmation prompt`	O cliente não tem suporte a elicitação, `elicitInput` falhou ou retornou uma aceitação degenerada	Tente novamente com `confirm: true` para automação não interativa, ou use um cliente que suporte elicitação
`body.template_yaml (or body.yaml) is required` para criar/atualizar modelo	As APIs de modelo esperam payload YAML completo	Forneça a string completa de `template_yaml` em `body`; para exclusões, passe `version_label` para excluir uma versão (omita para excluir todas as versões)
`HARNESS_BASE_URL must use HTTPS` na inicialização	`HARNESS_BASE_URL` está definido como uma URL HTTP	Use HTTPS, ou defina `HARNESS_ALLOW_HTTP=true` para desenvolvimento local

Licença

MIT

Harness

O que você pode fazer com Harness MCP?

Documentação

Servidor MCP Harness 2.0

Por que usar este servidor MCP

Pré-requisitos

Início Rápido

Opção 0: MCP Harness Hospedado

Opção 1: npx (Recomendado)

Opção 2: Instalação Global

Opção 3: Compilar a partir do Código Fonte

Pacote do Diretório MCP da Anthropic

Uso via CLI

Transporte HTTP

Modo OAuth HarnessID

Modo Multi-Usuário

Configuração do Cliente

MCP Harness Hospedado

Claude Desktop (claude_desktop_config.json)

Claude Code (via claude mcp add)

Cursor (.cursor/mcp.json)

Devin Desktop (~/.windsurf/mcp.json)

MCP Gateway

Docker MCP Gateway

Portkey

LiteLLM

Envoy AI Gateway

Kong

Outros Gateways

Docker

Kubernetes

Configuração

Pesquisa Semântica

Aplicação de HTTPS

Registro de Auditoria

Referência de Ferramentas

Fluxo de Trabalho de Consulta de Esquema

Exemplos de Ferramentas

Fluxo de Trabalho de Execução de Pipeline (Recomendado)

Execução Dinâmica de Pipeline

Forense de Entrada de Execução

Modo de Espera de Execução de Pipeline

Modos de Armazenamento de Pipeline

Tipos de Recursos

Plataforma

Pipelines

Agentes de IA

Serviços

Ambientes

Conectores

Infraestrutura

Segredos

Logs de Execução

Trilha de Auditoria

Delegados

Repositórios de Código

Registros de Artefatos

File Store

Templates

Dashboards

Database DevOps

Gerenciamento de Infraestrutura como Código (IaCM)

Portal Interno de Desenvolvedores (IDP)

Pull Requests

Gerenciamento de Releases

Vibração

Feature Flags

GitOps

Chaos Engineering

Gerenciamento de Custos na Nuvem (CCM)

Insights de Engenharia de Software (SEI)

Garantia de Segurança da Cadeia de Suprimentos de Software (SCS)

Cofre de Evidências

Orquestração de Testes de Segurança (STO)

Controle de Acesso

Governança

Congelamento de Implantação

Substituições de Serviço

Configurações

Prompts do MCP

Claude Desktop (`claude_desktop_config.json`)

Claude Code (via `claude mcp add`)

Cursor (`.cursor/mcp.json`)

Devin Desktop (`~/.windsurf/mcp.json`)

Adicionando conjuntos de ferramentas com prefixo `+`