Harness

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 243 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, 243 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. 40 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 está disponible cuando necesitas datos de inventario y playbooks.
• 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: construir e implementar aplicaciones de extremo a extremo, 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 despliegues remotos/compartidos, listo para Docker y Kubernetes.
• Inicio sin configuración. Solo proporciona una clave de API de Harness. El ID de cuenta se extrae automáticamente de los tokens PAT y SAT, los valores predeterminados de org/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 de API de Harness:

1. Inicia sesión en tu cuenta de Harness
2. Ve a Mi Perfil → Claves de API → + Nueva Clave de API
3. Crea un nuevo Token bajo la clave de API; esto genera un PAT o SAT en el formato <prefix>.<accountId>.<tokenId>.<secret>
4. 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 requiere instalación, solo ejecútalo:

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

O configura la clave de 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 de 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 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 las dependencias de producción instaladas desde npm-shrinkwrap.json usando el diseño plano de npm. El CLI oficial fijado 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 del 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 despliegues remotos/compartidos.

Transporte HTTP

Cuando se ejecuta en modo HTTP, el servidor expone:

Endpoint	Método	Descripción
/mcp	POST	Endpoint JSON-RPC de MCP (solicitudes de initialize + sesión)
/mcp	GET	Flujo SSE para mensajes iniciados por el servidor (progreso, elicitación)
/mcp	DELETE	Termina una sesión MCP activa
/mcp	OPTIONS	Preflight CORS
/health	GET	Verificación de salud: devuelve { "status": "ok", "sessions": <count> }

El transporte HTTP se ejecuta en modo basado en sesiones. 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 cualquier despliegue compartido o accesible de forma remota. Cuando se establece, cada solicitud POST, GET y DELETE a /mcp debe incluir Authorization: Bearer <token>.
• Los enlaces que no son de loopback requieren HARNESS_MCP_AUTH_TOKEN de forma predeterminada. Para ejecutar sin autenticación en una interfaz que no sea de loopback 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 solicitudes ni flujos SSE activos (predeterminado 1800000, o 30 minutos).
• GET /health es el único endpoint que no es de 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 despliegue, por lo que una sesión puede reducir pero no ampliar el techo de aprobación configurado.

Modo multiusuario

Establece HARNESS_MCP_MODE=multi-user para despliegues HTTP compartidos 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 de API no incorpora un segmento de cuenta.
• Las sesiones también pueden proporcionar los encabezados x-harness-org y x-harness-project para establecer el alcance predeterminado de esa sesión.
• La clave de API de Harness fluye a través de cada llamada a la API de Harness para esa sesión, por lo que el registro 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 la protección contra el 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 org y el ID de proyecto que se usan 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 quieres 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 usa HARNESS_API_KEY en la configuración del cliente. La disponibilidad de MCP alojado se configura por cuenta de Harness, por lo que deberás 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 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, solicita a Soporte de Harness que habilite/configure MCP alojado para ese entorno, o ejecuta el servidor local/autoalojado y establece 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 alojadas y 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 tu shell, por lo que pueden fallar al encontrar npx o node después de una recarga de configuración. Soluciona 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"
      }
    }
  }
}

Encuentra tus rutas con which npx y which node en una terminal, luego asegúrate 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 (ejecuta nvm which current para encontrar la ruta exacta)
• Node del sistema: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (sin instalación)

{
  "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 (vía claude mcp add)

npx (sin instalación)

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 establece HARNESS_API_KEY en tu entorno o archivo .env.

Cursor (.cursor/mcp.json)

npx (sin instalación, 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"
      }
    }
  }
}

Ejecuta which npx en una terminal y usa esa ruta completa para command; incluye 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"
      }
    }
  }
}

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

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

npx (sin instalación)

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

¿Usas una compilación local desde el código fuente?

Reemplaza el comando con la ruta a tu index.js compilado:

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

MCP Gateway

El servidor MCP de Harness es totalmente compatible con MCP Gateways — 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 gateway compatible con MCP sin cambios de código.

¿Por qué usar un gateway?

