Harness

oficial

Accede e interactúa con los datos de la plataforma Harness, incluyendo pipelines, repositorios, logs y registros de artefactos.

GitHub

104

Prueba este MCPPatrocinado

¿Qué puedes hacer con Harness MCP?

Listar recursos de Harness — Pídele a tu IA que liste organizaciones, proyectos, pipelines u otros recursos usando harness_list.
Recuperar detalles de recursos — Obtén detalles completos de cualquier recurso de Harness, como un pipeline o servicio, mediante harness_get.
Crear nuevos recursos — Indica a tu IA que cree pipelines, servicios u otras entidades con harness_create.
Descubrimiento entre proyectos — Pide ejecuciones fallidas o recursos en todos los proyectos; el agente navega dinámicamente la jerarquía de la cuenta.
Autenticación multiusuario — En implementaciones compartidas, cada sesión puede autenticarse con su propia clave de API de Harness mediante el encabezado x-harness-api-key.

Documentación

Servidor MCP de Harness 2.0

Un servidor MCP (Model Context Protocol) que brinda a los agentes de IA acceso completo a la plataforma Harness.io a través de 11 herramientas consolidadas y 255 tipos de recursos.

Por qué usar este servidor MCP

La mayoría de los servidores MCP asignan una herramienta por endpoint de API. Para una plataforma tan amplia como Harness, eso significa más de 240 herramientas, y los LLM empeoran en la selección de herramientas a medida que aumenta la cantidad. Las ventanas de contexto se llenan con esquemas, y cada nuevo endpoint implica nuevo código.

Este servidor está construido de manera diferente:

11 herramientas, 255 tipos de recursos. Un sistema de despacho basado en registro enruta harness_list, harness_get, harness_create, etc. a cualquier recurso de Harness: pipelines, servicios, entornos, organizaciones, proyectos, feature flags, datos de costos y más. El LLM elige entre 11 herramientas en lugar de cientos.
Cobertura completa de la plataforma. 41 conjuntos de herramientas predeterminados que abarcan CI/CD, GitOps, Feature Flags, Gestión de Costos en la Nube, Pruebas de Seguridad, Ingeniería del Caos, DevOps de Bases de Datos, Portal Interno para Desarrolladores, Cadena de Suministro de Software, Gestión de Infraestructura como Código, Gestión de Lanzamientos, Gobernanza, Anulaciones de Servicios, Grafo de Conocimiento y más. La cobertura opcional de Ansible y evaluación de observabilidad está disponible cuando se necesita.
Flujos de trabajo multi-proyecto listos para usar. Los agentes descubren organizaciones y proyectos dinámicamente, sin necesidad de variables de entorno codificadas. Pregunta "muestra ejecuciones fallidas en todos los proyectos" y el agente puede navegar por toda la jerarquía de la cuenta.
35 plantillas de prompts. Prompts preconstruidos para flujos de trabajo comunes: compilar e implementar aplicaciones de principio a fin, depurar pipelines fallidos, revisar métricas DORA, clasificar vulnerabilidades, optimizar costos en la nube, auditar control de acceso, planificar despliegues de feature flags, revisar pull requests, aprobar pipelines pendientes y más.
Funciona en todas partes. Transporte Stdio para clientes locales (Claude Desktop, Cursor, Devin Desktop), transporte HTTP para implementaciones remotas/compartidas, listo para Docker y Kubernetes.
Inicio sin configuración. Solo proporciona una clave API de Harness. El ID de cuenta se extrae automáticamente de los tokens PAT y SAT, los valores predeterminados de organización/proyecto son opcionales, y el filtrado de conjuntos de herramientas te permite exponer solo lo que necesitas.
Extensible por diseño. Agregar un nuevo recurso de Harness significa agregar un archivo de datos declarativo: sin registro de nuevas herramientas, sin cambios de esquema, sin actualizaciones de prompts.

Requisitos previos

Antes de instalar o ejecutar el servidor, necesitas una clave API de Harness:

Inicia sesión en tu cuenta de Harness
Ve a Mi Perfil → Claves API → + Nueva Clave API
Crea un nuevo Token bajo la clave API: esto genera un PAT o SAT en el formato <prefix>.<accountId>.<tokenId>.<secret>
Guarda el token en un lugar seguro: lo necesitarás en el siguiente paso

Para instrucciones detalladas, consulta la Guía de inicio rápido de la API de Harness.

Inicio rápido

Opción 0: Harness MCP alojado

Si tu cuenta de Harness tiene habilitado el servicio MCP alojado, los clientes que admiten servidores MCP remotos pueden conectarse directamente al endpoint administrado en lugar de ejecutar el servidor localmente.

Importante: El servicio MCP alojado utiliza OAuth de la Plataforma Harness, no HARNESS_API_KEY. También debe estar habilitado/configurado por cuenta por Soporte de Harness antes de que el endpoint pueda usarse.

Consulta Harness MCP alojado para ver ejemplos de configuración.

Opción 1: npx (Recomendado)

No se requiere instalación, solo ejecútalo:

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

O configura la clave API en tu cliente de IA (consulta Configuración del cliente a continuación).

# 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: El ID de cuenta se extrae automáticamente de los tokens PAT y SAT (pat.<accountId>... o sat.<accountId>...), por lo que HARNESS_ACCOUNT_ID solo se necesita para claves API sin un segmento de cuenta integrado.

Opción 2: Instalación global

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Opción 3: Compilar desde el código fuente

Para desarrollo o personalización:

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

Paquete del directorio MCP de Anthropic

El manifiesto del paquete MCPB se encuentra en [mcp-directory/](mcp-directory/), y el ícono del paquete de 512×512 se rastrea en [icon.png](icon.png) en la raíz del repositorio. El archivo empaquetado contiene manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json a nivel de raíz, y node_modules/ de producción.

Para mantener el archivo pequeño, compila los paquetes MCPB desde un directorio de preparación:

pnpm prepare:mcpb

El directorio de preparación se escribe en dist/mcpb/ con dependencias de producción instaladas desde npm-shrinkwrap.json usando el diseño plano de npm. La CLI oficial fijada de MCPB lo valida y crea dist/harness-mcp-server-<version>.mcpb.

Las etiquetas de versión que coinciden con v*.*.* publican ese paquete en la Release correspondiente de GitHub automáticamente. Para rellenar una release existente sin volver a publicar npm, ejecuta el flujo de trabajo Release manualmente con su entrada release_tag (por ejemplo, v3.2.20). El flujo de trabajo verifica y compila esa etiqueta exacta antes de reemplazar solo su activo MCPB versionado.

Uso de 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

El transporte predeterminado es stdio si no se especifica. Usa http para implementaciones remotas/compartidas.

Transporte HTTP

Cuando se ejecuta en modo HTTP, el servidor expone:

Endpoint	Método	Descripción
`/mcp`	`POST`	Endpoint MCP JSON-RPC (solicitudes de inicialización + sesión)
`/mcp`	`GET`	Flujo SSE para mensajes iniciados por el servidor (progreso, elicitación)
`/mcp`	`DELETE`	Terminar una sesión MCP activa
`/mcp`	`OPTIONS`	Preflight CORS
`/health`	`GET`	Verificación de salud: devuelve `{ "status": "ok", "sessions": <count> }`
`/.well-known/oauth-protected-resource`	`GET`	Metadatos RFC 9728 cuando `HARNESS_MCP_MODE=oauth`
`/.well-known/oauth-protected-resource/mcp`	`GET`	Metadatos RFC 9728 sensibles a la ruta para el recurso `/mcp` predeterminado

El transporte HTTP se ejecuta en modo basado en sesión. Se crea una nueva sesión MCP en initialize, el servidor devuelve un encabezado mcp-session-id, y las solicitudes posteriores para esa sesión deben incluir el mismo encabezado.

Restricciones operativas en modo HTTP:

Establece HARNESS_MCP_AUTH_TOKEN para implementaciones de un solo usuario y multiusuario compartidas o accesibles de forma remota. Cuando se establece, cada solicitud POST, GET y DELETE a /mcp debe incluir Authorization: Bearer <token>.
El modo OAuth acepta tokens de acceso de HarnessID en lugar de HARNESS_MCP_AUTH_TOKEN y puede vincularse a una dirección que no sea de bucle local sin la exclusión no autenticada.
Los enlaces de un solo usuario y multiusuario que no sean de bucle local requieren HARNESS_MCP_AUTH_TOKEN de forma predeterminada. Para ejecutar sin autenticación en una interfaz que no sea de bucle local de todos modos, establece HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true explícitamente.
POST /mcp sin mcp-session-id debe ser una solicitud initialize.
POST /mcp, GET /mcp y DELETE /mcp para sesiones existentes requieren el encabezado mcp-session-id.
GET /mcp se usa para notificaciones SSE (actualizaciones de progreso y prompts de elicitación).
Las sesiones inactivas se eliminan después de MCP_SESSION_TTL_MS milisegundos una vez que no hay solicitud ni flujo SSE activo (predeterminado 1800000, o 30 minutos).
GET /health es el único endpoint que no es MCP.
El tamaño del cuerpo de la solicitud está limitado por HARNESS_MAX_BODY_SIZE_MB (predeterminado 10 MB).
Establece x-harness-pipeline-version: 0 o 1 en la solicitud initialize para seleccionar recursos de pipeline V0 o V1 para esa sesión HTTP.
Establece x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all en la solicitud initialize para elegir un umbral de aprobación automática por sesión más estricto. El servidor limita este valor al HARNESS_AUTO_APPROVE_RISK a nivel de implementación, por lo que una sesión puede reducir pero no ampliar el techo de aprobación configurado.

Modo OAuth de HarnessID

Establece HARNESS_MCP_MODE=oauth para permitir que los clientes MCP remotos descubran HarnessID y completen OAuth 2.1 Código de Autorización con PKCE. El modo OAuth solo está disponible con transporte HTTP. Los valores predeterminados de producción de HarnessID, recurso MCP y enrutamiento de API de Harness están integrados:

HARNESS_MCP_MODE=oauth

Esto predetermina al emisor https://id.harness.io/idp/realms/HarnessIDP, recurso https://mcp.harness.io/mcp, cliente OAuth mcp-client y base de API de Harness https://mcp.harness.io/cli. Anúlelos solo para QA, desarrollo local u otro entorno de Harness.

HARNESS_API_KEY no debe establecerse en este modo. HARNESS_MCP_OAUTH_JWKS_URI predetermina a <issuer>/protocol/openid-connect/certs, y HARNESS_ACCOUNT_ID es innecesario porque la cuenta proviene del token.

El servidor publica metadatos de recurso protegido RFC 9728 y devuelve este desafío cuando un cliente no se ha autenticado:

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

Valida la firma RS256 del token de acceso de HarnessID, iss, expiración y sub usando el endpoint JWKS configurado, y verifica que el token fue emitido a HARNESS_MCP_OAUTH_CLIENT_ID a través de la declaración azp. HARNESS_MCP_OAUTH_RESOURCE es el identificador de recurso protegido RFC 9728 utilizado para descubrimiento y desafíos. Los tokens de acceso actuales de HarnessID usan aud: account en lugar de la URL MCP, por lo que el recurso no se compara con aud.

El ID de cuenta proviene de la declaración HARNESS_MCP_OAUTH_ACCOUNT_CLAIM del token (account_id por defecto), que el alcance organization de HarnessID completa. Cada sesión almacena el token de acceso del llamante y lo reenvía a la API de Harness como Authorization: Bearer, por lo que el RBAC de Harness y los registros de auditoría reflejan al usuario conectado en lugar de un PAT compartido. La sesión está vinculada al sub y la cuenta con la que se creó: una solicitud posterior puede llevar un token renovado, pero uno para un usuario o cuenta diferente se rechaza.

Los clientes normalmente solo necesitan la URL del recurso MCP:

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

El cliente lee los metadatos del recurso protegido, descubre HARNESS_MCP_OAUTH_ISSUER y luego usa los metadatos RFC 8414 de ese servidor de autorización. Si el cliente no admite registro dinámico de clientes, usa el ID de cliente mcp-client pre-registrado.

Consulta OAuth de HarnessID para un servidor MCP autoalojado para la lista de verificación de QA Keycloak y los comandos de validación.

Modo multiusuario

Establece HARNESS_MCP_MODE=multi-user para implementaciones HTTP compartidas donde cada cliente se autentica como un usuario diferente de Harness. En este modo:

HARNESS_API_KEY no debe establecerse en la configuración del servidor: el servidor no contiene credenciales de Harness.
Cada sesión debe proporcionar x-harness-api-key en la solicitud initialize. x-harness-account-id solo se requiere cuando la clave API no incorpora un segmento de cuenta.
Las sesiones también pueden proporcionar encabezados x-harness-org y x-harness-project para establecer el alcance predeterminado de esa sesión.
La clave API de Harness fluye a través de cada llamada a la API de Harness para esa sesión, por lo que el rastro de auditoría en Harness refleja al usuario real.
HARNESS_MCP_AUTH_TOKEN es independiente y aún puede usarse como una puerta adicional a nivel 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 la validación del encabezado Host para protección contra rebinding de DNS, y CORS limita los orígenes del navegador. Ninguno es autenticación; usa HARNESS_MCP_AUTH_TOKEN o una puerta de enlace/proxy inverso autenticado para el control de acceso.