• Gestión centralizada de credenciales — sin claves API en configuraciones de agentes
• Gobernanza y registro de 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 — restringe qué equipos pueden usar qué herramientas

Docker MCP Gateway

Registra el servidor en tu configuración de Docker MCP Gateway:

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

Portkey

Añade el servidor MCP de Harness a tu Portkey MCP Gateway 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

Añade a tu 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 el soporte MCP de Envoy AI Gateway mediante transporte HTTP:

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

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

Kong

Usa el plugin AI MCP Proxy de Kong para exponer el servidor MCP de Harness a través de tu infraestructura de gateway Kong existente.

Otros Gateways

Cualquier gateway que soporte la especificación MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, etc.) puede actuar como proxy de este servidor. Para gateways basados en stdio, usa el transporte predeterminado. Para gateways basados en HTTP, inicia el servidor con el transporte http y apunta el gateway al endpoint /mcp.

Docker

Compila y ejecuta 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

Despliega 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

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

Configuración

El servidor carga automáticamente las variables de entorno desde un archivo .env en la raíz del proyecto si existe. Copia .env.example a .env y completa tus valores. Las variables de entorno también se pueden configurar mediante tu 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 en configuración, usada para todas las sesiones) o multi-user (solo HTTP, credenciales por sesión mediante cabeceras x-harness-api-key y opcional x-harness-account-id)
HARNESS_API_KEY	Sí*	--	Token de acceso personal de Harness o token de cuenta de servicio. Requerido en modo single-user. NO debe establecerse en modo multi-user
HARNESS_ACCOUNT_ID	No	(de PAT/SAT)	Identificador de cuenta de Harness. Se extrae automáticamente de tokens PAT/SAT en modo de usuario único; las sesiones multiusuario pueden proporcionar el suyo mediante x-harness-account-id cuando la clave API no incluye uno
HARNESS_BASE_URL	No	https://app.harness.io	URL base de API/UI de Harness para stdio local o despliegues HTTP autohospedados. Establézcala en entornos como https://harness0.harness.io cuando ejecute el servidor usted mismo. No afecta al endpoint hospedado gestionado https://mcp.harness.io/mcp
HARNESS_FME_API_KEY	No	--	Credencial opcional de usuario único/autohospedado FME/Split Admin usada para recursos fme_ solo en modo legado (workspace_id). Puede ser una clave admin de Split legada o un PAT/SAT de Harness con derecho FME. Las llamadas FME van directamente a api.split.io, por lo que las credenciales OAuth/de enrutamiento de servicio hospedadas para APIs de plataforma Harness no autentican estas solicitudes. No debe establecerse en modo multi-user; FME debe usar la credencial x-harness-api-key de cada sesión. Si no se establece, FME recurre a un HARNESS_API_KEY no marcador para sesiones autohospedadas. 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_FME_BASE_URL	No	https://api.split.io	URL base de API Admin Split/FME usada por recursos fme_ solo en modo legado (workspace_id). Las URLs 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 separada por comas. Vacío carga los conjuntos predeterminados. Admite +name para incluir explícitamente conjuntos opt-in y -name para eliminar 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 para compatibilidad hacia atrás
HARNESS_ALLOW_HTTP	No	false	Permitir HARNESS_BASE_URL no HTTPS. Por defecto, el servidor impone HTTPS por seguridad. Establezca a true solo para desarrollo local contra una instancia 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 tiempo de inicialización con x-harness-pipeline-version: 0 o 1
HARNESS_MCP_ALLOWED_HOSTS	No	--	Nombres de host permitidos separados por comas por la validación de cabecera Host del transporte HTTP. mcp.harness.io se permite por defecto para enlaces localhost; agregue dominios proxy/personalizados aquí
HARNESS_MCP_AUTH_TOKEN	No	--	Token Bearer requerido en rutas HTTP /mcp cuando se establece. Requerido por defecto cuando el transporte HTTP se vincula a un host no loopback
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	No	false	Permitir explícitamente transporte HTTP no autenticado en enlaces no loopback. 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 resolución de IP de cliente (Express trust proxy). Establezca al número de proxies frente al servidor para que las claves de limitación por IP se basen en el cliente real en lugar del par de socket del proxy
HARNESS_MCP_LOG_FILE	No	~/.claude/harness-mcp.log	Archivo usado 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 registros. Desactivado por defecto 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 recolección local duradera
HARNESS_AUDIT_WEBHOOK_URL	No	--	Endpoint HTTPS que recibe eventos de auditoría por lotes. Las URLs 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 del webhook
OTEL_EXPORTER_OTLP_ENDPOINT	No	--	Habilita tramos de auditoría OpenTelemetry cuando los paquetes opcionales de OpenTelemetry están instalados
HARNESS_SEARCH_PROVIDER	No	local	Backend de búsqueda semántica: local (incrustaciones 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-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 remota. 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 pre-carga el modelo en /app/.cache/hf para evitar descargas en tiempo de ejecución. Establézcalo en una ruta de volumen persistente en implementaciones de producción
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	No	3	Descargas simultáneas máximas 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 pared de la descarga 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 por 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, los datos de entidad por cuenta usan el ID de cuenta.
none	Desactiva la búsqueda semántica por completo; recurre a scatter-gather por palabras clave 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 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 no HTTPS (p. ej., 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 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 nueva línea 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 tramos 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 detalles de configuración de OTel y atributos de tramos, 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 alcance 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 alcance: 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 alcances incluyen connector, service, environment, infrastructure, secret, file_store, template, policy y policy_set. Si resource_scope se omite, el registro utiliza el alcance predeterminado del recurso y los valores predeterminados configurados, excepto que los recursos marcados como de alcance opcional pueden omitir org/proyecto a menos que se pasen explícitamente. Las URL de Harness también pueden establecer el alcance 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. No realiza llamadas 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. Utiliza 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 reduciendo 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 requiere.
• 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 entidades 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 entidades 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:

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

2. 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).

3. 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 pipelineBranchName):

  {
    "resource_type": "pipeline",
    "action": "run",
    "resource_id": "deploy_app",
    "params": { "pipeline_branch": "feature/new-stage" },
    "inputs": { "branch": "main" },
    "wait": true
  }
  