Configuración del cliente

Nota: HARNESS_ORG y HARNESS_PROJECT son opcionales. Establecen el ID de organización y el ID de proyecto utilizados cuando no se especifican por llamada de herramienta. Los agentes pueden descubrir organizaciones y proyectos dinámicamente usando harness_list(resource_type="organization") y harness_list(resource_type="project"). Los nombres obsoletos HARNESS_DEFAULT_ORG_ID y HARNESS_DEFAULT_PROJECT_ID aún se aceptan por compatibilidad con versiones anteriores.

Harness MCP alojado

Harness también admite un endpoint MCP alojado para cuentas que tienen habilitado el servicio administrado. Esto es útil cuando deseas un endpoint MCP remoto compartido en lugar de ejecutar npx harness-mcp-v2 o autoalojar el transporte HTTP tú mismo.

Importante: La autenticación de MCP alojado utiliza OAuth de la Plataforma Harness. No utiliza HARNESS_API_KEY en la configuración del cliente. La disponibilidad de MCP alojado se configura por cuenta de Harness, por lo que deberá trabajar con Soporte de Harness para habilitar/configurar el ajuste antes de usarlo.

El endpoint alojado https://mcp.harness.io/mcp es un servicio administrado. La configuración de MCP del lado del cliente en Claude, Cursor o Cowork no puede anular a qué entorno de Harness se enruta. Para Harness0 u otro entorno SaaS privado de Harness, solicite a Soporte de Harness que habilite/configure MCP alojado para ese entorno, o ejecute el servidor local/autohospedado y establezca HARNESS_BASE_URL al host de Harness de destino.

Ejemplo de MCP alojado:

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

Ejemplo con entradas tanto alojadas como locales:

{
  "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"
      }
    }
  }
}

Solución de problemas de npx ENOENT o node: No such file or directory

Esto es un fallo de lanzamiento del proceso del cliente, no un fallo de autenticación de Harness. El servidor MCP aún no se ha iniciado, por lo que cambiar HARNESS_API_KEY no afectará a spawn npx ENOENT.

Las aplicaciones GUI (Cursor, Claude Desktop, Devin Desktop, VS Code) no siempre heredan el PATH de su shell, por lo que pueden fallar al encontrar npx o node después de una recarga de configuración. Solucione esto usando rutas absolutas y estableciendo explícitamente PATH en el bloque 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"
      }
    }
  }
}
Encuentre sus rutas con which npx y which node en una terminal, luego asegúrese de que el directorio que contiene node esté incluido en el valor de PATH anterior. Ubicaciones comunes:

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

nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (ejecute nvm which current para encontrar la ruta exacta)

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

Claude Desktop (`claude_desktop_config.json`)

npx (instalación cero)

{
  "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 (instalación 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 (a través de `claude mcp add`)

npx (instalación cero)

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

node (instalación local)

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

Luego establezca HARNESS_API_KEY en su entorno o archivo .env.

Cursor (`.cursor/mcp.json`)

npx (instalación cero, recomendado para configuraciones locales de 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"
      }
    }
  }
}

Ejecute which npx en una terminal y use esa ruta completa para command; incluya el directorio de which node al frente de PATH.

node (instalación 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"
      }
    }
  }
}

Ejecute which harness-mcp-v2 después de npm install -g harness-mcp-v2 y use esa ruta completa para command; incluya el directorio de which node al frente de PATH.

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

npx (instalación cero)

{
  "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 (instalación 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 una compilación local desde el código fuente?

Reemplace el comando con la ruta a su index.js compilado:

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

Puerta de enlace MCP

El servidor MCP de Harness es totalmente compatible con puertas de enlace MCP — proxies inversos que proporcionan autenticación centralizada, gobernanza, enrutamiento de herramientas y observabilidad en múltiples servidores MCP. Dado que el servidor implementa el protocolo MCP estándar con transportes stdio y HTTP, funciona detrás de cualquier puerta de enlace compatible con MCP sin cambios de código.

¿Por qué usar una puerta de enlace?

Gestión centralizada de credenciales — sin claves API en configuraciones de agentes
Registro de gobernanza y auditoría para todas las llamadas de herramientas entre equipos
Un único endpoint para agentes en lugar de N conexiones a N servidores MCP
Control de acceso — restringir qué equipos pueden usar qué herramientas

Puerta de enlace MCP de Docker

Registre el servidor en su configuración de puerta de enlace MCP de Docker:

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

Portkey

Agregue el servidor MCP de Harness a su Puerta de enlace MCP de Portkey para gobernanza empresarial, seguimiento de costos y enrutamiento multi-LLM:

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

LiteLLM

Agregue a su configuración de proxy LiteLLM:

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

Envoy AI Gateway

El servidor funciona con soporte MCP de Envoy AI Gateway a través del transporte HTTP:

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

Luego configure Envoy para enrutar a http://localhost:8080/mcp como backend MCP ascendente.

Kong

Use el plugin de proxy MCP de IA de Kong para exponer el servidor MCP de Harness a través de su infraestructura de puerta de enlace Kong existente.

Otras puertas de enlace

Cualquier puerta de enlace que admita la especificación MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, etc.) puede actuar como proxy para este servidor. Para puertas de enlace basadas en stdio, use el transporte predeterminado. Para puertas de enlace basadas en HTTP, inicie el servidor con el transporte http y apunte la puerta de enlace al endpoint /mcp.

Docker

Compile y ejecute el servidor como un contenedor 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

El contenedor se ejecuta en modo HTTP en el puerto 3000 por defecto con una verificación de salud integrada.

Kubernetes

Implemente en un clúster de Kubernetes usando los manifiestos proporcionados:

# 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

La implementación ejecuta 2 réplicas con sondas de preparación/viveza, límites de recursos y contexto de seguridad sin root. El Servicio expone el puerto 80 internamente (apuntando al puerto 3000 del contenedor).

Configuración

El servidor carga automáticamente las variables de entorno de un archivo .env en la raíz del proyecto si existe. Copie .env.example a .env y complete sus valores. Las variables de entorno también se pueden establecer a través de su shell o la configuración del cliente MCP.

Variable	Requerido	Predeterminado	Descripción
`HARNESS_MCP_MODE`	No	`single-user`	Modo de despliegue: `single-user` (clave API compartida), `multi-user` (HTTP con claves API por sesión) o `oauth` (HTTP con validación de token de acceso HarnessID)
`HARNESS_API_KEY`	Sí*	--	Token de acceso personal de Harness o token de cuenta de servicio. Requerido en modo `single-user`. NO debe configurarse en modo `multi-user` o `oauth`, donde cada sesión aporta su propia credencial
`HARNESS_ACCOUNT_ID`	No	(del PAT/SAT)	Identificador de cuenta de Harness. Se extrae automáticamente de los tokens PAT/SAT en modo de usuario único; las sesiones multiusuario pueden proporcionar el suyo propio mediante `x-harness-account-id` cuando la clave API no incluye uno
`HARNESS_BASE_URL`	No	`https://app.harness.io` (`https://mcp.harness.io/cli` en modo OAuth)	URL base de API/UI de Harness. El modo OAuth enruta a través del proxy MCP `/cli` alojado de forma predeterminada; otros modos usan la API SaaS de Harness directamente
`HARNESS_MCP_OAUTH_ISSUER`	No	`https://id.harness.io/idp/realms/HarnessIDP`	Emisor de HarnessID comparado exactamente contra la reclamación `iss` del token de acceso
`HARNESS_MCP_OAUTH_RESOURCE`	No	`https://mcp.harness.io/mcp`	URL MCP canónica pública publicada como identificador de recurso RFC 9728
`HARNESS_MCP_OAUTH_JWKS_URI`	No	`<issuer>/protocol/openid-connect/certs`	Endpoint JWKS de HarnessID utilizado para validar firmas de token de acceso RS256
`HARNESS_MCP_OAUTH_CLIENT_ID`	No	`mcp-client`	Cliente de HarnessID al que debe emitirse el token de acceso, verificado contra la reclamación `azp` del token
`HARNESS_MCP_OAUTH_ACCOUNT_CLAIM`	No	`account_id`	Reclamación del token de acceso que contiene el ID de cuenta de Harness, poblada por el alcance `organization` de HarnessID
`HARNESS_MCP_OAUTH_SCOPES`	No	`openid profile email organization`	Alcances separados por espacios anunciados en los metadatos de recursos protegidos RFC 9728
`HARNESS_FME_API_KEY`	No	--	Credencial opcional de administrador FME/Split de usuario único/autohospedado utilizada para recursos `fme_` solo en modo legado (`workspace_id`). El FME legado no está disponible en modo OAuth, por lo que los tokens de HarnessID nunca se envían a `api.split.io`; use el alcance nativo de Harness `org_id`+`project_id` en su lugar. No debe configurarse en modo `multi-user` o `oauth`
`HARNESS_FME_BASE_URL`	No	`https://api.split.io`	URL base de API de administrador Split/FME utilizada por recursos `fme_` solo en modo legado (`workspace_id`). Las URL HTTP requieren `HARNESS_ALLOW_HTTP=true` para desarrollo local. El modo nativo de Harness (`org_id`+`project_id`) ignora esto y usa el estándar `HARNESS_API_KEY`/`HARNESS_BASE_URL` en su lugar
`HARNESS_ORG`	No	--	ID de organización. Se usa cuando `org_id` no se especifica por llamada de herramienta. Si se omite, `org_id` debe proporcionarse explícitamente. Los agentes también pueden descubrir organizaciones dinámicamente mediante `harness_list(resource_type="organization")`
`HARNESS_PROJECT`	No	--	ID de proyecto. Se usa cuando `project_id` no se especifica por llamada de herramienta. Los agentes también pueden descubrir proyectos dinámicamente mediante `harness_list(resource_type="project")`
`HARNESS_API_TIMEOUT_MS`	No	`30000`	Tiempo de espera de solicitud HTTP en milisegundos
`HARNESS_MAX_RETRIES`	No	`3`	Número de reintentos para fallos transitorios (429, 5xx)
`HARNESS_MAX_BODY_SIZE_MB`	No	`10`	Tamaño máximo del cuerpo de solicitud HTTP en MB para transporte `http`
`HARNESS_RATE_LIMIT_RPS`	No	`10`	Limitación de solicitudes del lado del cliente (solicitudes por segundo) a las APIs de Harness
`LOG_LEVEL`	No	`info`	Verbosidad de registro: `debug`, `info`, `warn`, `error`
`HARNESS_TOOLSETS`	No	(predeterminados)	Lista de conjuntos de herramientas separados por comas. Vacío carga los conjuntos de herramientas predeterminados. Admite `+name` para incluir explícitamente conjuntos de herramientas opcionales y `-name` para eliminar los predeterminados (ver Filtrado de conjuntos de herramientas)
`HARNESS_READ_ONLY`	No	`false`	Bloquear todas las operaciones de mutación (crear, actualizar, eliminar, ejecutar). Solo se permiten listar y obtener. Útil para entornos compartidos/demo
`HARNESS_AUTO_APPROVE_RISK`	No	`none`	Umbral de aprobación automática basado en riesgo para flujos de trabajo autónomos. Las operaciones en o por debajo de este riesgo proceden sin confirmación. Valores: `none`, `low_write`, `medium_write`, `high_write`, `all`. Ver Elicitación
`HARNESS_SKIP_ELICITATION`	No	`false`	Obsoleto — use `HARNESS_AUTO_APPROVE_RISK=all` en su lugar. Se mantiene por compatibilidad hacia atrás
`HARNESS_ALLOW_HTTP`	No	`false`	Permitir `HARNESS_BASE_URL` no HTTPS. De forma predeterminada, el servidor aplica HTTPS por seguridad. Configure `true` solo para desarrollo local contra una instancia de Harness sin TLS
`HARNESS_PIPELINE_VERSION`	No	`0`	(Alfa) Versión de YAML de pipeline. `0` carga el tipo de recurso `pipeline` y excluye `pipeline_v1`; `1` carga `pipeline_v1` y excluye `pipeline`. Las sesiones HTTP pueden anular esto en el momento de la inicialización con `x-harness-pipeline-version: 0` o `1`
`HARNESS_MCP_ALLOWED_HOSTS`	No	--	Nombres de host separados por comas permitidos por la validación de encabezado Host del transporte HTTP. `mcp.harness.io` se permite de forma predeterminada para enlaces de localhost; agregue dominios proxy/personalizados aquí
`HARNESS_MCP_AUTH_TOKEN`	No	--	Token Bearer estático requerido en rutas HTTP `/mcp` cuando se configura. Requerido de forma predeterminada para enlaces de usuario único y multiusuario que no sean de bucle local. Debe estar sin configurar en modo `oauth`
`HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP`	No	`false`	Permitir explícitamente transporte HTTP no autenticado en enlaces que no sean de bucle local. Use solo detrás de otro control autenticado
`HARNESS_MCP_TRUST_PROXY`	No	`0`	Número de saltos de proxy inverso / balanceador de carga a confiar para la resolución de IP del cliente (Express `trust proxy`). Configure el número de proxies frente al servidor para que la limitación de velocidad por IP se base en el cliente real en lugar del par de socket del proxy
`HARNESS_MCP_LOG_FILE`	No	`~/.claude/harness-mcp.log`	Archivo utilizado para diagnósticos de desconexión/fallo de stdio cuando stderr puede ya no estar disponible
`HARNESS_LOG_UNSAFE_BODIES`	No	`false`	Incluir cuerpos de solicitud/respuesta sin procesar en los registros. Desactivado de forma predeterminada ya que los cuerpos pueden contener secretos; habilite solo para depuración local
`HARNESS_AUDIT_FILE`	No	--	Anexar eventos de auditoría a un archivo JSON delimitado por nuevas líneas para recopilación local duradera
`HARNESS_AUDIT_WEBHOOK_URL`	No	--	Endpoint HTTPS que recibe eventos de auditoría por lotes. Las URL HTTP requieren `HARNESS_ALLOW_HTTP=true` para desarrollo local
`HARNESS_AUDIT_WEBHOOK_TOKEN`	No	--	Token Bearer opcional enviado al webhook de auditoría
`HARNESS_AUDIT_WEBHOOK_BATCH_SIZE`	No	`10`	Número de eventos de auditoría a agrupar antes del vaciado del webhook
`HARNESS_AUDIT_WEBHOOK_FLUSH_MS`	No	`5000`	Tiempo máximo para retener eventos de auditoría antes del vaciado por webhook
`OTEL_EXPORTER_OTLP_ENDPOINT`	No	--	Habilita los spans de auditoría de OpenTelemetry cuando los paquetes opcionales de OpenTelemetry están instalados
`HARNESS_SEARCH_PROVIDER`	No	`local`	Backend de búsqueda semántica: `local` (embeddings ONNX en proceso, predeterminado), `remote` (servicio de búsqueda externo vía HTTP, requerido para modo multiusuario), o `none` (deshabilitar búsqueda semántica, recurrir solo a dispersión y recolección por palabras clave). Use `none` en entornos aislados o cuando la carga del modelo al inicio no sea deseable
`HARNESS_SEARCH_SERVICE_URL`	No	--	URL base del servicio de búsqueda remoto cuando `HARNESS_SEARCH_PROVIDER=remote` (p. ej. `http://search-svc:8080`). Requerido al usar el proveedor `remote`
`HARNESS_SEARCH_SERVICE_HEADERS`	No	--	Objeto JSON de encabezados enviados con cada solicitud al servicio de búsqueda remoto. Admite cualquier esquema de autenticación: `{"Authorization":"Bearer tok"}`, `{"x-api-key":"key"}`, o múltiples encabezados internos de servicio a servicio
`HARNESS_HF_CACHE_DIR`	No	`/tmp/hf-cache`	Directorio para la caché del modelo `@huggingface/transformers` utilizada por el proveedor de búsqueda `local`. La imagen Docker precarga el modelo en `/app/.cache/hf` para evitar descargas en tiempo de ejecución. Establezca una ruta de volumen persistente en despliegues de producción
`HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY`	No	`3`	Máximo de descargas concurrentes de blobs de registro emitidas por `harness_diagnose` al obtener registros de pasos fallidos. Aumente solo si la latencia de diagnóstico está dominada por el tiempo de reloj de pared de la obtención de registros y el pod tiene margen de memoria

Búsqueda Semántica

harness_search utiliza enrutamiento semántico para reducir las llamadas API de tipo scatter-gather antes de distribuirlas a Harness. Hay tres proveedores de búsqueda disponibles:

Proveedor	Cuándo usarlo
`local` (predeterminado)	Modo stdio de un solo usuario. Ejecuta `all-MiniLM-L6-v2` en proceso mediante `@huggingface/transformers`. Descarga un modelo de ~23 MB en el primer uso; los inicios posteriores usan la caché.
`remote`	Modo HTTP multiusuario (alojado en Harness). Delega la incrustación y la recuperación a un servicio de búsqueda externo. El aislamiento de inquilinos se aplica mediante `tenant_id`: el conocimiento/documentación estática usa `global`, y los datos de entidades por cuenta usan el ID de cuenta.
`none`	Desactiva la búsqueda semántica por completo; vuelve a la búsqueda por palabras clave tipo scatter-gather en todos los tipos de recursos.

Configuración del proveedor 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

Prueba del proveedor remoto localmente con el servicio stub incluido (sin dependencias 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)

El stub (stub-search-service.py) implementa el mismo contrato /v1/health, /v1/ingest y /v1/search que el servicio de búsqueda de producción. Utiliza una incrustación simple de tipo bolsa de caracteres, por lo que no se requiere descarga de modelos; los resultados son semánticamente plausibles pero no de calidad de producción.

Aplicación de HTTPS