4. Opcional: combina ambos

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

Para pipelines v1:

1. 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 a través de params.
2. Lee template_yaml y resolved_yaml para valores declarados de ${{ inputs.* }} y valores predeterminados.
3. 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 requeridos no están resueltos, la herramienta devuelve un error previo a la ejecución con las claves esperadas y conjuntos de entradas sugeridos. Puedes 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 del pipeline v0 en tiempo de ejecución y necesita ejecutarlo contra un shell de pipeline de Harness existente. Esto no reemplaza el pipeline.run normal: el pipeline v0 guardado ya debe existir, la Ejecución dinámica permitida a nivel de cuenta y de pipeline debe estar habilitada, y el llamador necesita permisos de Edición y Ejecución en el 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 de pipeline JSON; el JSON se serializa a YAML antes de la solicitud.
• Los marcadores de posición de <+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, los reintentos 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 como no habilitada, verifique tanto la configuración de Ejecución dinámica permitida 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 una falla 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 pipeline

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 del pipeline y la verificación de estado en una sola llamada de herramienta en lugar de pedirle 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 por 1.5x y tiene un tope de 30 segundos.
• En caso de éxito o falla, 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 revisión. No vuelva a ejecutar el 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: "..."}).

Pídale al Agente DevOps de IA que cree un 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

Los pipelines de Harness se pueden almacenar de tres maneras:

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

Cree un pipeline en línea (predeterminado):

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

Cree un pipeline remoto (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"
  }
}

Cree un pipeline remoto (Harness Code, sin necesidad de conector):

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

Actualice un pipeline remoto:

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

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

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

Cree un conector:

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

Elimine un disparador:

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

Liste los conjuntos de entrada para un pipeline:

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

Obtenga un conjunto de entrada específico:

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

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

Actualice 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\""
}

Elimine un conjunto de entrada:

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

Tipos de recursos

243 tipos de recursos organizados en 40 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
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				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 de blob actual.