HARNESS_BASE_URL debe usar HTTPS de forma predeterminada. Si configuras una URL que no sea HTTPS (por ejemplo, http://localhost:8080), el servidor se negará a iniciarse con:

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

Registro de Auditoría

Todas las operaciones de la API de Harness despachadas por el registro (list, get, create, update, delete y execute) emiten eventos de auditoría estructurados cuando los sumideros de auditoría están configurados. Los eventos de mutación incluyen la ruta de confirmación utilizada por la elicitación o la aprobación automática cuando hay un contexto de confirmación presente; los eventos de lectura actualmente omiten los metadatos de confirmación. Las herramientas locales de metadatos y descubrimiento de esquemas que omiten el registro, como harness_describe y harness_schema, no forman parte de este flujo de auditoría. Un sumidero de stderr está registrado de forma predeterminada, pero pasa por el registrador normal y obedece a LOG_LEVEL; configura sumideros de archivo o webhook para una recopilación de auditoría duradera:

HARNESS_AUDIT_FILE agrega eventos JSON delimitados por nuevas líneas para la recopilación local.
HARNESS_AUDIT_WEBHOOK_URL publica lotes { "events": [...] } en un webhook HTTPS, opcionalmente con HARNESS_AUDIT_WEBHOOK_TOKEN. Los lotes fallidos se vuelven a poner en cola con capacidad limitada y finalmente se descartan con una advertencia en lugar de bloquear la ejecución de la herramienta.
OTEL_EXPORTER_OTLP_ENDPOINT habilita los spans de auditoría cuando las dependencias opcionales de OpenTelemetry están instaladas. El sumidero reutiliza un proveedor de trazadores existente cuando está registrado; de lo contrario, inicia un exportador OTLP independiente.

Cada evento incluye el nombre de la herramienta, el tipo de recurso, la operación, los identificadores, la marca de tiempo, el riesgo, el resultado, el método/ruta HTTP, la duración y el método de confirmación cuando corresponda. Los sumideros de auditoría son telemetría de mejor esfuerzo; los problemas de entrega se registran y nunca se reproducen ni cambian la operación subyacente de la API de Harness. Para obtener detalles de configuración de OTel y atributos de span, consulta specs/005-otel-audit-sink.md.

Referencia de Herramientas

El servidor expone 11 herramientas MCP. La mayoría de las herramientas de API aceptan org_id y project_id como anulaciones opcionales; si se omiten, recurren a HARNESS_ORG y HARNESS_PROJECT. harness_describe es solo metadatos locales y no utiliza el ámbito de org/proyecto.

Soporte de URL: La mayoría de las herramientas orientadas a API aceptan un parámetro url: pega una URL de la interfaz de Harness y el servidor extrae automáticamente org, proyecto, tipo de recurso, ID de recurso, ID de pipeline e ID de ejecución. harness_describe no acepta url.

Soporte de ámbito: Los tipos de recursos con variantes de cuenta/org/proyecto exponen supportedScopes en harness_describe. Pasa resource_scope cuando necesites un nivel específico:

resource_scope: "account" envía solo accountIdentifier.
resource_scope: "org" envía accountIdentifier y orgIdentifier.
resource_scope: "project" envía identificadores de cuenta, org y proyecto.

Los recursos actuales de múltiples ámbitos incluyen connector, service, environment, infrastructure, secret, file_store, template, policy y policy_set. Si se omite resource_scope, el registro utiliza el ámbito predeterminado del recurso y los valores predeterminados configurados, excepto que los recursos marcados como de ámbito opcional pueden omitir org/proyecto a menos que se pasen explícitamente. Las URL de Harness también pueden establecer el ámbito automáticamente cuando la ruta contiene contexto a nivel de cuenta o de proyecto.

Salida estructurada: Cada herramienta declara un outputSchema de MCP. harness_list normaliza las respuestas de Harness similares a listas en contenido estructurado con forma de objeto para que los clientes estrictos puedan validarlo: los arreglos de nivel superior se convierten en { "items": [...], "total": <count>, "page": <page> }, y las claves de envoltura comunes como content, data, body, objects o features se elevan a items cuando es necesario. La respuesta de texto aún contiene la carga útil JSON compacta devuelta a todos los clientes.

Herramienta	Descripción
`harness_describe`	Descubre los tipos de recursos, operaciones y campos disponibles. Sin llamada a la API: devuelve metadatos del registro local.
`harness_schema`	Obtén definiciones exactas de esquemas YAML/JSON y ejemplos para crear/actualizar recursos. Los esquemas de pipelines/plantillas están incluidos; los esquemas de conectores, entornos, servicios, secretos e infraestructura son esquemas de entidad sensibles al ámbito, obtenidos de instantáneas incluidas o de NG `/yaml-schema`; los esquemas de `release_process` y `release_activity` se obtienen en vivo desde RMG `/api/yamlSchema`. Admite exploración en profundidad mediante `path`.
`harness_list`	Lista recursos de un tipo determinado con filtrado, búsqueda y paginación.
`harness_get`	Obtén un único recurso por su identificador.
`harness_create`	Crea un nuevo recurso. Admite pipelines en línea y remotos (respaldados por Git). Solicita confirmación del usuario mediante elicitation.
`harness_update`	Actualiza un recurso existente. Admite pipelines en línea y remotos (respaldados por Git). Solicita confirmación del usuario mediante elicitation.
`harness_delete`	Elimina un recurso. Solicita confirmación del usuario mediante elicitation. Destructivo.
`harness_execute`	Ejecuta una acción sobre un recurso (ejecutar/reintentar pipeline, importar pipeline desde Git, alternar flag, sincronizar app). Solicita confirmación del usuario mediante elicitation. Para ejecuciones de pipelines, usa el flujo de trabajo de entradas en tiempo de ejecución a continuación (admite expansión abreviada de `branch`/`tag`/`pr_number`/`commit_sha`).
`harness_search`	Busca entre los tipos de recursos de Harness con una sola consulta. Usa enrutamiento semántico (embeddings ONNX locales de `all-MiniLM-L6-v2`, 384 dimensiones) para predecir los tipos de recursos relevantes a partir de un corpus de `knowledge` indexado al inicio; normalmente reduce de ~163 tipos a 1–8 antes del scatter-gather. Si la confianza semántica es baja, recurre a scatter-gather completo por palabras clave. La respuesta incluye `semantic_routed` y `types_skipped` cuando el enrutamiento se activa. Consulta `docs/search-guidelines.md` para saber cómo hacer que nuevos tipos de recursos sean detectables.
`harness_diagnose`	Diagnostica recursos de `pipeline`, `connector`, `delegate` y `gitops_application` (alias: `execution` -> `pipeline`, `gitops_app` -> `gitops_application`). Para pipelines, devuelve tiempos de etapas/pasos y detalles de fallos; para conectores/delegados/apps de GitOps, devuelve señales específicas de salud y resolución de problemas.
`harness_status`	Obtén un panel de salud del proyecto en tiempo real: ejecuciones recientes, tasas de fallos y enlaces profundos.

Flujo de trabajo de consulta de esquemas

Usa harness_schema antes de crear o actualizar recursos respaldados por YAML para que los agentes puedan copiar nombres de campos y restricciones exactos en lugar de adivinar a partir de prosa.

Los esquemas incluidos incluyen pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 y agent-pipeline.
Los esquemas de entidad incluyen connector, environment, service, secret y infrastructure. Son sensibles al ámbito (account, org o project) y requieren org_id/project_id cuando el ámbito seleccionado lo exige.
Las definiciones de Release Management (release_process, release_activity) obtienen JSON Schema en vivo desde RMG /api/yamlSchema (no incluidas). Pasa scope, org_id y project_id al delimitar a organización o proyecto.
Las instantáneas de entidad incluidas se usan primero cuando coinciden con la cuenta en tiempo de ejecución; de lo contrario, la herramienta recurre a la API de NG /yaml-schema de Harness y almacena en caché el resultado.
Omite path para un resumen de campos/secciones; luego pasa un path separado por puntos para inspeccionar una definición anidada.

Ejemplos:

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

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

Los mantenedores pueden actualizar las instantáneas de entidad incluidas con pnpm sync-entity-schemas cuando cambien los esquemas YAML de entidades de Harness.

Ejemplos de herramientas

Descubre qué recursos están disponibles:

{ "resource_type": "pipeline" }

Lista organizaciones en la cuenta:

{ "resource_type": "organization" }

Lista proyectos en una organización:

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

Lista pipelines en un proyecto:

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

Obtén un servicio específico:

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

Ejecuta un pipeline:

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

Alterna un feature flag:

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

Busca en todos los tipos de recursos:

{ "query": "payment-service" }

Diagnostica una ejecución por ID (modo resumen — predeterminado):

{ "execution_id": "abc123XYZ" }

Diagnostica desde una URL de Harness:

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

Diagnostica la conectividad de un conector:

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

Diagnostica la salud de un delegado:

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

Diagnostica una aplicación de GitOps (con opciones):

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

Obtén el informe de ejecución más reciente de un pipeline:

{ "pipeline_id": "my-pipeline" }

Modo de diagnóstico completo con YAML y registros de pasos fallidos:

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

Modo resumen con registros habilitados (lo mejor de ambos):

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

Obtén el estado de salud del proyecto:

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

Lista esquemas de base de datos filtrados por tipo de migración:

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

Lista instancias de base de datos para un esquema:

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

Obtén el pipeline de autoría LLM resuelto para un esquema e instancia:

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

Lista nombres de objetos de instantánea (p. ej., tablas) para una instancia de esquema:

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

Obtén metadatos completos de instantánea para objetos nombrados específicos:

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

Flujo de trabajo de ejecución de pipelines (Recomendado)

Para pipelines v0, usa esta secuencia para reducir errores de entrada en tiempo de ejecución:

Descubre entradas de tiempo de ejecución requeridas

harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
La plantilla devuelta muestra marcadores de posición de <+input> que necesitan valores.

Elige la estrategia de entrada

Variables simples: pasa pares clave-valor planos de inputs (por ejemplo, {"branch":"main","env":"prod"}).
Entradas complejas/estructurales: usa input_set_ids (los bloques de codebase/build de CI y las entradas de plantilla anidadas se manejan mejor así).

Claves abreviadas de codebase de CI (solo ejecución de pipeline):

Clave abreviada	Estructura 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>`

Restricción: la expansión abreviada se omite cuando inputs.build ya está presente (el build explícito gana).

Ejecuta la ejecución

harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)
Para pipelines respaldados por Git cuyo YAML deba cargarse desde una rama no predeterminada, pasa params.pipeline_branch (enviado a Harness como branch). Este selector de definición explícito tiene prioridad sobre el alias params.branch. inputs.branch selecciona de forma independiente la rama de codebase de CI:
```
{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}
```

Opcional: combina ambos

Usa input_set_ids para la forma base y inputs para anulaciones simples.

Para pipelines v1:

Obtén harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>"). Para pipelines respaldados por Git, pasa branch_name, connector_ref y repo_name mediante params.
Usa cada inputs[].details.name devuelto como clave de nivel superior en harness_execute.inputs.
Ejecuta harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}). El servidor envuelve estos valores bajo una raíz YAML de inputs: y envía el cuerpo de inputs_yaml de la API. Si los campos obligatorios no están resueltos, la herramienta devuelve un error de verificación previa con las claves esperadas y los conjuntos de entrada sugeridos. Puede inspeccionar las asignaciones abreviadas disponibles con harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Ejecución dinámica de pipelines

Use pipeline_dynamic_execution.run cuando un agente o un sistema externo genera el YAML completo de la pipeline v0 en tiempo de ejecución y necesita ejecutarlo contra un shell de pipeline de Harness existente. Esto no reemplaza la pipeline.run normal: la pipeline v0 guardada ya debe existir, la opción Permitir ejecución dinámica a nivel de cuenta y de pipeline debe estar habilitada, y el llamador necesita permisos de Edición y Ejecución en la 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
  }
}

Restricciones:

body debe ser un objeto con un campo yaml. Los cuerpos de cadena sin procesar son rechazados por el esquema público harness_execute.
body.yaml puede ser una cadena YAML o un objeto JSON de pipeline; el JSON se serializa a YAML antes de la solicitud.
Los marcadores de posición <+input> en tiempo de ejecución no se resuelven mediante esta API. Envíe YAML completamente resuelto.
Los conjuntos de entrada, la ejecución selectiva de etapas, el reintento y los disparadores no son compatibles con el endpoint de ejecución dinámica.
La acción es high_write y utiliza la ruta normal de confirmación/aprobación automática. La respuesta proyecta el sobre de la API a { "execution_id": "...", "status": "..." } e incluye un enlace de ejecución openInHarness cuando los datos de alcance están disponibles.

Si Harness rechaza la ejecución por no estar habilitada, verifique tanto la configuración de Permitir ejecución dinámica a nivel de cuenta como el interruptor a nivel de pipeline en Pipeline -> Opciones avanzadas -> Configuración de ejecución dinámica.

Análisis forense de entradas de ejecución

Use execution_inputs después de una ejecución para inspeccionar el YAML de entrada combinado que produjo una ejecución específica. Esto es útil cuando un fallo depende de la combinación de conjuntos de entrada, ramas de conjuntos de entrada respaldadas por Git o valores de disparador/tiempo de ejecución que son difíciles de reconstruir solo desde la página de ejecución.

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

La respuesta de obtención se proyecta a:

executionId: el ID de ejecución del plan de resource_id.
inputSetYaml: YAML de entrada de tiempo de ejecución combinado utilizado para la ejecución, o null.
inputSetTemplateYaml: plantilla de entrada en el momento de la ejecución, o null.
resolvedYaml: YAML resuelto por expresión cuando resolve_expressions=true, de lo contrario, generalmente null.
inputSetDetails: conjuntos de entrada guardados que contribuyen como pares { identifier, name }.
inputSetBranchName: rama de origen para conjuntos de entrada respaldados por Git, o null.

execution_inputs es solo de obtención y de riesgo de lectura. Si se omite resolve_expressions, el servidor omite los parámetros de consulta de la API y Harness usa su modo de resolución UNKNOWN predeterminado.

Modo de espera de ejecución de pipelines

Para pipeline.run, pipeline.retry y pipeline_v1.run, pase wait: true para permitir que el servidor sondee hasta que la ejecución alcance un estado terminal. Esto mantiene el lanzamiento de una pipeline y la verificación de estado en una sola llamada de herramienta en lugar de pedir al cliente o al LLM que ejecute un bucle de sondeo.

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

Comportamiento del modo de espera:

El tiempo de espera predeterminado es de 600 segundos; el rango permitido es de 10 segundos a 7200 segundos.
El intervalo de sondeo inicial es de 3 segundos por defecto, retrocede en 1.5x y alcanza un máximo de 30 segundos.
En caso de éxito o fallo, la respuesta incluye campos como execution_id, execution_status, execution_terminal, execution_elapsed_ms y execution_poll_count.
Si el tiempo de espera se agota, el disparador original aún tuvo éxito; la respuesta incluye execution_timed_out: true y _wait.hint con el último estado observado.
Si el sondeo falla después de que el disparador tenga éxito, la respuesta incluye _wait.error y una sugerencia de re-verificación. No vuelva a ejecutar la pipeline a ciegas a menos que haya confirmado que la primera ejecución no está en curso.
Los estados terminales fallidos incluyen _diagnose_hint que apunta a harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Pida al Agente DevOps de IA que cree una pipeline:

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

Actualice un servicio mediante lenguaje 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 almacenamiento de pipelines

Las pipelines de Harness se pueden almacenar de tres maneras:

Modo	Descripción	Cuándo usar
En línea	YAML de pipeline almacenado en Harness	Predeterminado. Configuración más simple, no requiere Git.
Remoto (Git externo)	YAML de pipeline almacenado en GitHub, GitLab, Bitbucket, etc.	Equipos que usan pipeline-como-código respaldada por Git con un proveedor externo.
Remoto (Harness Code)	YAML de pipeline almacenado en un repositorio de Harness Code	Equipos que usan el alojamiento Git integrado de Harness.

Crear una pipeline en línea (predeterminada):

// 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"
  }
}

Crear una pipeline remota (Git externo, por ejemplo, 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"
  }
}

Crear una pipeline remota (Harness Code, sin conector necesario):

// 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"
  }
}

Actualizar una pipeline remota:

// 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 una pipeline desde un repositorio 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 una pipeline desde un repositorio de 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"
  }
}

Crear un conector:

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

Eliminar un disparador:

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

Listar conjuntos de entrada para una pipeline:

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

Obtener un conjunto de entrada específico:

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

Crear un 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"
}

Actualizar un 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\""
}

Eliminar un conjunto de entrada:

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

Tipos de recursos

255 tipos de recursos organizados en 41 conjuntos de herramientas. Cada tipo de recurso admite un subconjunto de operaciones CRUD y acciones de ejecución opcionales.

Plataforma

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`organization`	x	x	x	x	x
`project`	x	x	x	x	x

Pipelines

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`pipeline`	x	x	x	x	x	`run`, `retry`
`pipeline_v1` (Alfa)	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 tipos de recursos YAML de pipeline están disponibles cuando el conjunto de herramientas de pipelines está habilitado. HARNESS_PIPELINE_VERSION y el encabezado de inicialización HTTP x-harness-pipeline-version seleccionan la preferencia de versión predeterminada; no ocultan la otra versión.

Agentes de IA

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`agent`	x	x	x	x	x
`agent_run`	x

Servicios

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`service`	x	x	x	x	x

Entornos

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`environment`	x	x	x	x	x	`move_configs`

Conectores

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`connector`	x	x	x	x	x	`test_connection`
`connector_catalogue`	x

Infraestructura

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`infrastructure`	x	x	x	x	x	`move_configs`

Secretos

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`secret`	x	x

Registros de ejecución

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`execution_log`		x

Rastro de auditoría

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`audit_event`	x	x

Delegados

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`delegate`	x	x
`delegate_token`	x	x	x		x	`revoke`, `get_delegates`

Repositorios de código

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`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

La creación de commit confirma una o más acciones de archivo directamente a través de la API de Harness Code sin clonar. Pase body.title, body.branch y body.actions; cada acción es CREATE, UPDATE, DELETE o MOVE, y UPDATE requiere el SHA del blob actual.

La lista de file_content devuelve cada ruta en una referencia; obtener devuelve contenido de archivo o directorio (omita o pase path vacío para la raíz del repositorio; las rutas anidadas mantienen las barras). Omita git_ref para usar la rama predeterminada del repositorio; no adivine main.

Registros de artefactos

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

Almacén de Archivos

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`file_store`	x	x	x	x	x	`list_children`

file_store gestiona archivos y carpetas del Almacén de Archivos de Harness a través de las herramientas genéricas. Admite alcance de cuenta, organización y proyecto; pase resource_scope="account"|"org"|"project" o pegue una URL del Almacén de Archivos de Harness para que el servidor pueda derivar el alcance y los IDs.

Llamadas comunes:

# 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"})

Restricciones del cuerpo multiparte:

Crear/actualizar acepta JSON body, luego lo convierte a multipart/form-data para /ng/api/file-store.
name, type (FILE o FOLDER) y parent_identifier son obligatorios; use el literal "Root" solo para la raíz del alcance seleccionado.
La creación de FILE requiere exactamente uno de content (cadena UTF-8) o content_base64 (base64 válido no vacío). La actualización de FILE puede omitir contenido para actualizaciones solo de metadatos, o proporcionar exactamente un campo de contenido para reemplazar el contenido.
La creación/actualización de FOLDER debe omitir content y content_base64.
El file_usage opcional debe ser MANIFEST_FILE, CONFIG o SCRIPT; los metadatos escalares opcionales como description, mime_type, path y tags deben ser cadenas.
El contenido de carga está limitado a 100 MB. Los avisos de confirmación redactan las vistas previas de content, content_base64 y contentBase64 antes de la solicitud.

list_children acepta tanto forma abreviada (resource_id más params.folder_name, o params.file_store_id/params.folder_identifier más params.folder_name) como un FileStoreNode completo body con identifier, name y type: "FOLDER". Los cuerpos completos usan parentIdentifier en camelCase de Harness; la forma abreviada puede usar params.parent_identifier.

Plantillas

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`template`	x	x	x	x	x

Las operaciones de plantillas usan las rutas del servicio de Plantillas de Harness (/template/api/templates...). Crear y actualizar requieren la cadena YAML completa de la plantilla en body.template_yaml o body.yaml; version_label apunta a una versión específica para actualizar/eliminar, mientras que eliminar sin version_label elimina todas las versiones.

Paneles

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`dashboard`	x	x
`dashboard_data`		x

DevOps de Bases de Datos

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar
`database_schema`	x	x	x	x	x
`database_instance`	x	x	x	x	x
`database_snapshot_object`	x	x
`database_llm_authoring_pipeline`		x

Gestión de Infraestructura como Código (IaCM)

Los recursos de IaCM están habilitados por defecto y son mayormente de alcance de proyecto. Comience con iacm_workspace para encontrar identificadores de espacios de trabajo, luego use ese workspace_id para recursos de espacios de trabajo, costos y diferencias de actividad. Use iacm_variable_set para conjuntos de variables reutilizables en alcance de cuenta, organización o proyecto. El registro de proveedores es de alcance de cuenta.

iacm_module abarca alcance de cuenta, organización y proyecto. Por defecto usa el registro de cuenta; cada operación (listar, obtener, crear, actualizar) envía los mismos parámetros de consulta scope_org / scope_project, por lo que un módulo que cree es detectable en el alcance donde lo creó. Seleccione el alcance con resource_scope="account" | "org" | "project" más org_id/project_id. El alcance es opcional: cuando se omite resource_scope, org_id/project_id se aplican solo si los pasa explícitamente — los valores predeterminados configurados de HARNESS_ORG/HARNESS_PROJECT no se aplican, por lo que una configuración de proyecto ambiental no puede registrar silenciosamente un módulo de cuenta bajo un proyecto. Los campos propios de org/project del cuerpo de un módulo ubican su conector Git y no están relacionados con este alcance de visibilidad.

La creación/actualización de iacm_workspace devuelve solo { policy_evaluation } — continúe con harness_get para obtener el espacio de trabajo. La creación/actualización de iacm_variable_set y iacm_module devuelve el recurso en sí. La creación de iacm_provider devuelve solo { id } — continúe con harness_get; la actualización es solo orientada a versiones (POST/PUT /providers/{id}/version) — no hay PUT de metadatos. Las escrituras de versiones pueden devolver un cuerpo vacío; HarnessClient lo normaliza a { status: "SUCCESS", message: "No content" }.

La actualización de conjuntos de variables es HTTP PUT con colecciones de reemplazo completo — siempre haga harness_get primero, luego PUT del cuerpo completo deseado (terraform_variables / environment_variables son obligatorios en la actualización; omitir/vacío limpia conectores y archivos de variables). La actualización de módulos también es PUT — prefiera obtener-luego-poner para campos opcionales. Las escrituras son medium_write y requieren confirmación (solicitud o confirm: true).

El RBAC de conjuntos de variables y registro de proveedores (iac_variableset_*, iac_providerregistry_*) es actualmente Experimental en Harness — las comprobaciones de acceso siempre permiten hasta que iac-server active la aplicación. El RBAC del registro de módulos (iac_registry_view / iac_registry_edit) está Activo y es aplicable. MCP siempre reenvía el PAT/SAT del llamante sin cambios.

Tipo de Recurso	Listar	Obtener	Crear	Actualizar
`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

Flujo de trabajo típico:

harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") para encontrar el espacio de trabajo.
harness_create / harness_update en iacm_workspace para crear desde cero o desde una plantilla (associated_template), o actualizar un espacio de trabajo existente — la respuesta es solo { policy_evaluation }.
harness_get(resource_type="iacm_workspace", workspace_id="...") para obtener el espacio de trabajo creado/actualizado.
harness_list / harness_create / harness_update en iacm_variable_set (opcionalmente con resource_scope) para conjuntos de variables reutilizables de Terraform/env — la respuesta es el recurso VariableSet.
harness_list / harness_create / harness_update en iacm_module para el registro de módulos (name + system obligatorios; agregue resource_scope con org_id/project_id para un módulo de alcance de organización o proyecto) — la respuesta es el recurso de módulo.
harness_list / harness_create / harness_update en iacm_provider para el registro de proveedores de cuenta (body.type obligatorio para crear; crear devuelve solo { id } — luego harness_get; actualizar crea/actualiza solo versiones) — la actualización de versión puede devolver éxito vacío.
harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") para inspeccionar recursos de Terraform, salidas y fuentes de datos.
harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") para revisar entradas de costos por ejecución.
harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") para inspeccionar diferencias de recursos antes/después para una actividad de plan, aplicar o destruir.

Las respuestas de listado de IaCM exponen page_count como el conteo solo para la página actual (excepto iacm_variable_set, que no está paginado). Cuando has_more es verdadero, siga solicitando la siguiente página basada en 1 y sume los conteos de página si necesita un total.

Portal de Desarrollador Interno (IDP)

Tipo de Recurso	Listar	Obtener	Ejecutar Acciones
`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

Solicitudes de Extracción (Pull Requests)

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`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 una operación de cierre explícita. harness_update también acepta body.state (open o closed) y enruta los cambios de estado al endpoint dedicado de estado de PR de Harness Code; envíe ediciones de título/descripción en una llamada de actualización separada.

Use harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) para leer comentarios de PR. Use pr_comment para operaciones de escritura de comentarios.

Gestión de Lanzamientos

Los recursos de Gestión de Lanzamientos (RMG) están habilitados por defecto. Los recursos de definición (release_process, release_activity) admiten listar/obtener/crear/actualizar/eliminar con body.yaml; llame a harness_schema(resource_type="release_process"|"release_activity") antes de crear/actualizar. Los recursos de ejecución monitorean lanzamientos en curso — la mayoría de las operaciones de listado requieren release_id (UUID de harness_list resource_type=release, o el slug de URL de la interfaz como identifier-1.0.0-abc). Pegue una URL de lanzamiento de RMG en harness_list para autocompletar release_id.

Las llamadas de RMG usan ${HARNESS_BASE_URL}/gateway/rmg con alcance de cuenta mediante el encabezado Harness-Account. El alcance de organización/proyecto usa alcance basado en encabezados cuando se proporcionan org_id/project_id. release_execution_phase es solo de listado — use el campo identifier de cada elemento de fase como params.phase_identifier al llamar a harness_get en recursos de entrada/salida de fase (no llame a harness_get en release_execution_phase en sí). El filtrado de status de la lista de lanzamientos se aplica del lado del cliente solo en la página actual; continúe paginando con los mismos filtros cuando los resultados puedan abarcar varias páginas.

Tipo de recurso	Listar	Obtener	Crear	Actualizar	Eliminar
`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

Flujo de trabajo típico:

harness_list(resource_type="release_process", org_id="...", project_id="...") para descubrir definiciones de procesos de orquestación.
harness_schema(resource_type="release_process") (o release_activity) antes de crear/actualizar; luego harness_create / harness_update con body.yaml.
harness_list(resource_type="release", org_id="...", project_id="...") para encontrar versiones activas o recientes (retroceso predeterminado de 30 días; opcional filters.status, filters.search_term, filters.days_back).
harness_get(resource_type="release", release_id="...") para detalles de la versión.
harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) para el estado de la fase; el mismo release_id para release_execution_task y release_execution_activity.
harness_get en release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output o release_execution_activity_input usando release_id más params.phase_identifier / params.activity_identifier / activity_execution_id como se documenta en cada recurso.