Registros de artefactos

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

Almacén de archivos

Tipo de recurso	Lista	Obtener	Crear	Actualizar	Eliminar	Acciones de ejecución
file_store	x	x	x	x	x	list_children
file_store gestiona archivos y carpetas de Harness File Store mediante las herramientas genéricas. Admite alcance de cuenta, organización y proyecto; pase `resource_scope="account"	"org"	"project"` o pegue una URL de Harness File Store 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 conviértalo 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 elicitación.

list_children acepta tanto notación abreviada (resource_id más params.folder_name, o params.file_store_id/params.folder_identifier más params.folder_name) como un FileStoreNode body completo con identifier, name y type: "FOLDER". Los cuerpos completos usan parentIdentifier en camelCase de Harness; la notación 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 plantilla 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	Ejecutar acciones
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 workspace, luego use ese workspace_id para recursos de workspace, 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 tiene 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 se puede descubrir 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 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 workspace. 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 versión 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 deseado completo (terraform_variables / environment_variables son obligatorios en la actualización; omitir/vaciar limpia conectores y archivos de variables). La actualización de módulos también es PUT — prefiera obtener-luego-PUT para campos opcionales. Las escrituras son medium_write y requieren confirmación (elicitación 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	Eliminar	Ejecutar acciones
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:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") para encontrar el workspace.
2. harness_create / harness_update en iacm_workspace para crear desde cero o desde una plantilla (associated_template), o actualizar un workspace existente — la respuesta es solo { policy_evaluation }.
3. harness_get(resource_type="iacm_workspace", workspace_id="...") para obtener el workspace creado/actualizado.
4. 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.
5. 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.
6. 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.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") para inspeccionar recursos, salidas y fuentes de datos de Terraform.
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") para revisar entradas de costos por ejecución.
9. 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, apply o destroy.

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 Interno de Desarrolladores (IDP)

Tipo de recurso	Listar	Obtener	Crear	Actualizar	Eliminar	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
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 las ediciones de título/descripción en una llamada de actualización separada.

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 en el listado de lanzamientos se aplica del lado del cliente solo en la página actual; siga paginando con los mismos filtros cuando los resultados puedan abarcar varias páginas.

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

1. harness_list(resource_type="release_process", org_id="...", project_id="...") para descubrir definiciones de procesos de orquestación.
2. harness_schema(resource_type="release_process") (o release_activity) antes de crear/actualizar; luego harness_create / harness_update con body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="...") para encontrar lanzamientos activos o recientes (retroceso predeterminado de 30 días; opcional filters.status, filters.search_term, filters.days_back).
4. harness_get(resource_type="release", release_id="...") para detalles del lanzamiento.
5. 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.
6. 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.

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
fme_segment_definition	x	x	x	x	x