Vibe

El conjunto de herramientas vibe habilitado por defecto cubre el contrato BFF de Vibe Orchestrator bajo ${HARNESS_BASE_URL}/vibe/v1. Utiliza la conexión y el encabezado de cuenta existentes de Harness, sin agregar parámetros de consulta de cuenta/org/proyecto ni campos de alcance a los cuerpos de solicitud. El equipo validó el flujo de Vibe usando autenticación con clave API de Harness (PAT/SAT), por lo que no se requiere configuración de suscripción para sesiones predeterminadas. Los documentos OpenAPI seleccionados describen autenticación de portador/sesión; el modo OAuth del servidor reenvía el token de portador de la sesión actual. Las regresiones automatizadas verifican ambas rutas de encabezado; la autenticación de puerta de enlace sigue sujeta a la configuración del entorno de destino.

Tipo de recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar acciones
`vibe_project`			x			`prepare`, `deploy`
`vibe_app_lifecycle`		x				`events`

La API admite dos rutas de ingesta. Mantén estas formas de solicitud nativas de la API:

Fuente disponible para el agente de codificación	Flujo de API
Enlace/conector de repositorio de GitHub	`harness_create` con `resource_type="vibe_project"` y `body.mode` más los campos específicos del modo. El contrato nombra `github_link` y `github_connector` pero no define sus formas de campos de URL, rama o conector; estos campos se reenvían al backend sin inventar un mapeo.
Archivo ZIP	Llama a `prepare` con el nombre de la aplicación y los metadatos del archivo, sube los bytes al destino firmado devuelto y luego llama a `deploy`.
Directorio fuente local	El agente de codificación archiva el código fuente del espacio de trabajo deseado en un ZIP localmente y luego sigue el flujo de ZIP. Una ruta local o contexto conversacional no es una carga de fuente compatible con la API.

Al empaquetar un directorio, incluye el código fuente, manifiestos, archivos de bloqueo, configuración y ediciones no confirmadas previstas necesarias para compilarlo. Excluye credenciales, .git, dependencias instaladas y artefactos generados. El empaquetado y la carga firmada ocurren donde los archivos son accesibles; un servidor MCP alojado no puede leer el directorio local del agente de codificación.

Para un ZIP existente, prepara la carga:

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

Pasa esto a harness_execute. El tamaño debe describir el ZIP real; size_bytes, content_type y md5 son opcionales y anulables. Los campos de preparación adicionales se conservan para validación del backend, según lo permitido por el OpenAPI. La preparación devuelve projectId, sourceId y upload, incluidos el uploadUrl, method, headers y expiresAt de cada archivo. Sube los bytes del archivo directamente usando esa URL firmada, método y encabezados; conserva la URL exactamente y no agregues credenciales de Harness a la solicitud de almacenamiento. La acción de preparación no lee ni sube archivos locales.

Después de una carga exitosa, implementa explícitamente:

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

Para importaciones JSON, usa el id devuelto en su lugar. La implementación también acepta body: {"project_id": "<Vibe app id>"} o params.app_id; el campo de cable de la API es snake_case project_id aunque la preparación devuelve camelCase projectId. El project_id de nivel superior de la herramienta genérica es un identificador de alcance de Harness y nunca se usa como ID de aplicación de Vibe. La importación y la preparación crean la aplicación/fuente; ninguna inicia la implementación. Las escrituras no se reintentan automáticamente y la implementación usa la política de confirmación de alto riesgo existente.

Lee el progreso con harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Conserva URLs de aplicaciones, etapas de ejecución, subpasos, fallos, líneas de registro y detalles del analizador de compilación. La acción de ejecución events acepta resource_id o params.app_id y consume el endpoint SSE como un lote finito: hasta 20 eventos JSON o cinco segundos después de la conexión, con un límite de respuesta de 1 MiB. Estos límites pertenecen al endpoint de Vibe. El HARNESS_API_TIMEOUT_MS de la conexión también limita el consumo de conexión y flujo juntos; la expiración devuelve un error de tiempo de espera. Un lote completado devuelve events y stop_reason (end, event_limit o duration_limit) y cierra el flujo. Ni los fallos de conexión iniciales ni los flujos interrumpidos se reintentan. Los eventos son diffs transitorios sin cursor de reproducción documentado; usa la obtención de ciclo de vida para una instantánea autoritativa. Ambas lecturas de ciclo de vida están disponibles en modo de solo lectura.

Feature Flags