Recursos FME (Split.io) — los recursos fme_* admiten alcance de doble modo: las llamadas heredadas pasan workspace_id y acceden a la API de Split.io (api.split.io); las llamadas más nuevas pasan org_id+project_id juntos y acceden a endpoints nativos de Harness (estándar HARNESS_API_KEY/HARNESS_BASE_URL, 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. La cobertura del modo nativo de Harness es actualmente más limitada:

• fme_workspace — sin equivalente nativo de Harness; solo heredado (se usa para descubrir valores de workspace_id).

• fme_environment — list de doble modo (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 opcional offset/limit (máx. 100; harness_list size se asigna a limit); el sobre {data, limit, offset, totalCount} se promueve a items/total. La creación/actualización nativa usa isProduction (production aceptado 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 — doble modo, ambas ramas completamente conectadas. Nativo de Harness (org_id+project_id): list/get/create/delete acceden a /fme/api/v4/feature-flags (cuerpo para create: name, trafficType, opcional description/tags/owners, según CreateFeatureFlagRequest); update envía un merge-patch a /fme/api/v4/feature-flags/{name}; archive/unarchive acceden a /fme/api/v4/feature-flags/{name}/archive|unarchive (solo opcional comment — sin title, según ArchiveUnarchiveRequest); kill/restore/reallocate acceden a /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate con environment_id como parámetro de consulta (opcional comment/title, según FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update siguen siendo de doble modo (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 obtener/crear/actualizar coincide con el heredado (treatments, defaultTreatment, defaultRule, opcional rules/baselineTreatment/trafficAllocation/comment), más opcional title en modo nativo de Harness. La actualización nativa es JSON Merge Patch.

• fme_rollout_status — list de doble modo. Pasa org_id+project_id (preferido) o el obsoleto workspace_id. 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 opcional description.

• 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 heredado workspace_id.

• 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 heredado workspace_id/environment_id.

• fme_traffic_type — list de doble modo. Pasa org_id+project_id (preferido) o el obsoleto workspace_id. 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 heredada normal.

• fme_standard_segment — (Obsoleto — ver fme_segment.) El modo nativo de Harness se rechaza en cada operación (list/get) — usa fme_segment en su lugar; este recurso solo admite el contrato heredado workspace_id. No hay operación create para este recurso en ningún modo.

• fme_segment_keys — list/update aún no están implementados si org_id+project_id se pasan juntos; de lo contrario, procede como una llamada heredada normal.

• fme_segment — list/get/create/delete están conectados al endpoint real /fme/api/v4/segments (consolida fme_standard_segment/fme_rule_based_segment); cuerpo de create: name, trafficType, type (requerido — uno de standard/rule_based/large), opcional description/tags/owners.

• fme_segment_definition — solo nativo de Harness (sin soporte heredado workspace_id). list/get/create/update/delete están conectados a /fme/api/v4/segment-definitions, según Harness_Split/Main PR #12644 (abierto, aún no fusionado al momento de escribir esto — las rutas pueden cambiar). update usa JSON Merge Patch en description, el único campo mutable. No hay acción enable/disable/change_request — el backend no tiene tales endpoints para este recurso unificado.

En modo de usuario único/autoalojado, la autenticación en modo heredado 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 heredada 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 heredado: 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 habilitar/deshabilitar y solicitudes de cambio.

GitOps

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

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

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

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

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

Garantía de Cadena de Suministro de Software (SCS)

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
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 de SDLC). Listar admite alcance de cuenta/org/proyecto mediante resource_scope. Los filtros singulares de texto libre (pipeline, artifact solo, gitoid) usan search_term; una restricción adicional de Nombre usa filters.subject_name; el resumen de 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	Obtener	Crear	Actualizar	Eliminar	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 por defecto duration_days a 30 cuando no se proporciona. Para listar exenciones, pasa un tamaño de página explícito pequeño (por ejemplo filters: { "status": "Pending", "size": 5 }) y sigue el _nextPageHint devuelto en cada respuesta.

Flujo de trabajo 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 el endpoint de promoción de STO internamente. 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 es aprobación en alcance de cuenta, organización o proyecto.

Control de Acceso

Tipo de Recurso	Listar	Obtener	Crear	Actualizar	Eliminar	Ejecutar Acciones
user	x	x
user_group	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	Ejecutar Acciones
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	Descripción	Parámetros
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 etapas/pasos, 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 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, recopila requisitos, genera la especificación YAML del agente usando el esquema de pipeline de agente, confirma con el usuario, 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 el proceso de 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 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	Descripción	Parámetros
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 causa raíz, recursos afectados y remediación	projectId (opcional)
rightsizing-recommendations	Revisa y prioriza recomendaciones de ajuste de tamaño, opcionalmente crea tickets en Jira o ServiceNow	projectId (opcional), minSavings (opcional)

DevSecOps

Prompt	Descripción	Parámetros
security-review	Revisa problemas de seguridad en 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, prioriza 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 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 alcance explícito y guía de 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 imponer el principio de mínimo privilegio	projectId (opcional), orgId (opcional)

Harness Code

Prompt	Descripción	Parámetros
code-review	Revisar una pull request — analizar diff, commits, checks y comentarios para proporcionar retroalimentación estructurada sobre errores, seguridad, rendimiento y estilo	repoId (obligatorio), prNumber (obligatorio), projectId (opcional)
pr-summary	Auto-generar un título y 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

URI del recurso	Descripción	Tipo MIME
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

Filtrado de conjuntos de herramientas

Por defecto, 40 de 41 conjuntos de herramientas están habilitados. Un conjunto de herramientas es opcional y está excluido de los valores predeterminados:

• ansible — Harness Ansible (inventarios, playbooks, hosts, actividad). Es opcional porque está limitado al proyecto y añade conceptos que muchos usuarios no necesitan.

Añadir conjuntos de herramientas con el prefijo +

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

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Eliminar conjuntos de herramientas predeterminados

Usa el prefijo - para excluir conjuntos de herramientas que no necesites:

# 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 los conjuntos de herramientas listados están habilitados:

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

Nombres de conjuntos de herramientas disponibles:

Toolset	Tipos de recursos
platform	organization, project
pipelines	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
agents	agent, agent_run
services	service
environments	environment
connectors	connector, connector_catalogue
infrastructure	infrastructure
secrets	secret
logs	execution_log
audit	audit_event
delegates	delegate, delegate_token
repositories	repository, branch, commit, file_content, tag, repo_rule, space_rule
registries	registry, artifact, artifact_version, artifact_file
file_store	file_store
templates	template
dashboards	dashboard, dashboard_data
idp	idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc
pull-requests	pull_request, pr_reviewer, pr_comment, pr_check, pr_activity
feature-flags	fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition
gitops	gitops_agent, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree
chaos	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
access_control	user, user_group, service_account, role, role_assignment, resource_group, permission
governance	policy, policy_set, policy_evaluation
freeze	freeze_window, global_freeze
overrides	service_override
settings	setting
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
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
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

Arquitectura

                 +------------------+
                 |   AI Agent       |
                 |  (Claude, etc.)  |
                 +--------+---------+
                          |  MCP (stdio or HTTP)
                 +--------v---------+
                |    MCP Server     |
                | 11 Generic Tools  |
                 +--------+---------+
                          |
                 +--------v---------+
                |    Registry       |  <-- Declarative resource definitions
                |  40 Toolsets      |      (data files, not code)
                |  243 Resource Types|
                 +--------+---------+
                          |
                 +--------v---------+
                 |  HarnessClient    |  <-- Auth, retry, rate limiting
                 +--------+---------+
                          |  HTTPS
                 +--------v---------+
                 |  Harness REST API |
                 +-------------------+

Cómo funciona

1. 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.
2. 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.
3. 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 relevantes de la respuesta.
4. El filtrado de conjuntos de herramientas (HARNESS_TOOLSETS) controla qué definiciones de recursos se cargan en el registro al inicio.
5. 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.
6. Los enlaces profundos se añaden automáticamente a las respuestas, proporcionando URLs directas de la interfaz de Harness para cada recurso.
7. 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, brindando una aprobación real de supervisión humana para las operaciones que realmente mutan o ejecutan cosas.

Cómo funciona:

1. 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.
2. 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).
3. El usuario ve los detalles y hace clic en Aceptar (con confirm marcada) o Rechazar / Cancelar.
4. 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	Procede silenciosamente — no se muestra ningún aviso (confirm no tiene efecto en este nivel de riesgo)
medium_write, high_write, destructive	Sí	cualquiera	Solicita al usuario. Procede 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í	Procede (aceptación explícita para automatización no interactiva)
cualquiera (en o por debajo de HARNESS_AUTO_APPROVE_RISK)	cualquiera	cualquiera	Autoaprobación sin solicitar

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 superarlo (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 los 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 la 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, lo que previene 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 prevenir 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 prevenir 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 compatible con el á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 conjuntos 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 expiró 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 de pipeline falla antes del vuelo 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 de 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 de pipeline cargó la revisión YAML incorrecta	La definición del pipeline se almacena en Git y la ejecución no especificó la rama de pipeline deseada	Pase params.pipeline_branch en la acción run; esto se asigna a Harness pipelineBranchName
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 a una URL HTTP	Use HTTPS, o establezca HARNESS_ALLOW_HTTP=true para desarrollo local

Licencia

MIT