Tipo de recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar acciones
`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) — los recursos fme_* admiten alcance de doble modo: las llamadas heredadas pasan workspace_id y alcanzan la API de Split.io (api.split.io); las llamadas más nuevas pasan org_id+project_id juntos y alcanzan endpoints nativos de Harness (HARNESS_API_KEY/HARNESS_BASE_URL estándar, misma autenticación que cualquier otro recurso harness_*) en su lugar. Pasar tanto workspace_id como org_id/project_id en la misma llamada, o mezclar org_id con project_id solo, es un error: elige un modo por llamada. Cada operación a continuación está disponible en modo heredado, sin cambios, a menos que el recurso esté marcado solo nativo de Harness. La cobertura del modo nativo de Harness es actualmente más limitada:

fme_workspace — sin equivalente nativo en Harness; solo legado (se usa para descubrir valores de workspace_id).
fme_environment — list de modo dual (workspace_id o org_id+project_id). get/create/update/delete son solo nativos de Harness (/fme/api/v4/environments) — MCP nunca tuvo un contrato workspace_id para esas operaciones. La lista nativa usa offset/limit opcionales (máx. 100; harness_list size se asigna a limit); el {data, limit, offset, totalCount} del sobre se promueve a items/total. La creación/actualización nativa usa isProduction (production se acepta como alias). La actualización nativa es JSON Merge Patch; name y isProduction no se pueden borrar. El nombre tiene un máximo de 15 caracteres.
fme_feature_flag — modo dual, ambas ramas completamente conectadas. Nativo de Harness (org_id+project_id): list/get/create/delete llegan a /fme/api/v4/feature-flags (cuerpo para create: name, trafficType, description/tags/owners opcionales, por CreateFeatureFlagRequest); update envía un merge-patch a /fme/api/v4/feature-flags/{name}; archive/unarchive llegan a /fme/api/v4/feature-flags/{name}/archive|unarchive (solo comment opcional — sin title, por ArchiveUnarchiveRequest); kill/restore/reallocate llegan a /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate con environment_id como parámetro de consulta (comment/title opcionales, por FeatureFlagDefinitionActionRequest).
fme_feature_flag_definition — get/create/update siguen en modo dual (workspace_id o org_id+project_id). list/delete/kill/restore/reallocate son solo nativos de Harness (org_id+project_id) — MCP nunca tuvo un contrato workspace_id para esas operaciones. La lista nativa requiere feature_flag_name y usa offset/limit (predeterminado 100, máx. 100); no acepta environment_id. Eliminar y ejecutar requieren environment_id. Kill/restore/reallocate son las mismas acciones que en fme_feature_flag. El cuerpo de get/create/update coincide con el legado (treatments, defaultTreatment, defaultRule, rules/baselineTreatment/trafficAllocation/comment opcionales), más title opcional en modo nativo de Harness. La actualización nativa es JSON Merge Patch.
fme_rollout_status — list de modo dual. Pasa org_id+project_id (preferido) o el workspace_id obsoleto. La paginación nativa usa offset/limit (máx. 100; harness_list size se asigna a limit); los resultados se promueven a items/total. Cada elemento tiene id, name y description opcional.
fme_rule_based_segment — (Obsoleto — ver fme_segment.) El modo nativo de Harness se rechaza en cada operación (list/get/create/delete) — usa fme_segment en su lugar; este recurso solo admite el contrato workspace_id legado.
fme_rule_based_segment_definition — (Obsoleto — ver fme_segment_definition.) El modo nativo de Harness se rechaza en cada operación/acción (list/update/enable/disable/change_request) — usa fme_segment_definition en su lugar (sin equivalente enable/disable/change_request allí); este recurso solo admite el contrato workspace_id/environment_id legado.
fme_traffic_type — list de modo dual. Pasa org_id+project_id (preferido) o el workspace_id obsoleto. La paginación nativa usa offset/limit (máx. 100; harness_list size se asigna a limit); los resultados se promueven a items/total. Cada elemento tiene id y name (sin displayAttributeId).
fme_identity — create/update aún no están implementados si org_id+project_id se pasan juntos; de lo contrario, procede como una llamada legada normal.
fme_standard_segment — obsoleto. El workspace_id legado aún llega a Split v2. El nativo de Harness se rechaza — usa fme_segment.
fme_segment_keys — list/update siguen siendo legados (workspace_id / environment_id+segment_name). El nativo de Harness (org_id+project_id) se rechaza — usa fme_segment_definition ejecutar list_keys/add_keys/remove_keys.
fme_segment — Solo nativo (org_id+project_id). CRUD. list/get/update/delete requieren segment_type: STANDARD | LARGE | RULE_BASED. Cuerpo de creación: name, trafficType, segmentType; description, tags, owners opcionales.
fme_segment_definition — Solo nativo. CRUD más ejecutar list_keys/add_keys/remove_keys. La actualización es solo de descripción. La eliminación falla con hasDependents mientras queden claves.
fme_metric — Solo nativo de Harness (sin soporte workspace_id legado). list/get/create/update/delete están conectados a /fme/api/v4/metrics (el harness_list size de list se asigna a limit). create requiere spread aunque el backend CreateMetricRequest lo mantiene opcional (predeterminado PER) — un contrato más estricto solo del lado de MCP, ya que omitirlo cambia silenciosamente la semántica de una métrica RATE. update es JSON Merge Patch; name/trafficType son inmutables y no se aceptan. delete es una eliminación permanente (sin archivo/restauración) — clasificado como destructive.
fme_event_type — Solo nativo de Harness (sin soporte workspace_id legado). Solo lectura: list/get están conectados a /fme/api/v4/event-types; id es el nombre del evento. Solo se ven los tipos de evento con eventos en los últimos 30 días; get devuelve un 404 para un tipo de evento fuera del alcance del tipo de tráfico del espacio de trabajo solicitante, o inactivo por más de 30 días. Filtros de lista: name (subcadena), traffic_type (por ID o nombre), offset/limit (harness_list size se asigna a limit). Usa esto para descubrir IDs reales de tipos de evento antes de referenciar uno en el filtro baseEventTypes/filterEventType o event_type_ids de fme_metric, en lugar de adivinar un ID.

En modo de usuario único/autohospedado, la autenticación en modo legado usa un token Bearer de HARNESS_FME_API_KEY, con respaldo a un HARNESS_API_KEY que no es un marcador de posición. HARNESS_FME_API_KEY puede ser una clave de administrador legada de Split o un PAT/SAT de Harness con derecho FME, pero se rechaza en modo multi-user para que las implementaciones compartidas no puedan sobrescribir la credencial de cada usuario de sesión. Las credenciales de OAuth alojado/enrutamiento de servicios para las API de la plataforma Harness no autentican solicitudes directas a Split.io. fme_feature_flag admite la gestión completa del ciclo de vida en modo legado: crear (requiere traffic_type_id), listar, obtener, actualizar metadatos, eliminar y acciones de ejecución kill/restore/reallocate/archive/unarchive. Usa fme_traffic_type para descubrir IDs de tipos de tráfico, fme_identity para crear/actualizar atributos de identidad, y fme_standard_segment / fme_segment_keys para inspeccionar segmentos estándar y agregar claves de miembros. fme_rule_based_segment proporciona CRUD para segmentos de segmentación, mientras que fme_rule_based_segment_definition gestiona reglas de segmento específicas del entorno con flujos de aprobación de solicitudes de cambio y habilitación/deshabilitación.

GitOps

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
`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

Ingeniería del Caos

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`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`

Gestión de Costos en la Nube (CCM)

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`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`

Información de Ingeniería de Software (SEI)

Los recursos de SEI están consolidados para eficiencia de tokens. Use los parámetros metric o aspect para DORA, detalles de equipo/árbol organizativo e información de IA.

Tipo de Recurso	Listar	Obtener	Ejecutar Acciones
`sei_metric`	x
`sei_productivity_metric`		x
`sei_dora_metric`		x	Pase `metric`: deployment_frequency, change_failure_rate, mttr, lead_time, o *_drilldown
`sei_team`	x	x
`sei_team_detail`	x		Pase `aspect`: integrations, developers, integration_filters
`sei_org_tree`	x	x
`sei_org_tree_detail`	x	x	Pase `aspect`: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
`sei_business_alignment`	x	x	Pase `aspect`: feature_metrics, feature_summary, drilldown para obtener
`sei_ai_usage`	x	x	Pase `aspect`: metrics, breakdown, summary, top_languages
`sei_ai_adoption`	x	x	Pase `aspect`: metrics, breakdown, summary
`sei_ai_impact`		x	Pase `aspect`: pr_velocity, rework
`sei_ai_raw_metric`	x

Aseguramiento de la Cadena de Suministro de Software (SCS)

Tipo de Recurso	Listar	Obtener
`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

Bóveda de Evidencias

La Bóveda de Evidencias almacena atestaciones in-toto (evidencias del SDLC). Listar admite alcance de cuenta/org/proyecto mediante resource_scope. Los filtros singulares de texto libre (pipeline, artefacto solo, gitoid) usan search_term; una restricción adicional de Nombre usa filters.subject_name; el digesto del contenido del sujeto usa filters.subject_digest. Obtener busca por gitoid_sha256 y requiere org_id/project_id (de la fila de la lista). Descargar (acción harness_execute download) devuelve un download_url con límite de tiempo — muestra siempre ese enlace al usuario. Requiere el feature flag SCS_EVIDENCE_VAULT.

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`attestation`	x	x				`download`

Orquestación de Pruebas de Seguridad (STO)

Tipo de Recurso	Listar	Crear	Ejecutar Acciones
`security_issue`	x
`security_issue_filter`	x
`security_exemption`	x	x	`approve`, `reject`
`remediation_diff`	x

La creación de security_exemption es una operación de high_write. El servidor deriva requester_id del PAT autenticado, establece exemptFutureOccurrences=true y establece duration_days a 30 por defecto cuando no se proporciona. Para listar exenciones, pasa un tamaño de página pequeño y explícito (por ejemplo, filters: { "status": "Pending", "size": 5 }) y sigue el _nextPageHint devuelto en cada respuesta.

Flujo de ejecución de exención de seguridad:

Usa harness_list con resource_type="security_exemption" y un status explícito como Pending, Approved, Rejected, Expired o Canceled.
Usa harness_execute con action="approve" y un body.scope requerido: CURRENT, ACCOUNT, ORG o PROJECT. CURRENT aprueba en el alcance existente de la exención; los otros alcances usan internamente el endpoint de promoción de STO. El servidor autocompleta body.approver_id desde el usuario autenticado cuando se omite; body.comment es opcional.
Usa action="reject" para rechazar una exención. body.approver_id también se autocompleta cuando se omite.
No hay una acción de ejecución separada de promote. Usa action="approve" con un body.scope no CURRENT cuando el resultado solicitado sea aprobación en alcance de cuenta, organización o proyecto.

Control de Acceso

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar
`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

Gobernanza

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar
`policy`	x	x	x	x	x
`policy_set`	x	x	x	x	x
`policy_evaluation`	x	x

Congelación de Despliegues

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`freeze_window`	x	x	x	x	x	`toggle_status`
`global_freeze`		x				`manage`

Anulaciones de Servicio

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`service_override`	x	x	x	x	x

Configuración

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
`setting`	x

Prompts de MCP

DevOps

Prompt	Description	Parameters
`build-deploy-app`	Flujo de trabajo CI/CD de extremo a extremo: escanea un repositorio git, genera un pipeline de CI (compilar y publicar imagen Docker), descubre o genera manifiestos de K8s, crea un pipeline de CD e implementa — con reintento automático en fallos de CI (hasta 5 intentos) y fallos de CD (hasta 3 intentos con permiso del usuario). Cuando se agotan los reintentos, proporciona enlaces profundos de la interfaz de Harness a todos los recursos creados para investigación manual.	`repoUrl` (obligatorio), `imageName` (obligatorio), `projectId` (opcional), `namespace` (opcional)
`debug-pipeline-failure`	Analiza una ejecución fallida: acepta un ID de ejecución, ID de pipeline o URL de Harness. Obtiene el desglose de etapa/paso, detalles del fallo, información del delegado y registros del paso fallido mediante `harness_diagnose`, luego proporciona análisis de causa raíz y correcciones sugeridas. Sigue automáticamente los fallos de pipelines encadenados.	`executionId` (opcional), `projectId` (opcional)
`pipeline_summarizer`	Obtiene y resume TODOS los registros de pasos de una ejecución de pipeline. Usa `harness_diagnose` con `include_logs: true, include_all_step_logs: true` para obtener el registro de cada paso, luego presenta una tabla con Nombre del Paso, Estado, Duración y Qué Ocurrió (resumen basado en registros). NO omite ningún paso.	`executionId` (opcional), `projectId` (opcional)
`create-pipeline`	Genera un nuevo YAML de pipeline a partir de requisitos en lenguaje natural, revisando recursos existentes para contexto	`description` (obligatorio), `projectId` (opcional)
`create-agent`	Construye interactivamente un agente de IA de Harness — verifica agentes existentes (detectando el formato de especificación actual `agent.uses` vs. el heredado `agent.step.group.steps` al actualizar), recopila requisitos, genera la especificación del agente en el formato apropiado, confirma con el usuario y luego crea o actualiza mediante `harness_create`/`harness_update`	`agent_name` (obligatorio), `task_description` (obligatorio), `org_id` (opcional), `project_id` (opcional)
`onboard-service`	Guía el proceso de incorporación de un nuevo servicio con entornos y un pipeline de implementación	`serviceName` (obligatorio), `projectId` (opcional)
`dora-metrics-review`	Revisa métricas DORA (frecuencia de implementación, tasa de fallos por cambios, MTTR, tiempo de entrega) con clasificación Elite/Alto/Medio/Bajo y recomendaciones de mejora	`teamRefId` (opcional), `dateStart` (opcional), `dateEnd` (opcional)
`setup-gitops-application`	Guía la incorporación de una aplicación GitOps — verifica agente, clúster, repositorio y crea la aplicación	`agentId` (obligatorio), `projectId` (opcional)
`chaos-resilience-test`	Diseña un experimento de caos para probar la resiliencia del servicio con inyección de fallos, sondas y resultados esperados	`serviceName` (obligatorio), `projectId` (opcional)
`feature-flag-rollout`	Planifica y ejecuta un despliegue progresivo de feature flags entre entornos con compuertas de seguridad	`flagIdentifier` (obligatorio), `projectId` (opcional)
`migrate-pipeline-to-template`	Analiza un pipeline existente y extrae plantillas reutilizables de etapas/pasos	`pipelineId` (obligatorio), `projectId` (opcional)
`delegate-health-check`	Verifica la conectividad del delegado, salud, estado del token y soluciona problemas de infraestructura	`projectId` (opcional)
`developer-portal-scorecard`	Revisa los scorecards de IDP para servicios e identifica brechas para mejorar la experiencia del desarrollador	`projectId` (opcional)
`pending-approvals`	Encuentra ejecuciones de pipeline en espera de aprobación, muestra detalles y ofrece aprobar o rechazar	`projectId` (opcional), `orgId` (opcional), `pipelineId` (opcional)

FinOps

Prompt	Description	Parameters
`optimize-costs`	Analiza datos de costos en la nube, muestra recomendaciones y anomalías, priorizadas por ahorro potencial	`projectId` (opcional)
`cloud-cost-breakdown`	Análisis profundo de costos en la nube por servicio, entorno o clúster con análisis de tendencias y detección de anomalías	`perspectiveId` (opcional), `projectId` (opcional)
`commitment-utilization-review`	Analiza la utilización de instancias reservadas y planes de ahorro para encontrar desperdicio y optimizar compromisos	`projectId` (opcional)
`cost-anomaly-investigation`	Investiga anomalías de costos — determina la causa raíz, recursos afectados y remediación	`projectId` (opcional)
`rightsizing-recommendations`	Revisa y prioriza recomendaciones de ajuste de tamaño, opcionalmente crea tickets de Jira o ServiceNow	`projectId` (opcional), `minSavings` (opcional)

DevSecOps

Prompt	Description	Parameters
`security-review`	Revisa problemas de seguridad en los recursos de Harness y sugiere remediaciones por severidad	`projectId` (opcional), `severity` (opcional, predeterminado: `critical,high`)
`vulnerability-triage`	Clasifica vulnerabilidades de seguridad en pipelines y artefactos, priorizando por severidad y explotabilidad	`projectId` (opcional), `severity` (opcional)
`sbom-compliance-check`	Audita SBOM y postura de cumplimiento para artefactos — riesgos de licencia, violaciones de políticas, vulnerabilidades de componentes	`artifactId` (opcional), `projectId` (opcional)
`supply-chain-audit`	Auditoría de seguridad de la cadena de suministro de software de extremo a extremo — procedencia, cadena de custodia, cumplimiento de políticas	`projectId` (opcional)
`security-exemption-review`	Revisa exenciones de seguridad pendientes y toma decisiones de aprobación o rechazo por lotes	`projectId` (opcional)
`bulk-exemption-create`	Crea exenciones de seguridad justificadas para múltiples problemas de STO con orientación explícita de alcance y duración	`projectId` (obligatorio), `exemption_type` (obligatorio), `reason` (obligatorio), filtros de problemas (opcional)
`access-control-audit`	Audita permisos de usuario, cuentas con privilegios excesivos y asignaciones de roles para aplicar el principio de mínimo privilegio	`projectId` (opcional), `orgId` (opcional)

Harness Code

Prompt	Description	Parameters
`code-review`	Revisar una solicitud de extracción — analizar el diff, los commits, los checks y los comentarios para proporcionar comentarios estructurados sobre errores, seguridad, rendimiento y estilo	`repoId` (obligatorio), `prNumber` (obligatorio), `projectId` (opcional)
`pr-summary`	Generar automáticamente un título y una descripción de PR a partir del historial de commits y el diff de una rama	`repoId` (obligatorio), `sourceBranch` (obligatorio), `targetBranch` (opcional, predeterminado: main), `projectId` (opcional)
`branch-cleanup`	Analizar ramas en un repositorio y recomendar ramas obsoletas o fusionadas para eliminar	`repoId` (obligatorio), `projectId` (opcional)

Recursos MCP

Resource URI	Description	MIME Type
`pipeline:///{pipelineId}`	Definición de YAML de pipeline	`application/x-yaml`
`pipeline:///{orgId}/{projectId}/{pipelineId}`	YAML de pipeline (con alcance explícito)	`application/x-yaml`
`executions:///recent`	Resúmenes de las últimas 10 ejecuciones de pipeline	`application/json`
`schema:///pipeline`	Esquema JSON de pipeline de Harness	`application/schema+json`
`schema:///template`	Esquema JSON de plantilla de Harness	`application/schema+json`
`schema:///trigger`	Esquema JSON de trigger de Harness	`application/schema+json`
`schema:///pipeline_v1` (Alpha)	Esquema JSON de pipeline V1 de Harness (formato simplificado de stages/steps)	`application/schema+json`
`schema:///agent-pipeline`	Esquema JSON de pipeline de agente de IA de Harness	`application/schema+json`
`agent-docs:///legacy-format`	Referencia de formato de especificación de agente heredado (`agent.step.group.steps` / `PLUGIN_TASK`), leída por el prompt `create-agent` al actualizar un agente existente en formato heredado	`text/markdown`

Filtrado de conjuntos de herramientas

De forma predeterminada, 41 de 45 conjuntos de herramientas están habilitados. Cuatro conjuntos de herramientas son opcionales y están excluidos de los valores predeterminados:

ansible — Harness Ansible (inventarios, playbooks, hosts, actividad). Opcional porque está limitado al proyecto y agrega conceptos que muchos usuarios no necesitan.
autonomous_work — Development Harness (trabajo autónomo). Opcional; consulte la descripción del conjunto de herramientas para conocer el alcance.
observability-evaluations — Reglas de evaluación de telemetría de producción programadas. Opcional porque depende del plano de control de puntuación implementado.
registries-v3 — Harness Artifact Registry v3 (paquetes, versiones, archivos, metadatos, escaneos, excepciones de firewall). Opcional hasta que se implementen las escrituras de v3, para que los agentes no tengan que desambiguar entre registros/artefactos v1 y paquetes/versiones v3.

Agregar conjuntos de herramientas con el prefijo `+`

Use el prefijo + para incluir explícitamente conjuntos de herramientas opcionales junto con todos los predeterminados:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Eliminar conjuntos de herramientas predeterminados

Use el prefijo - para excluir los conjuntos de herramientas que no necesite:

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

Combinando + y -

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

Lista de permitidos explícita

Una lista explícita separada por comas (sin prefijos) reemplaza los valores predeterminados por completo. Solo se habilitan los conjuntos de herramientas enumerados:

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

Nombres de conjuntos de herramientas disponibles:

Conjunto de herramientas	Tipos de recursos
`platform`	organización, proyecto
`pipelines`	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
`agents`	agente, ejecución_de_agente
`services`	servicio
`environments`	entorno
`connectors`	conector, catálogo_de_conectores
`infrastructure`	infraestructura
`secrets`	secreto
`logs`	registro_de_ejecución
`audit`	evento_de_auditoría
`delegates`	delegado, token_de_delegado
`repositories`	repositorio, rama, commit, contenido_de_archivo, etiqueta, regla_de_repo, regla_de_espacio
`registries`	registro, artefacto, versión_de_artefacto, archivo_de_artefacto
`file_store`	almacén_de_archivos
`templates`	plantilla
`dashboards`	panel, datos_de_panel
`idp`	entidad_idp, scorecard, verificación_de_scorecard, estadísticas_de_scorecard, estadísticas_de_verificación_de_scorecard, puntuación_idp, flujo_de_trabajo_idp, documento_técnico_idp
`pull-requests`	pull_request, revisor_de_pr, comentario_de_pr, verificación_de_pr, actividad_de_pr
`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`	agente_gitops, proyecto_argo_gitops, mapeo_proyecto_app_gitops, registro_autocreación_gitops, aplicación_gitops, clúster_gitops, repositorio_gitops, conjunto_de_aplicaciones_gitops, credencial_de_repo_gitops, evento_de_app_gitops, registro_de_pod_gitops, recurso_gestionado_gitops, acción_de_recurso_gitops, panel_gitops, árbol_de_recursos_de_app_gitops, enlace_de_clúster_gitops
`chaos`	experimento_de_caos, ejecución_de_experimento_de_caos, variable_de_experimento_de_caos, variable_de_componente_de_caos, conjunto_de_entradas_de_caos, plantilla_de_experimento_de_caos, sonda_de_caos, sonda_de_caos_en_ejecución, plantilla_de_sonda_de_caos, infraestructura_de_caos, infraestructura_k8s_de_caos, infraestructura_habilitada_para_caos, entorno_de_caos, hub_de_caos, fallo_de_hub_de_caos, fallo_de_caos, plantilla_de_fallo_de_caos, ejecución_de_experimento_de_fallo_de_caos, acción_de_caos, plantilla_de_acción_de_caos, prueba_de_carga_de_caos, servicio_de_caos, mapa_de_aplicación_de_caos, agente_descubierto, espacio_de_nombres_descubierto, servicio_descubierto, mapa_de_red_descubierto, condición_de_guardia_de_caos, regla_de_guardia_de_caos, recomendación_de_caos, riesgo_de_caos, prueba_de_dr_de_caos, riesgo_escaneado, regla_de_riesgo_de_caos, escaneo_de_riesgo_de_caos
`ccm`	perspectiva_de_costos, desglose_de_costos, serie_temporal_de_costos, resumen_de_costos, recomendación_de_costos, anomalía_de_costos, resumen_de_anomalía_de_costos, categoría_de_costos, visión_general_de_cuenta_de_costos, valor_de_filtro_de_costos, estadísticas_de_recomendación_de_costos, detalle_de_recomendación_de_costos, compromiso_de_costos
`sei`	métrica_sei, métrica_de_productividad_sei, métrica_dora_sei, equipo_sei, detalle_de_equipo_sei, árbol_organizativo_sei, detalle_de_árbol_organizativo_sei, alineación_de_negocio_sei, uso_de_ia_sei, adopción_de_ia_sei, impacto_de_ia_sei, métrica_bruta_de_ia_sei
`scs`	fuente_de_artefacto_scs, seguridad_de_artefactos, componente_de_artefacto_scs, remediación_de_artefacto_scs, cadena_de_custodia_scs, resultado_de_cumplimiento_scs, seguridad_de_repo_de_código, scs_sbom
`evidence-vault`	atestación
`sto`	problema_de_seguridad, filtro_de_problema_de_seguridad, exención_de_seguridad, diff_de_remediación
`dbops`	esquema_de_base_de_datos, instancia_de_base_de_datos, objeto_de_snapshot_de_base_de_datos, pipeline_de_autoría_llm_de_base_de_datos
`autonomous_work` (opt-in)	elemento_de_trabajo, reanudar_elemento_de_trabajo, aprobar_elemento_de_trabajo, línea_de_tiempo_de_trabajo, presupuesto_de_trabajo, fase_de_trabajo, artefacto_de_fase_de_trabajo, artefacto_de_trabajo, presupuesto, concesión_de_presupuesto, uso_de_presupuesto, clase_de_trabajo, disparador_de_trabajo, capacidad, evaluador_de_riesgo, equipo, miembro, plantilla_de_miembro, componente_de_software, conector_de_fuente_de_contenido
`access_control`	usuario, grupo_de_usuarios, cuenta_de_servicio, rol, asignación_de_rol, grupo_de_recursos, permiso
`governance`	política, conjunto_de_políticas, evaluación_de_política
`freeze`	ventana_de_congelación, congelación_global
`overrides`	anulación_de_servicio
`settings`	configuración
`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

Arquitectura

                 +------------------+
                 |   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 |
                 +-------------------+

Cómo funciona

Las herramientas son verbos genéricos: harness_list, harness_get, etc. Aceptan un parámetro resource_type que enruta al endpoint correcto de la API.
El Registro asigna cada resource_type a un ResourceDefinition — una estructura de datos declarativa que especifica el método HTTP, la ruta URL, los mapeos de parámetros de ruta/consulta y la lógica de extracción de respuestas.
El Despacho resuelve la definición del recurso, construye la solicitud HTTP (sustitución de ruta, parámetros de consulta, inyección de cuenta/org/proyecto consciente de resource_scope), llama a la API de Harness a través de HarnessClient y extrae los datos de respuesta relevantes.
El filtrado de conjuntos de herramientas (HARNESS_TOOLSETS) controla qué definiciones de recursos se cargan en el registro al inicio.
La salida estructurada se declara con outputSchema de MCP; harness_list convierte arrays y envoltorios comunes de listas en structuredContent con forma de objeto para clientes estrictos.
Los enlaces profundos se añaden automáticamente a las respuestas, proporcionando URLs directas de la interfaz de Harness para cada recurso.
El modo compacto elimina metadatos verbosos de los resultados de listas, conservando solo campos accionables (identidad, estado, tipo, marcas de tiempo, enlaces profundos) para minimizar el uso de tokens.

Añadir un nuevo tipo de recurso

Crea un nuevo archivo en src/registry/toolsets/ o añade un recurso a un conjunto de herramientas 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",
        },
      },
    },
  ],
};

Luego impórtalo en src/registry/index.ts y añádelo al array ALL_TOOLSETS. No se necesitan cambios en ningún archivo de herramientas.

Desarrollo

# 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

Estructura del proyecto

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

Elicitación

Las herramientas de escritura (harness_create, harness_update, harness_delete, harness_execute) utilizan elicitación MCP para solicitar confirmación al usuario cuando el riesgo de la acción lo requiere — solo operaciones medium_write, high_write y destructive. Las creaciones/actualizaciones/lecturas de bajo riesgo (p. ej. pipeline.create, pipeline.update, hql_query.run) proceden silenciosamente sin aviso. Cuando se muestra un aviso, el usuario ve lo que está a punto de suceder y lo acepta o rechaza, dando una aprobación real de supervisión humana para las operaciones que realmente mutan o ejecutan cosas.

Cómo funciona:

El LLM llama a una herramienta de escritura con riesgo medium_write+ (p. ej. harness_delete, harness_execute pipeline.run). Las creaciones/actualizaciones/lecturas de bajo riesgo no muestran un aviso.
El servidor envía una solicitud de elicitación al cliente con un resumen de la operación y una casilla confirm (marcada por defecto).
El usuario ve los detalles y hace clic en Aceptar (con confirm marcado) o Rechazar / Cancelar.
Si se acepta con confirm: true, la operación procede. Si se acepta con confirm sin marcar, se rechaza o se cancela, se bloquea y se informa al LLM (un rechazo explícito es autoritativo y no se omite mediante confirm: true en la llamada a la herramienta).

Soporte del cliente:

Cliente	Soporte de elicitación
Cursor	Sí
VS Code (Copilot)	Sí
Claude Desktop	Aún no
Devin Desktop	Aún no
MCP Inspector	Sí

El comportamiento de elicitación varía según el riesgo de la operación cuando falta soporte del cliente:

Nivel de riesgo	El cliente soporta elicitación	`confirm: true` pasado	Comportamiento
`read`, `low_write`	cualquiera	cualquiera	Proceder silenciosamente — no se muestra ningún aviso (`confirm` no tiene efecto en este nivel de riesgo)
`medium_write`, `high_write`, `destructive`	Sí	cualquiera	Preguntar al usuario. Proceder solo si el usuario acepta con `confirm: true` (el valor predeterminado del esquema). Un rechazo explícito, cancelación o aceptación con `confirm: false` (el usuario desmarcó la casilla) es autoritativo y no se omite mediante `confirm: true` en la llamada a la herramienta. Una aceptación que carece del campo `confirm` se trata como si el cliente no hubiera mostrado un aviso utilizable — recuperable reintentando con `confirm: true`
`medium_write`, `high_write`, `destructive`	No	No	BLOQUEAR (devolver error con sugerencia de reintentar con `confirm: true`)
`medium_write`, `high_write`, `destructive`	No	Sí	Proceder (aceptación explícita para automatización no interactiva)
cualquiera (en o por debajo de `HARNESS_AUTO_APPROVE_RISK`)	cualquiera	cualquiera	Aprobar automáticamente sin preguntar

Si elicitInput falla en tiempo de ejecución (error de transporte, método no soportado) para una operación medium_write+, la llamada se bloquea a menos que el llamador pase confirm: true. confirm: true se respeta como respaldo cuando el cliente no pudo mostrar un aviso o devolvió una aceptación degenerada ({action: "accept"} sin el campo de confirmación), pero no anula un rechazo/cancelación explícito de un cliente que completó el protocolo de elicitación.

Modo autónomo

El modo autónomo significa que el servidor procede con todas las operaciones — incluidas escrituras y acciones destructivas — sin solicitar confirmación. Actívalo configurando:

HARNESS_AUTO_APPROVE_RISK=all

Este es el límite a nivel de implementación: una vez establecido, las sesiones individuales no pueden escalar más allá (aunque pueden elegir un umbral más estricto por sesión mediante el encabezado x-harness-auto-approve-risk).

O en la configuración de tu cliente MCP:

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

Autonomía parcial: También puedes autoaprobar solo hasta un nivel de riesgo específico mientras sigues solicitando confirmación para operaciones de mayor riesgo:

# 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	Qué se autoaprueba
`none` (predeterminado)	Nada — sin umbral de autoaprobación
`low_write`	Lecturas + escrituras de bajo riesgo
`medium_write`	Lecturas + escrituras de riesgo bajo y medio
`high_write`	Lecturas + escrituras de riesgo bajo, medio y alto
`all`	Todo, incluidas operaciones destructivas

Advertencia sobre el modo autónomo: HARNESS_AUTO_APPROVE_RISK=all omite la confirmación para todas las operaciones, incluidas harness_delete. Úsalo con precaución y considera combinarlo con HARNESS_TOOLSETS para restringir qué tipos de recursos están disponibles.

Nota de migración: HARNESS_SKIP_ELICITATION=true sigue siendo compatible y se asigna a HARNESS_AUTO_APPROVE_RISK=all. Se registra una advertencia de obsolescencia en stderr. Si ambos están configurados, HARNESS_AUTO_APPROVE_RISK tiene prioridad.

Seguridad

Los secretos nunca se exponen. El tipo de recurso secret devuelve solo metadatos (nombre, tipo, alcance) — los valores de secretos nunca se incluyen en ninguna respuesta.
Las operaciones que requieren confirmación usan elicitación cuando está disponible. Cuando una acción de escritura o ejecución tiene riesgo medium_write, high_write o destructive, harness_create, harness_update, harness_delete y harness_execute intentan elicitación MCP antes de proceder (ver Elicitación). Las acciones de bajo riesgo (read, low_write — p. ej. pipeline.create, pipeline.update, hql_query.run) proceden silenciosamente sin aviso.
Riesgo medio y superior fallan de forma segura. Si no se puede obtener confirmación para operaciones medium_write, high_write o destructive, se bloquean en lugar de ejecutarse a ciegas. Anula con HARNESS_AUTO_APPROVE_RISK para flujos de trabajo autónomos.
CORS restringido al mismo origen. El transporte HTTP solo permite solicitudes del mismo origen, evitando ataques CSRF de sitios web maliciosos dirigidos al servidor MCP en localhost.
Limitación de velocidad HTTP. El transporte HTTP aplica 60 solicitudes por minuto por IP para evitar inundaciones de solicitudes.
Limitación de velocidad de API. El cliente de la API de Harness aplica un límite de 10 solicitudes por segundo para evitar alcanzar los límites de velocidad ascendentes.
Límites de paginación aplicados. Las consultas de listas están limitadas a 10,000 elementos en total y 100 por página para evitar el agotamiento de memoria.
Reintentos con retroceso. Los fallos transitorios (HTTP 429, 5xx) se reintentan con retroceso exponencial y fluctuación.
Vinculación a localhost. El transporte HTTP se vincula a 127.0.0.1 por defecto — no accesible desde la red.
Sin registro en stdout. Todos los registros van a stderr para evitar corromper el transporte JSON-RPC de stdio.

Habilidades complementarias

El servidor MCP de Harness se combina bien con Harness Skills — una colección de habilidades listas para usar de Claude Code (comandos de barra) diseñadas para flujos de trabajo comunes de Harness. Instálalos junto con este servidor MCP para obtener automatización de alto nivel como /deploy, /rollback, /triage y más sin escribir avisos personalizados.

Solución de problemas y errores comunes

Síntoma	Causa probable	Qué hacer
`HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...`	La clave de API no está en un formato admitido con ámbito de cuenta (`pat.<accountId>...` o `sat.<accountId>...`), por lo que no se puede inferir el ID de cuenta	Establezca `HARNESS_ACCOUNT_ID` explícitamente
`Unknown transport: "..."` al inicio	Argumento de transporte CLI no compatible	Use solo `stdio` o `http`
`Invalid HARNESS_TOOLSETS: ...` al inicio	Uno o más nombres de conjunto de herramientas no son reconocidos	Use solo nombres de Filtrado de conjuntos de herramientas (coincidencia exacta)
HTTP `mcp-session-id header is required...`	Se envió una solicitud de sesión sin el encabezado de sesión	Envíe `initialize` primero, luego incluya `mcp-session-id` en `POST/GET/DELETE /mcp`
HTTP `Session not found...`	La sesión caducó después de `MCP_SESSION_TTL_MS` milisegundos de inactividad o ya se cerró	Vuelva a ejecutar `initialize` para crear una nueva sesión y luego reintente con el nuevo encabezado
HTTP `405 Method Not Allowed` en `/mcp`	Método no compatible para el endpoint de MCP	Use solo `POST`, `GET`, `DELETE` o `OPTIONS`
HTTP `Invalid request`	Cuerpo JSON no válido o el cuerpo de la solicitud superó `HARNESS_MAX_BODY_SIZE_MB`	Valide el tamaño/forma de la carga útil JSON; aumente `HARNESS_MAX_BODY_SIZE_MB` si es necesario
`Unknown resource_type "..."` de las herramientas	El tipo de recurso está mal escrito o filtrado mediante `HARNESS_TOOLSETS`	Llame a `harness_describe` (con `search_term` opcional) para descubrir tipos válidos
`Missing required field "... for path parameter ..."`	Una llamada con ámbito de proyecto/org carece de identificadores	Establezca `HARNESS_ORG`/`HARNESS_PROJECT` o pase `org_id`/`project_id` por llamada de herramienta
`resource_scope "org" requires org_id...` o `resource_scope "project" requires project_id...`	Un recurso de múltiples ámbitos se forzó al ámbito de org/proyecto sin suficientes identificadores	Pase los `org_id`/`project_id` faltantes, configure `HARNESS_ORG`/`HARNESS_PROJECT`, o use `resource_scope: "account"` cuando sea compatible
`Read-only mode is enabled ... operations are not allowed`	`HARNESS_READ_ONLY=true` bloquea crear/actualizar/eliminar/ejecutar	Establezca `HARNESS_READ_ONLY=false` si se pretenden operaciones de escritura
La ejecución del pipeline falla en la verificación previa con entradas requeridas sin resolver	El `inputs` proporcionado no cubrió los marcadores de posición de tiempo de ejecución requeridos	Obtenga `runtime_input_template`, suministre claves simples faltantes, o use `input_set_ids` para entradas estructurales
La abreviatura de CI del pipeline (`branch`, `tag`, `pr_number`, `commit_sha`) no se aplicó	`inputs.build` ya se proporcionó, por lo que la expansión de abreviatura se omitió intencionalmente	Elimine `inputs.build` para usar la expansión de abreviatura, o mantenga la estructura completa explícita de `build`
La ejecución del pipeline cargó la revisión YAML incorrecta	La definición del pipeline se almacena en Git y la ejecución no especificó la rama deseada del pipeline	Pase `params.pipeline_branch` en la acción `run`; esto se asigna a Harness `branch`
`wait: true` devolvió `_wait.error`	El disparador del pipeline tuvo éxito, pero la consulta del lado del servidor falló	Vuelva a verificar el `execution_id` con `harness_get(resource_type="execution", ...)` antes de decidir si volver a ejecutar
`wait: true` devolvió `execution_timed_out: true`	La ejecución no alcanzó un estado terminal antes de `wait_timeout_seconds`	Use el `execution_id` devuelto para volver a verificar el estado; espere un estado terminal antes de ejecutar `harness_diagnose`
Los registros de ejecución están vacíos o las descargas de blobs devuelven 403	Las URL de blobs de registros alojados por Harness requieren la ruta de cliente/auth de Harness configurada, especialmente para hosts internos o autogestionados	Mantenga `HARNESS_BASE_URL` apuntando al host de Harness objetivo y use `harness_get(resource_type="execution_log", ...)` o `harness_diagnose(..., include_logs=true)` en lugar de omitir el cliente MCP
`Operation declined by user` / `Operation cancelled by user`	El usuario rechazó o canceló el diálogo de confirmación de elicitación — autoritativo	Verifique los detalles de la operación con el usuario; `confirm: true` no omite un rechazo explícito. El usuario debe aceptar la solicitud
`Operation blocked: the client could not surface a usable confirmation prompt`	El cliente carece de soporte de elicitación, `elicitInput` falló o devolvió una aceptación degenerada	Reintente con `confirm: true` para automatización no interactiva, o use un cliente que admita elicitación
`body.template_yaml (or body.yaml) is required` para crear/actualizar plantillas	Las API de plantillas esperan una carga útil YAML completa	Proporcione la cadena completa de `template_yaml` en `body`; para eliminaciones, pase `version_label` para eliminar una versión (omita para eliminar todas las versiones)
`HARNESS_BASE_URL must use HTTPS` al inicio	`HARNESS_BASE_URL` está configurado en una URL HTTP	Use HTTPS, o establezca `HARNESS_ALLOW_HTTP=true` para desarrollo local

Licencia

MIT

Harness

¿Qué puedes hacer con Harness MCP?

Documentación

Servidor MCP de Harness 2.0

Por qué usar este servidor MCP

Requisitos previos

Inicio rápido

Opción 0: Harness MCP alojado

Opción 1: npx (Recomendado)

Opción 2: Instalación global

Opción 3: Compilar desde el código fuente

Paquete del directorio MCP de Anthropic

Uso de CLI

Transporte HTTP

Modo OAuth de HarnessID

Modo multiusuario

Configuración del cliente

Harness MCP alojado

Claude Desktop (claude_desktop_config.json)

Claude Code (a través de claude mcp add)

Cursor (.cursor/mcp.json)

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

Puerta de enlace MCP

Puerta de enlace MCP de Docker

Portkey

LiteLLM

Envoy AI Gateway

Kong

Otras puertas de enlace

Docker

Kubernetes

Configuración

Búsqueda Semántica

Aplicación de HTTPS

Registro de Auditoría

Referencia de Herramientas

Flujo de trabajo de consulta de esquemas

Ejemplos de herramientas

Flujo de trabajo de ejecución de pipelines (Recomendado)

Ejecución dinámica de pipelines

Análisis forense de entradas de ejecución

Modo de espera de ejecución de pipelines

Modos de almacenamiento de pipelines

Tipos de recursos

Plataforma

Pipelines

Agentes de IA

Servicios

Entornos

Conectores

Infraestructura

Secretos

Registros de ejecución

Rastro de auditoría

Delegados

Repositorios de código

Registros de artefactos

Almacén de Archivos

Plantillas

Paneles

DevOps de Bases de Datos

Gestión de Infraestructura como Código (IaCM)

Portal de Desarrollador Interno (IDP)

Solicitudes de Extracción (Pull Requests)

Gestión de Lanzamientos

Vibe

Feature Flags

GitOps

Ingeniería del Caos

Gestión de Costos en la Nube (CCM)

Información de Ingeniería de Software (SEI)

Aseguramiento de la Cadena de Suministro de Software (SCS)

Bóveda de Evidencias

Orquestación de Pruebas de Seguridad (STO)

Control de Acceso

Gobernanza

Congelación de Despliegues

Anulaciones de Servicio

Configuración

Prompts de MCP

Claude Desktop (`claude_desktop_config.json`)

Claude Code (a través de `claude mcp add`)

Cursor (`.cursor/mcp.json`)

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

Agregar conjuntos de herramientas con el prefijo `+`