Harness

Harness MCP Server 2.0

MCP-сервер (Model Context Protocol), который предоставляет AI-агентам полный доступ к платформе Harness.io через 11 консолидированных инструментов и 243 типа ресурсов.

Зачем использовать этот MCP-сервер

Большинство MCP-серверов сопоставляют один инструмент с одной конечной точкой API. Для такой обширной платформы, как Harness, это означает 240+ инструментов — и LLM становятся хуже в выборе инструментов по мере роста их количества. Контекстные окна заполняются схемами, а каждая новая конечная точка означает новый код.

Этот сервер построен иначе:

• 11 инструментов, 243 типа ресурсов. Система диспетчеризации на основе реестра направляет harness_list, harness_get, harness_create и т.д. к любому ресурсу Harness — конвейерам, сервисам, окружениям, организациям, проектам, флагам функций, данным о затратах и многому другому. LLM выбирает из 11 инструментов вместо сотен.
• Полное покрытие платформы. 40 наборов инструментов по умолчанию, охватывающих CI/CD, GitOps, флаги функций, управление облачными затратами, тестирование безопасности, инженерию хаоса, DevOps для баз данных, внутренний портал разработчика, цепочку поставок ПО, управление инфраструктурой как кодом, управление релизами, управление, переопределения сервисов, граф знаний и многое другое. Опциональное покрытие Ansible доступно, когда вам нужны данные об инвентаре и плейбуках.
• Мультипроектные рабочие процессы из коробки. Агенты динамически обнаруживают организации и проекты — без необходимости жестко заданных переменных окружения. Спросите «показать неудачные выполнения во всех проектах», и агент сможет перемещаться по всей иерархии аккаунта.
• 35 шаблонов промптов. Готовые промпты для типовых рабочих процессов: сборка и развертывание приложений от начала до конца, отладка неудачных конвейеров, просмотр метрик DORA, триаж уязвимостей, оптимизация облачных затрат, аудит контроля доступа, планирование раскатки флагов функций, проверка пул-реквестов, утверждение ожидающих конвейеров и многое другое.
• Работает везде. Транспорт stdio для локальных клиентов (Claude Desktop, Cursor, Devin Desktop), HTTP-транспорт для удаленных/общих развертываний, готов к работе с Docker и Kubernetes.
• Запуск без конфигурации. Просто предоставьте ключ API Harness. Идентификатор аккаунта автоматически извлекается из токенов PAT и SAT, значения по умолчанию для организации/проекта необязательны, а фильтрация наборов инструментов позволяет открыть только то, что вам нужно.
• Расширяемость по дизайну. Добавление нового ресурса Harness означает добавление декларативного файла данных — без регистрации нового инструмента, без изменений схем, без обновления промптов.

Предварительные требования

Перед установкой или запуском сервера вам понадобится ключ API Harness:

1. Войдите в свой аккаунт Harness
2. Перейдите в Мой профиль → Ключи API → + Новый ключ API
3. Создайте новый токен в рамках ключа API — это сгенерирует PAT или SAT в формате <prefix>.<accountId>.<tokenId>.<secret>
4. Сохраните токен в надежном месте — он понадобится на следующем шаге

Подробные инструкции см. в Кратком руководстве по API Harness.

Быстрый старт

Вариант 0: Размещенный Harness MCP

Если в вашем аккаунте Harness включена размещенная служба MCP, клиенты, поддерживающие удаленные MCP-серверы, могут подключаться напрямую к управляемой конечной точке вместо запуска сервера локально.

Важно: Размещенная служба MCP использует OAuth платформы Harness, а не HARNESS_API_KEY. Она также должна быть включена/настроена для каждого аккаунта службой поддержки Harness, прежде чем конечную точку можно будет использовать.

См. Размещенный Harness MCP для примеров конфигурации.

Вариант 1: npx (рекомендуется)

Установка не требуется — просто запустите:

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

Или настройте ключ API в вашем AI-клиенте (см. Конфигурация клиента ниже).

# 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

Примечание: Идентификатор аккаунта автоматически извлекается из токенов PAT и SAT (pat.<accountId>... или sat.<accountId>...), поэтому HARNESS_ACCOUNT_ID требуется только для ключей API без встроенного сегмента аккаунта.

Вариант 2: Глобальная установка

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Вариант 3: Сборка из исходного кода

Для разработки или настройки:

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

Пакет каталога MCP Anthropic

Манифест пакета MCPB находится в [mcp-directory/](mcp-directory/), а иконка пакета 512×512 отслеживается в [icon.png](icon.png) в корне репозитория. Упакованный архив содержит корневые manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json и продакшн node_modules/.

Чтобы архив оставался небольшим, собирайте пакеты MCPB из промежуточного каталога:

pnpm prepare:mcpb

Промежуточный каталог записывается в dist/mcpb/ с установленными продакшн-зависимостями из npm-shrinkwrap.json с использованием плоской структуры npm. Зафиксированный официальный CLI MCPB проверяет его и создает dist/harness-mcp-server-<version>.mcpb.

Теги версий, соответствующие v*.*.*, автоматически публикуют этот пакет в соответствующий релиз GitHub. Чтобы заполнить существующий релиз без повторной публикации npm, запустите рабочий процесс Release вручную с его входным параметром release_tag (например, v3.2.20). Рабочий процесс извлекает и собирает именно этот тег перед заменой только его версионированного ресурса MCPB.

Использование 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

Транспорт по умолчанию — stdio, если не указано иное. Используйте http для удаленных/общих развертываний.

HTTP-транспорт

При работе в режиме HTTP сервер предоставляет:

Конечная точка	Метод	Описание
/mcp	POST	Конечная точка MCP JSON-RPC (запросы initialize + session)
/mcp	GET	SSE-поток для сообщений, инициируемых сервером (прогресс, уточнение)
/mcp	DELETE	Завершение активной MCP-сессии
/mcp	OPTIONS	Предварительный запрос CORS
/health	GET	Проверка работоспособности — возвращает { "status": "ok", "sessions": <count> }

HTTP-транспорт работает в режиме на основе сессий. Новая MCP-сессия создается при initialize, сервер возвращает заголовок mcp-session-id, и последующие запросы для этой сессии должны включать тот же заголовок.

Эксплуатационные ограничения в режиме HTTP:

• Установите HARNESS_MCP_AUTH_TOKEN для любого общего или удаленно доступного развертывания. При установке каждый запрос POST, GET и DELETE к /mcp должен включать Authorization: Bearer <token>.
• Привязки к не-loopback интерфейсам требуют HARNESS_MCP_AUTH_TOKEN по умолчанию. Чтобы запустить без аутентификации на не-loopback интерфейсе, явно установите HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true.
• POST /mcp без mcp-session-id должен быть запросом initialize.
• POST /mcp, GET /mcp и DELETE /mcp для существующих сессий требуют заголовок mcp-session-id.
• GET /mcp используется для SSE-уведомлений (обновления прогресса и запросы уточнения).
• Неактивные сессии завершаются через MCP_SESSION_TTL_MS миллисекунд после отсутствия запросов или SSE-потоков (по умолчанию 1800000, или 30 минут).
• GET /health — единственная не-MCP конечная точка.
• Размер тела запроса ограничен HARNESS_MAX_BODY_SIZE_MB (по умолчанию 10 МБ).
• Установите x-harness-pipeline-version: 0 или 1 в запросе initialize, чтобы выбрать ресурсы конвейера V0 или V1 для этой HTTP-сессии.
• Установите x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all в запросе initialize, чтобы выбрать более строгий порог автоматического утверждения для сессии. Сервер ограничивает это значение на уровне развертывания HARNESS_AUTO_APPROVE_RISK, поэтому сессия может уменьшить, но не расширить настроенный потолок утверждения.

Многопользовательский режим

Установите HARNESS_MCP_MODE=multi-user для общих HTTP-развертываний, где каждый клиент аутентифицируется как другой пользователь Harness. В этом режиме:

• HARNESS_API_KEY не должен быть установлен в конфигурации сервера — сервер не хранит учетные данные Harness.
• Каждая сессия должна предоставлять x-harness-api-key в запросе initialize. x-harness-account-id требуется только тогда, когда ключ API не содержит встроенный сегмент аккаунта.
• Сессии также могут предоставлять заголовки x-harness-org и x-harness-project для установки области действия по умолчанию для этой сессии.
• Ключ API Harness передается в каждый вызов API Harness для этой сессии, поэтому аудиторский след в Harness отражает реального пользователя.
• HARNESS_MCP_AUTH_TOKEN независим и может по-прежнему использоваться как дополнительный шлюз транспортного уровня.

# 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 управляет проверкой заголовка Host для защиты от DNS-реббиндинга, а CORS ограничивает источники браузеров. Ни то, ни другое не является аутентификацией; используйте HARNESS_MCP_AUTH_TOKEN или аутентифицированный шлюз/обратный прокси для контроля доступа.

Конфигурация клиента

Примечание: HARNESS_ORG и HARNESS_PROJECT необязательны. Они задают идентификатор организации и идентификатор проекта, используемые, когда они не указаны в вызове инструмента. Агенты могут динамически обнаруживать организации и проекты с помощью harness_list(resource_type="organization") и harness_list(resource_type="project"). Устаревшие имена HARNESS_DEFAULT_ORG_ID и HARNESS_DEFAULT_PROJECT_ID по-прежнему принимаются для обратной совместимости.

Размещенный Harness MCP

Harness также поддерживает размещенную конечную точку MCP для аккаунтов, у которых включена управляемая служба. Это полезно, когда вам нужна общая удаленная конечная точка MCP вместо запуска npx harness-mcp-v2 или самостоятельного размещения HTTP-транспорта.

Важно: Аутентификация размещенного MCP использует OAuth платформы Harness. Она не использует HARNESS_API_KEY в конфигурации клиента. Доступность размещенного MCP настраивается для каждого аккаунта Harness, поэтому вам нужно будет работать со службой поддержки Harness, чтобы включить/настроить параметр перед использованием.

Размещенная конечная точка https://mcp.harness.io/mcp — это управляемая служба. Клиентская конфигурация MCP в Claude, Cursor или Cowork не может переопределить, в какую среду Harness она направляется. Для Harness0 или другой частной SaaS-среды Harness обратитесь к службе поддержки Harness, чтобы включить/настроить размещенный MCP для этой среды, или запустите локальный/самостоятельно размещенный сервер и установите HARNESS_BASE_URL на целевой хост Harness.

Пример размещенного MCP:

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

Пример с размещенной и локальной записями:

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

Устранение неполадок npx ENOENT или node: No such file or directory

Это сбой запуска процесса клиента, а не ошибка аутентификации Harness. MCP-сервер еще не запущен, поэтому изменение HARNESS_API_KEY не повлияет на spawn npx ENOENT.

GUI-приложения (Cursor, Claude Desktop, Devin Desktop, VS Code) не всегда наследуют PATH вашей оболочки, поэтому они могут не найти npx или node после перезагрузки конфигурации. Исправьте это, используя абсолютные пути и явно установив PATH в блоке 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"
      }
    }
  }
}

Найдите свои пути с помощью which npx и which node в терминале, затем убедитесь, что каталог, содержащий node, включен в значение PATH выше. Типичные расположения:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (выполните nvm which current, чтобы найти точный путь)
• Системный Node: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (без установки)

{
  "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 (локальная установка)

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 (через claude mcp add)

npx (без установки)

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

node (локальная установка)

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

Затем установите HARNESS_API_KEY в вашем окружении или файле .env.

Cursor (.cursor/mcp.json)

npx (без установки, рекомендуется для локальных конфигураций 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"
      }
    }
  }
}

Выполните which npx в терминале и используйте этот полный путь для command; включите каталог из which node в начало PATH.

node (локальная установка)

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

Выполните which harness-mcp-v2 после npm install -g harness-mcp-v2 и используйте этот полный путь для command; включите каталог из which node в начало PATH.

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

npx (без установки)

{
  "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 (локальная установка)

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

Используете локальную сборку из исходного кода?

Замените команду на путь к вашей собранной index.js:

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

MCP Gateway

Сервер Harness MCP полностью совместим с MCP Gateway — обратными прокси, которые обеспечивают централизованную аутентификацию, управление доступом, маршрутизацию инструментов и наблюдаемость для нескольких MCP-серверов. Поскольку сервер реализует стандартный протокол MCP с транспортами stdio и HTTP, он работает за любым MCP-совместимым шлюзом без изменений кода.

Зачем использовать шлюз?

• Централизованное управление учетными данными — никаких API-ключей в конфигурациях агентов
• Управление и журналирование аудита для всех вызовов инструментов в командах
• Единая конечная точка для агентов вместо N подключений к N MCP-серверам
• Контроль доступа — ограничение того, какие команды могут использовать какие инструменты

Docker MCP Gateway

Зарегистрируйте сервер в конфигурации вашего Docker MCP Gateway:

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

Portkey

Добавьте сервер Harness MCP в ваш Portkey MCP Gateway для корпоративного управления, отслеживания затрат и маршрутизации между несколькими LLM:

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

LiteLLM

Добавьте в конфигурацию прокси LiteLLM:

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

Envoy AI Gateway

Сервер работает с поддержкой MCP в Envoy AI Gateway через HTTP-транспорт:

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

Затем настройте Envoy для маршрутизации к http://localhost:8080/mcp как внутреннему MCP-бэкенду.

Kong

Используйте плагин AI MCP Proxy от Kong, чтобы предоставить сервер Harness MCP через вашу существующую инфраструктуру шлюза Kong.

Другие шлюзы

Любой шлюз, поддерживающий спецификацию MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers и т. д.), может проксировать этот сервер. Для шлюзов на основе stdio используйте транспорт по умолчанию. Для шлюзов на основе HTTP запустите сервер с транспортом http и укажите шлюзу на конечную точку /mcp.

Docker

Соберите и запустите сервер как 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

Контейнер по умолчанию работает в HTTP-режиме на порту 3000 со встроенной проверкой работоспособности.

Kubernetes

Разверните в кластере Kubernetes, используя предоставленные манифесты:

# 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

Развертывание запускает 2 реплики с проверками готовности/жизнеспособности, ограничениями ресурсов и контекстом безопасности без прав root. Сервис открывает порт 80 внутри (нацеливаясь на порт контейнера 3000).

Конфигурация

Сервер автоматически загружает переменные окружения из файла .env в корне проекта, если он существует. Скопируйте .env.example в .env и заполните свои значения. Переменные окружения также можно задать через вашу оболочку или конфигурацию MCP-клиента.

Переменная	Обязательная	По умолчанию	Описание
HARNESS_MCP_MODE	Нет	single-user	Режим развертывания: single-user (API-ключ в конфигурации, используется для всех сессий) или multi-user (только HTTP, учетные данные для каждой сессии через заголовки x-harness-api-key и необязательные x-harness-account-id)
HARNESS_API_KEY	Да*	--	Персональный токен доступа Harness или токен сервисного аккаунта. Требуется в режиме single-user. НЕ должен быть установлен в режиме multi-user
HARNESS_ACCOUNT_ID	Нет	(из PAT/SAT)	Идентификатор аккаунта Harness. Автоматически извлекается из токенов PAT/SAT в однопользовательском режиме; многопользовательские сессии могут предоставить свой собственный через x-harness-account-id, когда API-ключ не содержит встроенный идентификатор
HARNESS_BASE_URL	Нет	https://app.harness.io	Базовый URL API/интерфейса Harness для локального stdio или самостоятельного HTTP-развертывания. Установите для таких сред, как https://harness0.harness.io, при самостоятельном запуске сервера. Не влияет на управляемый хостинг-эндпоинт https://mcp.harness.io/mcp
HARNESS_FME_API_KEY	Нет	--	Необязательные учетные данные администратора FME/Split для однопользовательского/самостоятельного режима, используемые для ресурсов fme_ только в устаревшем (workspace_id) режиме. Это может быть устаревший ключ администратора Split или PAT/SAT Harness с правами FME. Вызовы FME идут напрямую в api.split.io, поэтому учетные данные хостинга OAuth/сервисной маршрутизации для API платформы Harness не аутентифицируют эти запросы. Не должен быть установлен в режиме multi-user; FME должен использовать учетные данные x-harness-api-key каждой сессии. Если не установлен, FME использует не-плейсхолдер HARNESS_API_KEY для самостоятельных сессий. Режим Harness-native (org_id+project_id) игнорирует это и использует стандартные HARNESS_API_KEY/HARNESS_BASE_URL вместо этого
HARNESS_FME_BASE_URL	Нет	https://api.split.io	Базовый URL API администратора Split/FME, используемый ресурсами fme_ только в устаревшем (workspace_id) режиме. HTTP-URL требуют HARNESS_ALLOW_HTTP=true для локальной разработки. Режим Harness-native (org_id+project_id) игнорирует это и использует стандартные HARNESS_API_KEY/HARNESS_BASE_URL вместо этого
HARNESS_ORG	Нет	--	Идентификатор организации. Используется, когда org_id не указан для каждого вызова инструмента. Если опущен, org_id должен быть указан явно. Агенты также могут динамически обнаруживать организации через harness_list(resource_type="organization")
HARNESS_PROJECT	Нет	--	Идентификатор проекта. Используется, когда project_id не указан для каждого вызова инструмента. Агенты также могут динамически обнаруживать проекты через harness_list(resource_type="project")
HARNESS_API_TIMEOUT_MS	Нет	30000	Таймаут HTTP-запроса в миллисекундах
HARNESS_MAX_RETRIES	Нет	3	Количество повторных попыток при временных сбоях (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	Нет	10	Максимальный размер тела HTTP-запроса в МБ для транспорта http
HARNESS_RATE_LIMIT_RPS	Нет	10	Ограничение запросов на стороне клиента (запросов в секунду) к API Harness
LOG_LEVEL	Нет	info	Уровень детализации журнала: debug, info, warn, error
HARNESS_TOOLSETS	Нет	(по умолчанию)	Список наборов инструментов через запятую. Пусто загружает наборы инструментов по умолчанию. Поддерживает +name для явного включения дополнительных наборов и -name для удаления наборов по умолчанию (см. Фильтрация наборов инструментов)
HARNESS_READ_ONLY	Нет	false	Блокировать все изменяющие операции (создание, обновление, удаление, выполнение). Разрешены только список и получение. Полезно для общих/демонстрационных сред
HARNESS_AUTO_APPROVE_RISK	Нет	none	Порог автоматического подтверждения на основе риска для автономных рабочих процессов. Операции с риском на этом уровне или ниже выполняются без подтверждения. Значения: none, low_write, medium_write, high_write, all. См. Элиситация
HARNESS_SKIP_ELICITATION	Нет	false	Устарело — используйте HARNESS_AUTO_APPROVE_RISK=all вместо этого. Сохранено для обратной совместимости
HARNESS_ALLOW_HTTP	Нет	false	Разрешить не-HTTPS HARNESS_BASE_URL. По умолчанию сервер обеспечивает HTTPS для безопасности. Установите true только для локальной разработки с экземпляром Harness без TLS
HARNESS_PIPELINE_VERSION	Нет	0	(Альфа) Версия YAML-конвейера. 0 загружает тип ресурса pipeline и исключает pipeline_v1; 1 загружает pipeline_v1 и исключает pipeline. HTTP-сессии могут переопределить это во время инициализации с помощью x-harness-pipeline-version: 0 или 1
HARNESS_MCP_ALLOWED_HOSTS	Нет	--	Список имен хостов через запятую, разрешенных проверкой заголовка Host для HTTP-транспорта. mcp.harness.io разрешен по умолчанию для привязок localhost; добавьте прокси/пользовательские домены здесь
HARNESS_MCP_AUTH_TOKEN	Нет	--	Bearer-токен, требуемый на HTTP-маршрутах /mcp при установке. Требуется по умолчанию, когда HTTP-транспорт привязан к не-loopback хосту
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	Нет	false	Явно разрешить неаутентифицированный HTTP-транспорт на не-loopback привязках. Используйте только за другим аутентифицированным контролем
HARNESS_MCP_TRUST_PROXY	Нет	0	Количество переходов обратного прокси / балансировщика нагрузки для доверия при определении IP клиента (Express trust proxy). Установите количество прокси перед сервером, чтобы ограничение скорости по IP основывалось на реальном клиенте, а не на сокетном пире прокси
HARNESS_MCP_LOG_FILE	Нет	~/.claude/harness-mcp.log	Файл, используемый для диагностики отключения/сбоя stdio, когда stderr может быть недоступен
HARNESS_LOG_UNSAFE_BODIES	Нет	false	Включать необработанные тела запросов/ответов в журналы. По умолчанию выключено, так как тела могут содержать секреты; включайте только для локальной отладки
HARNESS_AUDIT_FILE	Нет	--	Добавлять события аудита в файл JSON с разделителями строк для надежного локального сбора
HARNESS_AUDIT_WEBHOOK_URL	Нет	--	HTTPS-эндпоинт, получающий пакетные события аудита. HTTP-URL требуют HARNESS_ALLOW_HTTP=true для локальной разработки
HARNESS_AUDIT_WEBHOOK_TOKEN	Нет	--	Необязательный bearer-токен, отправляемый в вебхук аудита
HARNESS_AUDIT_WEBHOOK_BATCH_SIZE	Нет	10	Количество событий аудита для пакетной отправки перед сбросом вебхука
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	Нет	5000	Максимальное время удержания событий аудита перед сбросом вебхука
OTEL_EXPORTER_OTLP_ENDPOINT	Нет	--	Включает OpenTelemetry-спаны аудита при установке дополнительных пакетов OpenTelemetry
HARNESS_SEARCH_PROVIDER	Нет	local	Бэкенд семантического поиска: local (встроенные ONNX-эмбеддинги, по умолчанию), remote (внешний сервис поиска через HTTP, требуется для многопользовательского режима) или none (отключить семантический поиск, использовать только ключевой scatter-gather). Используйте none в изолированных средах или когда нежелательна загрузка модели при запуске
HARNESS_SEARCH_SERVICE_URL	Нет	--	Базовый URL удаленного сервиса поиска при HARNESS_SEARCH_PROVIDER=remote (например, http://search-svc:8080). Требуется при использовании провайдера remote
HARNESS_SEARCH_SERVICE_HEADERS	Нет	--	JSON-объект заголовков, отправляемых с каждым запросом к удалённому поисковому сервису. Поддерживает любую схему аутентификации: {"Authorization":"Bearer tok"}, {"x-api-key":"key"} или несколько внутренних заголовков для взаимодействия между сервисами
HARNESS_HF_CACHE_DIR	Нет	/tmp/hf-cache	Каталог для кэша модели @huggingface/transformers, используемого поисковым провайдером local. Docker-образ предварительно встраивает модель в /app/.cache/hf, чтобы избежать загрузок во время выполнения. В производственных развёртываниях укажите путь к постоянному тому
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	Нет	3	Максимальное количество одновременных загрузок блобов журналов, выполняемых harness_diagnose при получении журналов для неудачных шагов. Увеличивайте только в том случае, если задержка диагностики определяется временем ожидания загрузки журналов и у пода есть запас памяти

Семантический поиск

harness_search использует семантическую маршрутизацию для сужения scatter-gather API-вызовов перед распределением по Harness. Доступны три поисковых провайдера:

Провайдер	Когда использовать
local (по умолчанию)	Однопользовательский режим stdio. Запускает all-MiniLM-L6-v2 в процессе через @huggingface/transformers. При первом использовании загружает модель ~23 МБ; последующие запуски используют кэш.
remote	Многопользовательский режим HTTP (размещается Harness). Делегирует эмбеддинги и поиск внешнему поисковому сервису. Изоляция тенантов обеспечивается через tenant_id — статические знания/документация используют global, данные сущностей по аккаунтам используют ID аккаунта.
none	Полностью отключает семантический поиск; возвращается к ключевому scatter-gather по всем типам ресурсов.

Конфигурация удаленного провайдера:

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

Локальное тестирование удаленного провайдера с включенным заглушечным сервисом (без внешних зависимостей):

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

Заглушка (stub-search-service.py) реализует тот же контракт /v1/health, /v1/ingest и /v1/search, что и производственный поисковый сервис. Она использует простой эмбеддинг на основе мешка символов, поэтому загрузка модели не требуется — результаты семантически правдоподобны, но не производственного качества.

Принудительное использование HTTPS

HARNESS_BASE_URL должен использовать HTTPS по умолчанию. Если вы укажете не-HTTPS URL (например, http://localhost:8080), сервер откажется запускаться с сообщением:

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

Журналирование аудита

Все операции Harness API, распределяемые через реестр (list, get, create, update, delete и execute), генерируют структурированные события аудита, когда настроены приемники аудита. Изменяющие события включают путь подтверждения, используемый при элиситации или автоматическом одобрении, когда присутствует контекст подтверждения; события чтения в настоящее время опускают метаданные подтверждения. Локальные инструменты метаданных и обнаружения схемы, которые обходят реестр, такие как harness_describe и harness_schema, не являются частью этого потока аудита. Приемник stderr зарегистрирован по умолчанию, но проходит через обычный логгер и подчиняется LOG_LEVEL; настройте файловые или вебхук-приемники для долговременного сбора аудита:

• HARNESS_AUDIT_FILE добавляет JSON-события с разделителями строк для локального сбора.
• HARNESS_AUDIT_WEBHOOK_URL отправляет пакеты { "events": [...] } на HTTPS-вебхук, опционально с HARNESS_AUDIT_WEBHOOK_TOKEN. Неудачные пакеты повторно ставятся в очередь с ограниченной емкостью и в конечном итоге отбрасываются с предупреждением, а не блокируют выполнение инструментов.
• OTEL_EXPORTER_OTLP_ENDPOINT включает аудит-спаны, когда установлены опциональные зависимости OpenTelemetry. Приемник повторно использует существующий провайдер трассировок, если он зарегистрирован, в противном случае он инициализирует автономный OTLP-экспортер.

Каждое событие включает имя инструмента, тип ресурса, операцию, идентификаторы, временную метку, риск, результат, HTTP-метод/путь, длительность и метод подтверждения, когда применимо. Приемники аудита — это телеметрия с максимальными усилиями; проблемы доставки регистрируются и никогда не воспроизводятся и не изменяют базовую операцию Harness API. Подробности настройки OTel и атрибуты спанов см. в specs/005-otel-audit-sink.md.

Справочник инструментов

Сервер предоставляет 11 MCP-инструментов. Большинство API-инструментов принимают org_id и project_id как опциональные переопределения — если они опущены, используются HARNESS_ORG и HARNESS_PROJECT. harness_describe — это только локальные метаданные и не использует область org/project.

Поддержка URL: Большинство API-ориентированных инструментов принимают параметр url — вставьте URL интерфейса Harness, и сервер автоматически извлечет org, project, тип ресурса, ID ресурса, ID пайплайна и ID выполнения. harness_describe не принимает url.

Поддержка области: Типы ресурсов с вариантами account/org/project предоставляют supportedScopes в harness_describe. Передайте resource_scope, когда нужен конкретный уровень:

• resource_scope: "account" отправляет только accountIdentifier.
• resource_scope: "org" отправляет accountIdentifier и orgIdentifier.
• resource_scope: "project" отправляет идентификаторы account, org и project.

Текущие ресурсы с несколькими областями включают connector, service, environment, infrastructure, secret, file_store, template, policy и policy_set. Если resource_scope опущен, реестр использует область по умолчанию для ресурса и настроенные значения по умолчанию, за исключением ресурсов, помеченных как опциональная область, которые могут опускать org/project, если они явно не переданы. URL-адреса Harness также могут автоматически устанавливать область, когда путь содержит контекст уровня account или project.

Структурированный вывод: Каждый инструмент объявляет MCP outputSchema. harness_list нормализует спискообразные ответы Harness в объектно-структурированное содержимое, чтобы строгие клиенты могли его проверять: массивы верхнего уровня становятся { "items": [...], "total": <count>, "page": <page> }, а общие ключи-обертки, такие как content, data, body, objects или features, поднимаются до items при необходимости. Текстовый ответ по-прежнему содержит компактный JSON-полезный груз, возвращаемый всем клиентам.

Инструмент	Описание
harness_describe	Обнаружение доступных типов ресурсов, операций и полей. Без вызова API — возвращает локальные метаданные реестра.
harness_schema	Получение точных определений YAML/JSON Schema и примеров для создания/обновления ресурсов. Схемы конвейеров/шаблонов включены в комплект; схемы коннекторов, окружений, сервисов, секретов и инфраструктуры являются схемами сущностей с учетом области действия, полученными из встроенных снимков или NG /yaml-schema; схемы release_process и release_activity загружаются в реальном времени из RMG /api/yamlSchema. Поддерживает детальное изучение через path.
harness_list	Список ресурсов заданного типа с фильтрацией, поиском и пагинацией.
harness_get	Получение одного ресурса по его идентификатору.
harness_create	Создание нового ресурса. Поддерживает встроенные и удаленные (на основе Git) конвейеры. Запрашивает подтверждение пользователя через elicitation.
harness_update	Обновление существующего ресурса. Поддерживает встроенные и удаленные (на основе Git) конвейеры. Запрашивает подтверждение пользователя через elicitation.
harness_delete	Удаление ресурса. Запрашивает подтверждение пользователя через elicitation. Деструктивная операция.
harness_execute	Выполнение действия над ресурсом (запуск/повторный запуск конвейера, импорт конвейера из Git, переключение флага, синхронизация приложения). Запрашивает подтверждение пользователя через elicitation. Для запусков конвейеров используйте описанный ниже рабочий процесс с входными данными времени выполнения (поддерживает сокращенное развертывание branch/tag/pr_number/commit_sha).
harness_search	Поиск по типам ресурсов Harness с помощью одного запроса. Использует семантическую маршрутизацию (локальные all-MiniLM-L6-v2 ONNX-эмбеддинги, 384-мерные) для прогнозирования релевантных типов ресурсов из корпуса knowledge, индексируемого при запуске — обычно сужая выбор с ~163 типов до 1–8 перед scatter-gather. При низкой семантической уверенности выполняется полный поиск по ключевым словам scatter-gather. Ответ включает semantic_routed и types_skipped, когда маршрутизация срабатывает. См. docs/search-guidelines.md о том, как сделать новые типы ресурсов обнаруживаемыми.
harness_diagnose	Диагностика ресурсов pipeline, connector, delegate и gitops_application (псевдонимы: execution -> pipeline, gitops_app -> gitops_application). Для конвейеров возвращает тайминги стадий/шагов и детали сбоев; для коннекторов/делегатов/GitOps-приложений возвращает целевые сигналы работоспособности и устранения неполадок.
harness_status	Получение панели состояния проекта в реальном времени — последние выполнения, частота сбоев и глубокие ссылки.

Рабочий процесс поиска схем

Используйте harness_schema перед созданием или обновлением ресурсов на основе YAML, чтобы агенты могли копировать точные имена полей и ограничения, а не угадывать их из описания.

• Встроенные схемы включают pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 и agent-pipeline.
• Схемы сущностей включают connector, environment, service, secret и infrastructure. Они учитывают область действия (account, org или project) и требуют org_id/project_id, когда выбранная область этого требует.
• Определения Release Management (release_process, release_activity) загружают живую JSON Schema из RMG /api/yamlSchema (не встроенную). Передайте scope, org_id и project_id при ограничении области до организации или проекта.
• Встроенные снимки сущностей используются в первую очередь, если они соответствуют учетной записи времени выполнения; в противном случае инструмент обращается к API Harness NG /yaml-schema и кэширует результат.
• Опустите path для сводки полей/разделов, затем передайте разделенный точками path, чтобы изучить вложенное определение.

Примеры:

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

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

Сопровождающие могут обновить встроенные снимки сущностей с помощью pnpm sync-entity-schemas, когда схемы YAML сущностей Harness изменяются.

Примеры инструментов

Обнаружение доступных ресурсов:

{ "resource_type": "pipeline" }

Список организаций в учетной записи:

{ "resource_type": "organization" }

Список проектов в организации:

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

Список конвейеров в проекте:

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

Получение конкретного сервиса:

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

Запуск конвейера:

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

Переключение флага функции:

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

Поиск по всем типам ресурсов:

{ "query": "payment-service" }

Диагностика выполнения по идентификатору (режим сводки — по умолчанию):

{ "execution_id": "abc123XYZ" }

Диагностика по URL Harness:

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

Диагностика подключения коннектора:

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

Диагностика работоспособности делегата:

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

Диагностика GitOps-приложения (с параметрами):

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

Получение последнего отчета о выполнении конвейера:

{ "pipeline_id": "my-pipeline" }

Полный режим диагностики с YAML и журналами неудачных шагов:

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

Режим сводки с включенными журналами (лучшее из обоих):

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

Получение статуса состояния проекта:

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

Список схем баз данных, отфильтрованных по типу миграции:

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

Список экземпляров баз данных для схемы:

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

Получение разрешенного конвейера создания LLM для схемы и экземпляра:

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

Список имен объектов снимка (например, таблиц) для экземпляра схемы:

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

Получение полных метаданных снимка для конкретных именованных объектов:

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

Рабочий процесс запуска конвейера (рекомендуется)

Для конвейеров v0 используйте эту последовательность, чтобы уменьшить ошибки ввода во время выполнения:

1. Обнаружение обязательных входных данных времени выполнения

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• Возвращенный шаблон показывает заполнители <+input>, которым нужны значения.

2. Выбор стратегии ввода

• Простые переменные: передайте плоские пары ключ-значение inputs (например, {"branch":"main","env":"prod"}).

• Сложные/структурные входные данные: используйте input_set_ids (блоки CI codebase/build и вложенные входные данные шаблонов лучше всего обрабатывать таким образом).

• Сокращенные ключи CI codebase (только для запуска конвейера):

  Сокращенный ключ	Расширенная структура
  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>

• Ограничение: сокращенное развертывание пропускается, когда inputs.build уже присутствует (явный build имеет приоритет).

3. Выполнение запуска

• harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)

• Для конвейеров на основе Git, чей YAML должен загружаться из ветки, отличной от ветки по умолчанию, передайте params.pipeline_branch (отправляется в Harness как pipelineBranchName):

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

4. Необязательно: комбинирование обоих

• Используйте input_set_ids для базовой формы и inputs для простых переопределений.

Для конвейеров v1:

1. Получите harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>"). Для конвейеров на основе Git передайте branch_name, connector_ref и repo_name через params.
2. Прочитайте template_yaml и resolved_yaml для объявленных значений ${{ inputs.* }} и значений по умолчанию.
3. Запустите harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}). Сервер оборачивает эти значения под корнем YAML inputs: и отправляет тело inputs_yaml API.

Если обязательные поля не разрешены, инструмент возвращает ошибку предварительной проверки с ожидаемыми ключами и предлагаемыми наборами входных данных. Вы можете просмотреть доступные сокращенные сопоставления с помощью harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Динамическое выполнение конвейера

Use pipeline_dynamic_execution.run, когда агент или внешняя система генерирует полный YAML конвейера v0 во время выполнения и ему нужно запустить его против существующей оболочки конвейера Harness. Это не замена обычного pipeline.run: сохраненный конвейер v0 уже должен существовать, на уровне аккаунта и уровне конвейера должна быть включена опция Allow Dynamic Execution, а вызывающему нужны права Edit и Execute на конвейер.

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

Ограничения:

• body должен быть объектом с полем yaml. Сырые строковые тела отклоняются публичной схемой harness_execute.
• body.yaml может быть YAML-строкой или JSON-объектом конвейера; JSON сериализуется в YAML перед запросом.
• Плейсхолдеры времени выполнения <+input> не разрешаются этим API. Отправляйте полностью разрешенный YAML.
• Наборы входных данных, выборочное выполнение стадий, повторные попытки и триггеры не поддерживаются конечной точкой динамического выполнения.
• Действие — high_write и использует обычный путь подтверждения/автоодобрения. Ответ проецирует оболочку API на { "execution_id": "...", "status": "..." } и включает ссылку выполнения openInHarness, когда доступны данные области.

Если Harness отклоняет запуск как не включенный, проверьте как настройку Allow Dynamic Execution на уровне аккаунта, так и переключатель на уровне конвейера в Pipeline -> Advanced Options -> Dynamic Execution Settings.

Криминалистика входных данных выполнения

Используйте execution_inputs после запуска, чтобы проверить объединенный входной YAML, который создал конкретное выполнение. Это полезно, когда сбой зависит от объединения наборов входных данных, веток наборов входных данных на основе Git или значений триггеров/времени выполнения, которые трудно восстановить только со страницы выполнения.

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

Ответ get проецируется на:

• executionId — ID выполнения плана из resource_id.
• inputSetYaml — объединенный входной YAML времени выполнения, использованный для запуска, или null.
• inputSetTemplateYaml — шаблон входа на момент выполнения, или null.
• resolvedYaml — YAML с разрешенными выражениями, когда resolve_expressions=true, в противном случае обычно null.
• inputSetDetails — сохраненные наборы входных данных, которые внесли вклад, как пары { identifier, name }.
• inputSetBranchName — исходная ветка для наборов входных данных на основе Git, или null.

execution_inputs — только для чтения и с низким риском. Если resolve_expressions опущен, сервер опускает параметры запроса API, и Harness использует свой режим разрешения по умолчанию UNKNOWN.

Режим ожидания выполнения конвейера

Для pipeline.run, pipeline.retry и pipeline_v1.run передайте wait: true, чтобы сервер опрашивал до тех пор, пока выполнение не достигнет конечного статуса. Это позволяет объединить запуск конвейера и проверку статуса в одном вызове инструмента, вместо того чтобы просить клиента или LLM выполнять цикл опроса.

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

Поведение режима ожидания:

• Таймаут по умолчанию — 600 секунд; допустимый диапазон — от 10 секунд до 7200 секунд.
• Начальный интервал опроса по умолчанию — 3 секунды, увеличивается с коэффициентом 1.5x и ограничивается 30 секундами.
• При успехе или сбое ответ включает такие поля, как execution_id, execution_status, execution_terminal, execution_elapsed_ms и execution_poll_count.
• Если таймаут срабатывает, исходный триггер все равно завершился успешно; ответ включает execution_timed_out: true и _wait.hint с последним наблюдаемым статусом.
• Если опрос завершается сбоем после успешного срабатывания триггера, ответ включает _wait.error и подсказку для повторной проверки. Не запускайте конвейер вслепую повторно, если вы не подтвердили, что первое выполнение не запущено.
• Конечные статусы сбоя включают _diagnose_hint, указывающий на harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Попросите AI DevOps Agent создать конвейер:

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

Обновите сервис с помощью естественного языка:

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

Режимы хранения конвейеров

Конвейеры Harness могут храниться тремя способами:

Режим	Описание	Когда использовать
Встроенный	YAML конвейера хранится в Harness	По умолчанию. Простейшая настройка, Git не требуется.
Удаленный (внешний Git)	YAML конвейера хранится в GitHub, GitLab, Bitbucket и т.д.	Команды, использующие конвейер-как-код на основе Git с внешним провайдером.
Удаленный (Harness Code)	YAML конвейера хранится в репозитории Harness Code	Команды, использующие встроенный Git-хостинг Harness.

Создать встроенный конвейер (по умолчанию):

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

Создать удаленный конвейер (внешний Git — например, 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"
  }
}

Создать удаленный конвейер (Harness Code — коннектор не нужен):

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

Обновить удаленный конвейер:

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

Импортировать конвейер из внешнего Git-репозитория:

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

Импортировать конвейер из репозитория 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"
  }
}

Создать коннектор:

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

Удалить триггер:

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

Список наборов входных данных для конвейера:

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

Получить конкретный набор входных данных:

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

Создать набор входных данных:

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

Обновить набор входных данных:

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

Удалить набор входных данных:

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

Типы ресурсов

243 типа ресурсов, организованных в 40 наборов инструментов. Каждый тип ресурса поддерживает подмножество операций CRUD и необязательные действия выполнения.

Платформа

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
organization	x	x	x	x	x
project	x	x	x	x	x

Конвейеры

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
pipeline	x	x	x	x	x	run, retry
pipeline_v1 (Альфа)	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

Оба типа ресурсов YAML конвейера доступны, когда включен набор инструментов конвейеров. HARNESS_PIPELINE_VERSION и HTTP-заголовок инициализации x-harness-pipeline-version выбирают предпочтение версии по умолчанию; они не скрывают другую версию.

AI-агенты

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
agent	x	x	x	x	x
agent_run	x

Сервисы

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
service	x	x	x	x	x

Окружения

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
environment	x	x	x	x	x	move_configs

Коннекторы

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
connector	x	x	x	x	x	test_connection
connector_catalogue	x

Инфраструктура

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
infrastructure	x	x	x	x	x	move_configs

Секреты

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
secret	x	x

Журналы выполнения

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
execution_log		x

Аудит-трейл

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
audit_event	x	x

Делегаты

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
delegate	x
delegate_token	x	x	x		x	revoke, get_delegates

Репозитории кода

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
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

Создание commit фиксирует одно или несколько файловых действий напрямую через API Harness Code без клонирования. Передайте body.title, body.branch и body.actions; каждое действие — это CREATE, UPDATE, DELETE или MOVE, и для UPDATE требуется текущий SHA блоба.

Реестры артефактов

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

Файловое хранилище

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Действия выполнения
file_store	x	x	x	x	x	list_children
file_store управляет файлами и папками Harness File Store через универсальные инструменты. Он поддерживает область действия account, org и project; передайте `resource_scope="account"	"org"	"project"` или вставьте URL Harness File Store, чтобы сервер мог определить область действия и идентификаторы.

Типичные вызовы:

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

Ограничения multipart-тела:

• Создание/обновление принимает JSON body, затем преобразует его в multipart/form-data для /ng/api/file-store.
• name, type (FILE или FOLDER) и parent_identifier обязательны; используйте литерал "Root" только для корня выбранной области действия.
• Создание FILE требует ровно одно из content (строка UTF-8) или content_base64 (валидная непустая base64). Обновление FILE может опускать содержимое для обновлений только метаданных или предоставлять ровно одно поле содержимого для замены содержимого.
• Создание/обновление FOLDER должно опускать content и content_base64.
• Необязательный file_usage должен быть MANIFEST_FILE, CONFIG или SCRIPT; необязательные скалярные метаданные, такие как description, mime_type, path и tags, должны быть строками.
• Загружаемое содержимое ограничено 100 МБ. Подтверждающие запросы скрывают предпросмотры content, content_base64 и contentBase64 перед запросом.

list_children принимает либо сокращенную форму (resource_id плюс params.folder_name, или params.file_store_id/params.folder_identifier плюс params.folder_name), либо полный FileStoreNode body с identifier, name и type: "FOLDER". Полные тела используют Harness camelCase parentIdentifier; сокращенная форма может использовать params.parent_identifier.

Шаблоны

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
template	x	x	x	x	x

Операции с шаблонами используют пути сервиса Harness Template (/template/api/templates...). Создание и обновление требуют полной строки YAML шаблона в body.template_yaml или body.yaml; version_label нацелен на конкретную версию для обновления/удаления, тогда как удаление без version_label удаляет все версии.

Панели мониторинга

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
dashboard	x	x
dashboard_data		x

Database DevOps

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
database_schema	x	x	x	x	x
database_instance	x	x	x	x	x
database_snapshot_object	x	x
database_llm_authoring_pipeline		x

Управление инфраструктурой как кодом (IaCM)

Ресурсы IaCM включены по умолчанию и в основном ограничены проектом. Начните с iacm_workspace, чтобы найти идентификаторы рабочих областей, затем используйте этот workspace_id для ресурсов рабочих областей, затрат и диффов активности. Используйте iacm_variable_set для переиспользуемых наборов переменных на уровне account, org или project. Реестр провайдеров ограничен account.

iacm_module охватывает область действия account, org и project. По умолчанию используется реестр account; каждая операция (список, получение, создание, обновление) отправляет одинаковые параметры запроса scope_org / scope_project, поэтому созданный вами модуль обнаруживается в области действия, где вы его создали. Выберите область действия с помощью resource_scope="account" | "org" | "project" плюс org_id/project_id. Ограничение области действия является добровольным: когда resource_scope опущен, org_id/project_id применяются только если вы передаете их явно — настроенные значения по умолчанию HARNESS_ORG/HARNESS_PROJECT не применяются, поэтому фоновая конфигурация проекта не может молча зарегистрировать модуль account под проектом. Собственные поля org/project тела модуля определяют его Git-коннектор и не связаны с этой областью видимости.

Создание/обновление iacm_workspace возвращает только { policy_evaluation } — затем выполните harness_get, чтобы получить рабочую область. Создание/обновление iacm_variable_set и iacm_module возвращает сам ресурс. Создание iacm_provider возвращает только { id } — затем выполните harness_get; обновление ориентировано только на версии (POST/PUT /providers/{id}/version) — нет PUT для метаданных. Запись версий может возвращать пустое тело; HarnessClient нормализует это до { status: "SUCCESS", message: "No content" }.

Обновление набора переменных — это HTTP PUT с коллекциями полной замены — всегда сначала harness_get, затем PUT полного желаемого тела (terraform_variables / environment_variables обязательны при обновлении; опустите/очистите для удаления коннекторов и файлов переменных). Обновление модуля также является PUT — предпочтительно get-then-put для необязательных полей. Записи являются medium_write и требуют подтверждения (elicitation или confirm: true).

RBAC для наборов переменных и реестра провайдеров (iac_variableset_*, iac_providerregistry_*) в настоящее время Experimental в Harness — проверки доступа всегда разрешают, пока iac-server не активирует принудительное применение. RBAC реестра модулей (iac_registry_view / iac_registry_edit) является Active и принудительным. MCP всегда пересылает PAT/SAT вызывающего без изменений.

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Типичный рабочий процесс:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="..."), чтобы найти рабочую область.
2. harness_create / harness_update на iacm_workspace для создания с нуля или из шаблона (associated_template), или обновления существующей рабочей области — ответ содержит только { policy_evaluation }.
3. harness_get(resource_type="iacm_workspace", workspace_id="..."), чтобы получить созданную/обновленную рабочую область.
4. harness_list / harness_create / harness_update на iacm_variable_set (необязательно с resource_scope) для переиспользуемых наборов переменных Terraform/env — ответ — ресурс VariableSet.
5. harness_list / harness_create / harness_update на iacm_module для реестра модулей (name + system обязательны; добавьте resource_scope с org_id/project_id для модуля с областью org или project) — ответ — ресурс модуля.
6. harness_list / harness_create / harness_update на iacm_provider для реестра провайдеров account (body.type обязателен для создания; создание возвращает только { id } — затем harness_get; обновление создает/обновляет только версии) — обновление версии может вернуть пустой успех.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") для проверки ресурсов Terraform, выходных данных и источников данных.
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") для просмотра записей затрат по каждому выполнению.
9. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") для проверки диффов ресурсов до/после для plan, apply или destroy активности.

Ответы списков IaCM предоставляют page_count как количество для текущей страницы только (кроме iacm_variable_set, который не разбит на страницы). Когда has_more равно true, продолжайте запрашивать следующую страницу с 1-базовой нумерацией и суммируйте количество страниц, если вам нужен итог.

Внутренний портал разработчика (IDP)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
idp_entity	x	x
scorecard	x	x
scorecard_check	x	x
scorecard_stats		x
scorecard_check_stats		x
idp_score	x	x
idp_workflow	x					execute
idp_tech_doc	x

Запросы на вытягивание (Pull Requests)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
pull_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment	x		x
pr_check	x
pr_activity	x

Используйте harness_execute(resource_type="pull_request", action="close", ...) для явной операции закрытия. harness_update также принимает body.state (open или closed) и направляет изменения состояния в выделенную конечную точку состояния PR Harness Code; отправляйте правки заголовка/описания отдельным вызовом обновления.

Управление релизами

Ресурсы управления релизами (RMG) включены по умолчанию. Ресурсы определений (release_process, release_activity) поддерживают список/получение/создание/обновление/удаление с body.yaml; вызовите harness_schema(resource_type="release_process"|"release_activity") перед созданием/обновлением. Ресурсы выполнения отслеживают запущенные релизы — большинство операций списка требуют release_id (UUID из harness_list resource_type=release, или слаг URL интерфейса, такой как identifier-1.0.0-abc). Вставьте URL релиза RMG в harness_list, чтобы автоматически заполнить release_id.

Вызовы RMG используют ${HARNESS_BASE_URL}/gateway/rmg с областью account через заголовок Harness-Account. Область org/project использует область на основе заголовка, когда предоставлены org_id/project_id. release_execution_phase только для списка — используйте поле identifier каждого элемента фазы как params.phase_identifier при вызове harness_get на ресурсах ввода/вывода фазы (не вызывайте harness_get на самом release_execution_phase). Фильтрация списка релизов status применяется на стороне клиента только к текущей странице; продолжайте постраничный переход с теми же фильтрами, когда результаты могут охватывать несколько страниц.

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Типичный рабочий процесс:

1. harness_list(resource_type="release_process", org_id="...", project_id="...") для обнаружения определений процессов оркестрации.
2. harness_schema(resource_type="release_process") (или release_activity) перед созданием/обновлением; затем harness_create / harness_update с body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="...") для поиска активных или недавних релизов (по умолчанию период просмотра 30 дней; опционально filters.status, filters.search_term, filters.days_back).
4. harness_get(resource_type="release", release_id="...") для получения деталей релиза.
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) для статуса фазы; тот же release_id для release_execution_task и release_execution_activity.
6. harness_get на release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output или release_execution_activity_input с использованием release_id плюс params.phase_identifier / params.activity_identifier / activity_execution_id как описано для каждого ресурса.

Флаги функций

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Ресурсы FME (Split.io) — ресурсы fme_* поддерживают двухрежимную область действия: устаревшие вызовы передают workspace_id и обращаются к API Split.io (api.split.io); новые вызовы передают org_id+project_id вместе и обращаются к собственным конечным точкам Harness (стандартные HARNESS_API_KEY/HARNESS_BASE_URL, та же аутентификация, что и для любого другого ресурса harness_*). Передача как workspace_id, так и org_id/project_id в одном вызове или смешивание org_id с project_id отдельно является ошибкой — выберите один режим для каждого вызова. Каждая операция ниже доступна в устаревшем режиме без изменений. Собственный режим Harness в настоящее время охватывает меньше:

• fme_workspace — нет собственного эквивалента Harness; только устаревший (используется для обнаружения значений workspace_id).

• fme_environment — двухрежимный list (workspace_id или org_id+project_id). get/create/update/delete доступны только в собственном режиме Harness (/fme/api/v4/environments) — у MCP никогда не было контракта workspace_id для этих операций. Собственный список использует опциональные offset/limit (максимум 100; harness_list size сопоставляется с limit); конверт {data, limit, offset, totalCount} повышается до items/total. Собственные создание/обновление используют isProduction (production принимается как псевдоним). Собственное обновление — это JSON Merge Patch; name и isProduction не могут быть очищены. Максимальная длина имени — 15 символов.

• fme_feature_flag — двухрежимный, обе ветви полностью подключены. Собственный режим Harness (org_id+project_id): list/get/create/delete обращаются к /fme/api/v4/feature-flags (тело для create: name, trafficType, опционально description/tags/owners, согласно CreateFeatureFlagRequest); update отправляет merge-patch на /fme/api/v4/feature-flags/{name}; archive/unarchive обращаются к /fme/api/v4/feature-flags/{name}/archive|unarchive (только опциональный comment — без title, согласно ArchiveUnarchiveRequest); kill/restore/reallocate обращаются к /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate с environment_id в качестве параметра запроса (опционально comment/title, согласно FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update остаются двухрежимными (workspace_id или org_id+project_id). list/delete/kill/restore/reallocate доступны только в собственном режиме Harness (org_id+project_id) — у MCP никогда не было контракта workspace_id для этих операций. Собственный список требует feature_flag_name и использует offset/limit (по умолчанию 100, максимум 100); он не принимает environment_id. Удаление и выполнение требуют environment_id. Kill/restore/reallocate — те же действия, что и для fme_feature_flag. Тело get/create/update соответствует устаревшему (treatments, defaultTreatment, defaultRule, опционально rules/baselineTreatment/trafficAllocation/comment), плюс опциональный title в собственном режиме Harness. Собственное обновление — это JSON Merge Patch.

• fme_rollout_status — двухрежимный list. Передайте org_id+project_id (предпочтительно) или устаревший workspace_id. Собственная пагинация использует offset/limit (максимум 100; harness_list size сопоставляется с limit); результаты повышаются до items/total. Каждый элемент имеет id, name и опциональный description.

• fme_rule_based_segment — (Устарел — см. fme_segment.) Собственный режим Harness отклоняется для каждой операции (list/get/create/delete) — используйте fme_segment вместо этого; этот ресурс поддерживает только устаревший контракт workspace_id.

• fme_rule_based_segment_definition — (Устарел — см. fme_segment_definition.) Собственный режим Harness отклоняется для каждой операции/действия (list/update/enable/disable/change_request) — используйте fme_segment_definition вместо этого (без эквивалента enable/disable/change_request там); этот ресурс поддерживает только устаревший контракт workspace_id/environment_id.

• fme_traffic_type — двухрежимный list. Передайте org_id+project_id (предпочтительно) или устаревший workspace_id. Собственная пагинация использует offset/limit (максимум 100; harness_list size сопоставляется с limit); результаты повышаются до items/total. Каждый элемент имеет id и name (без displayAttributeId).

• fme_identity — create/update еще не реализованы, если org_id+project_id передаются вместе; в противном случае выполняется как обычный устаревший вызов.

• fme_standard_segment — (Устарел — см. fme_segment.) Собственный режим Harness отклоняется для каждой операции (list/get) — используйте fme_segment вместо этого; этот ресурс поддерживает только устаревший контракт workspace_id. Операция create отсутствует для этого ресурса в обоих режимах.

• fme_segment_keys — list/update еще не реализованы, если org_id+project_id передаются вместе; в противном случае выполняется как обычный устаревший вызов.

• fme_segment — list/get/create/delete подключены к реальной конечной точке /fme/api/v4/segments (объединяет fme_standard_segment/fme_rule_based_segment); тело create: name, trafficType, type (обязательно — одно из standard/rule_based/large), опционально description/tags/owners.

• fme_segment_definition — только собственный режим Harness (без поддержки устаревшего workspace_id). list/get/create/update/delete подключены к /fme/api/v4/segment-definitions, согласно PR #12644 Harness_Split/Main (открыт, еще не объединен на момент написания — пути могут измениться). update использует JSON Merge Patch на description, единственном изменяемом поле. Действия enable/disable/change_request отсутствуют — у бэкенда нет таких конечных точек для этого унифицированного ресурса.

В однопользовательском/самостоятельно размещенном режиме аутентификация в устаревшем режиме использует Bearer-токен из HARNESS_FME_API_KEY, с возвратом к не-заполнителю HARNESS_API_KEY. HARNESS_FME_API_KEY может быть устаревшим ключом администратора Split или PAT/SAT Harness с правом FME, но он отклоняется в режиме multi-user, чтобы общие развертывания не могли переопределить учетные данные пользователя каждой сессии. Учетные данные размещенного OAuth/сервисной маршрутизации для API платформы Harness не аутентифицируют прямые запросы Split.io. fme_feature_flag поддерживает полное управление жизненным циклом в устаревшем режиме: создание (требует traffic_type_id), список, получение, обновление метаданных, удаление и действия kill/restore/reallocate/archive/unarchive. Используйте fme_traffic_type для обнаружения ID типов трафика, fme_identity для создания/обновления атрибутов идентичности и fme_standard_segment / fme_segment_keys для просмотра стандартных сегментов и добавления ключей участников. fme_rule_based_segment предоставляет CRUD для целевых сегментов, а fme_rule_based_segment_definition управляет правилами сегментов для конкретной среды с включением/отключением и процессами утверждения запросов на изменение.

GitOps

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Chaos Engineering

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Cloud Cost Management (CCM)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Software Engineering Insights (SEI)

Ресурсы SEI объединены для эффективности токенов. Используйте параметры metric или aspect для DORA, деталей команды/организационного дерева и AI-аналитики.

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				Передайте metric: deployment_frequency, change_failure_rate, mttr, lead_time или *_drilldown
sei_team	x	x
sei_team_detail	x					Передайте aspect: integrations, developers, integration_filters
sei_org_tree	x	x
sei_org_tree_detail	x	x				Передайте aspect: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
sei_business_alignment	x	x				Передайте aspect: feature_metrics, feature_summary, drilldown для get
sei_ai_usage	x	x				Передайте aspect: metrics, breakdown, summary, top_languages
sei_ai_adoption	x	x				Передайте aspect: metrics, breakdown, summary
sei_ai_impact		x				Передайте aspect: pr_velocity, rework
sei_ai_raw_metric	x

Обеспечение безопасности цепочки поставок ПО (SCS)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Хранилище свидетельств (Evidence Vault)

Хранилище свидетельств хранит атестации in-toto (свидетельства SDLC). Список поддерживает область действия account/org/project через resource_scope. Одиночные фильтры свободного текста (pipeline, artifact отдельно, gitoid) используют search_term; дополнительное ограничение по имени использует filters.subject_name; дайджест содержимого субъекта использует filters.subject_digest. Получение выполняется по gitoid_sha256 и требует org_id/project_id (из строки списка). Загрузка (действие harness_execute download) возвращает ограниченную по времени download_url — всегда показывайте эту ссылку пользователю. Требуется флаг функции SCS_EVIDENCE_VAULT.

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
attestation	x	x				download

Оркестрация тестирования безопасности (STO)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

Создание security_exemption — это операция high_write. Сервер извлекает requester_id из аутентифицированного PAT, устанавливает exemptFutureOccurrences=true и по умолчанию задает duration_days равным 30, если оно не указано. Для перечисления исключений передавайте небольшой явный размер страницы (например, filters: { "status": "Pending", "size": 5 }) и следуйте _nextPageHint, возвращаемому в каждом ответе.

Рабочий процесс выполнения исключения безопасности:

• Используйте harness_list с resource_type="security_exemption" и явным status, таким как Pending, Approved, Rejected, Expired или Canceled.
• Используйте harness_execute с action="approve" и обязательным body.scope: CURRENT, ACCOUNT, ORG или PROJECT. CURRENT одобряет в существующей области исключения; другие области используют внутреннюю конечную точку продвижения STO. Сервер автоматически заполняет body.approver_id из аутентифицированного пользователя, если оно опущено; body.comment необязательно.
• Используйте action="reject" для отклонения исключения. body.approver_id также автоматически заполняется, если опущено.
• Нет отдельного действия выполнения promote. Используйте action="approve" с не-CURRENT body.scope, когда запрошенный результат — одобрение на уровне account, organization или project.

Управление доступом

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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

Управление (Governance)

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

Заморозка развертывания

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Переопределения сервисов

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
service_override	x	x	x	x	x

Настройки

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
setting	x

MCP-подсказки

DevOps

Prompt	Описание	Параметры
build-deploy-app	Сквозной CI/CD-процесс: сканирование git-репозитория, генерация CI-пайплайна (сборка и публикация Docker-образа), обнаружение или генерация K8s-манифестов, создание CD-пайплайна и развертывание — с автоматическими повторами при сбоях CI (до 5 попыток) и CD (до 3 попыток с разрешения пользователя). При исчерпании повторов предоставляет глубокие ссылки Harness UI на все созданные ресурсы для ручного расследования.	repoUrl (обязательный), imageName (обязательный), projectId (необязательный), namespace (необязательный)
debug-pipeline-failure	Анализ неудачного выполнения: принимает ID выполнения, ID пайплайна или URL Harness. Получает разбивку по этапам/шагам, детали сбоя, информацию о делегате и логи неудачных шагов через harness_diagnose, затем предоставляет анализ первопричины и предлагаемые исправления. Автоматически отслеживает цепочки сбоев пайплайнов.	executionId (необязательный), projectId (необязательный)
pipeline_summarizer	Получение и сводка ВСЕХ логов шагов из выполнения пайплайна. Использует harness_diagnose с include_logs: true, include_all_step_logs: true для получения логов каждого шага, затем представляет таблицу с именем шага, статусом, длительностью и сводкой произошедшего (на основе логов). Не пропускает ни одного шага.	executionId (необязательный), projectId (необязательный)
create-pipeline	Генерация нового YAML-файла пайплайна из требований на естественном языке, с просмотром существующих ресурсов для контекста	description (обязательный), projectId (необязательный)
create-agent	Интерактивное создание AI-агента Harness — проверка существующих агентов, сбор требований, генерация YAML-спецификации агента с использованием схемы agent-pipeline, подтверждение с пользователем, затем создание или обновление через harness_create/harness_update	agent_name (обязательный), task_description (обязательный), org_id (необязательный), project_id (необязательный)
onboard-service	Пошаговое подключение нового сервиса с окружениями и пайплайном развертывания	serviceName (обязательный), projectId (необязательный)
dora-metrics-review	Обзор метрик DORA (частота развертываний, процент сбоев изменений, MTTR, время выполнения) с классификацией Elite/High/Medium/Low и рекомендациями по улучшению	teamRefId (необязательный), dateStart (необязательный), dateEnd (необязательный)
setup-gitops-application	Руководство по подключению GitOps-приложения — проверка агента, кластера, репозитория и создание приложения	agentId (обязательный), projectId (необязательный)
chaos-resilience-test	Проектирование хаос-эксперимента для проверки устойчивости сервиса с внедрением сбоев, пробами и ожидаемыми результатами	serviceName (обязательный), projectId (необязательный)
feature-flag-rollout	Планирование и выполнение постепенного развертывания функционального флага в окружениях с защитными шлюзами	flagIdentifier (обязательный), projectId (необязательный)
migrate-pipeline-to-template	Анализ существующего пайплайна и извлечение переиспользуемых шаблонов этапов/шагов из него	pipelineId (обязательный), projectId (необязательный)
delegate-health-check	Проверка подключения делегата, работоспособности, статуса токена и устранение проблем инфраструктуры	projectId (необязательный)
developer-portal-scorecard	Обзор карточек IDP для сервисов и выявление пробелов для улучшения опыта разработчиков	projectId (необязательный)
pending-approvals	Поиск выполнений пайплайнов, ожидающих утверждения, показ деталей и предложение утвердить или отклонить	projectId (необязательный), orgId (необязательный), pipelineId (необязательный)

FinOps

Prompt	Описание	Параметры
optimize-costs	Анализ данных о затратах на облако, выявление рекомендаций и аномалий, приоритизированных по потенциальной экономии	projectId (необязательный)
cloud-cost-breakdown	Глубокий анализ затрат на облако по сервису, окружению или кластеру с анализом трендов и обнаружением аномалий	perspectiveId (необязательный), projectId (необязательный)
commitment-utilization-review	Анализ использования зарезервированных экземпляров и планов сбережений для выявления потерь и оптимизации обязательств	projectId (необязательный)
cost-anomaly-investigation	Расследование аномалий затрат — определение первопричины, затронутых ресурсов и мер по устранению	projectId (необязательный)
rightsizing-recommendations	Обзор и приоритизация рекомендаций по изменению размеров, при необходимости создание тикетов Jira или ServiceNow	projectId (необязательный), minSavings (необязательный)

DevSecOps

Prompt	Описание	Параметры
security-review	Обзор проблем безопасности в ресурсах Harness и предложение мер по устранению по степени серьезности	projectId (необязательный), severity (необязательный, по умолчанию: critical,high)
vulnerability-triage	Триаж уязвимостей безопасности в пайплайнах и артефактах, приоритизация по серьезности и эксплуатируемости	projectId (необязательный), severity (необязательный)
sbom-compliance-check	Аудит SBOM и соответствия требованиям для артефактов — риски лицензий, нарушения политик, уязвимости компонентов	artifactId (необязательный), projectId (необязательный)
supply-chain-audit	Сквозной аудит безопасности цепочки поставок ПО — происхождение, цепочка хранения, соответствие политикам	projectId (необязательный)
security-exemption-review	Обзор ожидающих исключений безопасности и принятие решений о массовом утверждении или отклонении	projectId (необязательный)
bulk-exemption-create	Создание обоснованных исключений безопасности для нескольких проблем STO с явными указаниями по объему и длительности	projectId (обязательный), exemption_type (обязательный), reason (обязательный), фильтры проблем (необязательный)
access-control-audit	Аудит разрешений пользователей, учетных записей с избыточными привилегиями и назначений ролей для обеспечения минимальных привилегий	projectId (необязательный), orgId (необязательный)

Harness Code

Prompt	Description	Parameters
code-review	Проверить pull request — проанализировать diff, коммиты, проверки и комментарии, чтобы предоставить структурированную обратную связь по ошибкам, безопасности, производительности и стилю	repoId (обязательный), prNumber (обязательный), projectId (необязательный)
pr-summary	Автоматически сгенерировать заголовок и описание PR из истории коммитов и diff ветки	repoId (обязательный), sourceBranch (обязательный), targetBranch (необязательный, по умолчанию: main), projectId (необязательный)
branch-cleanup	Проанализировать ветки в репозитории и рекомендовать устаревшие или объединенные ветки для удаления	repoId (обязательный), projectId (необязательный)

Ресурсы MCP

URI ресурса	Описание	Тип MIME
pipeline:///{pipelineId}	Определение YAML пайплайна	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	YAML пайплайна (с явной областью действия)	application/x-yaml
executions:///recent	Последние 10 сводок выполнения пайплайна	application/json
schema:///pipeline	JSON-схема пайплайна Harness	application/schema+json
schema:///template	JSON-схема шаблона Harness	application/schema+json
schema:///trigger	JSON-схема триггера Harness	application/schema+json
schema:///pipeline_v1 (Alpha)	JSON-схема пайплайна Harness V1 (упрощенный формат этапов/шагов)	application/schema+json
schema:///agent-pipeline	JSON-схема пайплайна AI-агента Harness	application/schema+json

Фильтрация наборов инструментов

По умолчанию включены 40 из 41 наборов инструментов. Один набор инструментов является опциональным и исключен из стандартных:

• ansible — Harness Ansible (инвентаризации, плейбуки, хосты, активность). Опциональный, поскольку ограничен областью проекта и добавляет концепции, которые многим пользователям не нужны.

Добавление наборов инструментов с префиксом +

Используйте префикс +, чтобы явно включить опциональные наборы инструментов вместе со всеми стандартными:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Удаление стандартных наборов инструментов

Используйте префикс -, чтобы исключить ненужные наборы инструментов:

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

Комбинирование + и -

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

Явный список разрешенных

Явный список, разделенный запятыми (без префиксов), полностью заменяет стандартные наборы. Включаются только перечисленные наборы инструментов:

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

Доступные имена наборов инструментов:

Набор инструментов	Типы ресурсов
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 (по желанию)	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

Архитектура

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

Как это работает

1. Инструменты — это обобщённые глаголы: harness_list, harness_get и т.д. Они принимают параметр resource_type, который направляет запрос к соответствующему API-эндпоинту.
2. Реестр сопоставляет каждый resource_type с ResourceDefinition — декларативной структурой данных, определяющей HTTP-метод, путь URL, сопоставления path/query-параметров и логику извлечения ответа.
3. Диспетчеризация разрешает определение ресурса, формирует HTTP-запрос (подстановка пути, query-параметры, внедрение account/org/project с учётом resource_scope), вызывает Harness API через HarnessClient и извлекает релевантные данные ответа.
4. Фильтрация наборов инструментов (HARNESS_TOOLSETS) управляет тем, какие определения ресурсов загружаются в реестр при запуске.
5. Структурированный вывод объявляется с помощью MCP outputSchema; harness_list преобразует массивы и распространённые обёртки списков в объектные structuredContent для строгих клиентов.
6. Глубокие ссылки автоматически добавляются к ответам, предоставляя прямые URL-адреса Harness UI для каждого ресурса.
7. Компактный режим удаляет подробные метаданные из результатов списков, оставляя только полезные поля (идентичность, статус, тип, временные метки, глубокие ссылки), чтобы минимизировать использование токенов.

Добавление нового типа ресурса

Создайте новый файл в src/registry/toolsets/ или добавьте ресурс в существующий набор инструментов:

// 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",
        },
      },
    },
  ],
};

Затем импортируйте его в src/registry/index.ts и добавьте в массив ALL_TOOLSETS. Никаких изменений в файлах инструментов не требуется.

Разработка

# 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

Структура проекта

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

Элиситация

Инструменты записи (harness_create, harness_update, harness_delete, harness_execute) используют элиситацию MCP для запроса подтверждения у пользователя, когда риск действия этого требует — только операции medium_write, high_write и destructive. Низкорисковые операции создания / обновления / чтения (например, pipeline.create, pipeline.update, hql_query.run) выполняются беззвучно, без запроса. Когда запрос отображается, пользователь видит, что должно произойти, и принимает или отклоняет действие, обеспечивая реальное подтверждение человеком для операций, которые действительно изменяют или запускают что-либо.

Как это работает:

1. LLM вызывает инструмент записи с риском medium_write+ (например, harness_delete, harness_execute pipeline.run). Низкорисковые операции создания / обновления / чтения не отображают запрос.
2. Сервер отправляет клиенту запрос элиситации с описанием операции и флажком confirm (по умолчанию установлен).
3. Пользователь видит детали и нажимает Принять (с установленным confirm) или Отклонить / Отменить.
4. Если принято с confirm: true, операция выполняется. Если принято с снятым confirm, отклонено или отменено, операция блокируется, и LLM уведомляется (явный отказ авторитетен и не обходится параметром confirm: true в вызове инструмента).

Поддержка клиентов:

Клиент	Поддержка элиситации
Cursor	Да
VS Code (Copilot)	Да
Claude Desktop	Пока нет
Devin Desktop	Пока нет
MCP Inspector	Да

Поведение элиситации зависит от риска операции, когда поддержка клиента отсутствует:

Уровень риска	Клиент поддерживает элиситацию	Передан confirm: true	Поведение
read, low_write	любое	любой	Выполняется беззвучно — запрос не отображается (confirm не влияет на этом уровне риска)
medium_write, high_write, destructive	Да	любой	Запрос пользователю. Выполняется только если пользователь принимает с confirm: true (значение по умолчанию в схеме). Явный отказ, отмена или принятие с confirm: false (пользователь снял флажок) авторитетны и не обходятся параметром confirm: true в вызове инструмента. Принятие без поля confirm рассматривается как сбой клиента при отображении полезного запроса — можно повторить с confirm: true
medium_write, high_write, destructive	Нет	Нет	БЛОКИРОВКА (возврат ошибки с подсказкой повторить с confirm: true)
medium_write, high_write, destructive	Нет	Да	Выполняется (явное согласие для неинтерактивной автоматизации)
любой (на уровне HARNESS_AUTO_APPROVE_RISK или ниже)	любое	любой	Автоматическое одобрение без запроса

Если elicitInput завершается ошибкой во время выполнения (ошибка транспорта, неподдерживаемый метод) для операции уровня medium_write+, вызов блокируется, если вызывающий не передаёт confirm: true. confirm: true учитывается как запасной вариант, когда клиент не смог отобразить запрос или вернул вырожденное принятие ({action: "accept"} без поля подтверждения), но он не отменяет явный отказ/отмену от клиента, завершившего рукопожатие элиситации.

Автономный режим

Автономный режим означает, что сервер выполняет все операции — включая записи и разрушительные действия — без запроса подтверждения. Включите его, установив:

HARNESS_AUTO_APPROVE_RISK=all

Это потолок на уровне развёртывания: после установки отдельные сессии не могут превысить его (хотя могут выбрать более строгий порог для конкретной сессии через заголовок x-harness-auto-approve-risk).

Или в конфигурации вашего MCP-клиента:

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

Частичная автономия: Вы также можете автоматически одобрять только до определённого уровня риска, продолжая запрашивать подтверждение для операций с более высоким риском:

# 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

Значение	Что автоматически одобряется
none (по умолчанию)	Ничего — порог автоматического одобрения отсутствует
low_write	Чтения + низкорисковые записи
medium_write	Чтения + низко- и среднерисковые записи
high_write	Чтения + низко-, средне- и высокорисковые записи
all	Всё, включая разрушительные операции

Предупреждение об автономном режиме: HARNESS_AUTO_APPROVE_RISK=all пропускает подтверждение для всех операций, включая harness_delete. Используйте с осторожностью и рассмотрите сочетание с HARNESS_TOOLSETS, чтобы ограничить доступные типы ресурсов.

Примечание о миграции: HARNESS_SKIP_ELICITATION=true по-прежнему поддерживается и сопоставляется с HARNESS_AUTO_APPROVE_RISK=all. Предупреждение об устаревании записывается в stderr. Если заданы оба параметра, приоритет имеет HARNESS_AUTO_APPROVE_RISK.

Безопасность

• Секреты никогда не раскрываются. Тип ресурса secret возвращает только метаданные (имя, тип, область действия) — значения секретов никогда не включаются ни в один ответ.
• Операции, требующие подтверждения, используют элиситацию, когда это доступно. Когда действие записи или выполнения имеет риск medium_write, high_write или destructive, harness_create, harness_update, harness_delete и harness_execute пытаются выполнить элиситацию MCP перед продолжением (см. Элиситация). Низкорисковые действия (read, low_write — например, pipeline.create, pipeline.update, hql_query.run) выполняются беззвучно, без запроса.
• Средний риск и выше завершаются с блокировкой. Если подтверждение не может быть получено для операций medium_write, high_write или destructive, они блокируются вместо слепого выполнения. Переопределите с помощью HARNESS_AUTO_APPROVE_RISK для автономных рабочих процессов.
• CORS ограничен тем же источником. HTTP-транспорт разрешает только запросы с того же источника, предотвращая CSRF-атаки со стороны вредоносных веб-сайтов, нацеленных на MCP-сервер на localhost.
• Ограничение скорости HTTP. HTTP-транспорт обеспечивает 60 запросов в минуту на IP-адрес для предотвращения флуда запросами.
• Ограничение скорости API. Клиент Harness API обеспечивает лимит 10 запросов в секунду, чтобы избежать превышения лимитов вышестоящего API.
• Ограничения пагинации. Запросы списков ограничены 10 000 элементов всего и 100 на страницу для предотвращения исчерпания памяти.
• Повторные попытки с экспоненциальной задержкой. Временные сбои (HTTP 429, 5xx) повторяются с экспоненциальной задержкой и джиттером.
• Привязка к localhost. HTTP-транспорт по умолчанию привязывается к 127.0.0.1 — недоступен из сети.
• Без логирования в stdout. Все журналы записываются в stderr, чтобы не повредить stdio JSON-RPC транспорт.

Дополнительные навыки

MCP-сервер Harness хорошо сочетается с Harness Skills — коллекцией готовых навыков Claude Code (слэш-команд), предназначенных для распространённых рабочих процессов Harness. Установите их вместе с этим MCP-сервером, чтобы получить высокоуровневую автоматизацию, такую как /deploy, /rollback, /triage и другие, без написания пользовательских промптов.

Устранение неполадок и распространённые ошибки

Симптом	Вероятная причина	Что делать
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	Ключ API не в поддерживаемом формате с областью аккаунта (pat.<accountId>... или sat.<accountId>...), поэтому идентификатор аккаунта не может быть выведен	Установите HARNESS_ACCOUNT_ID явно
Unknown transport: "..." при запуске	Неподдерживаемый аргумент транспорта CLI	Используйте только stdio или http
Invalid HARNESS_TOOLSETS: ... при запуске	Одно или несколько имен наборов инструментов не распознаны	Используйте только имена из Фильтрация наборов инструментов (точное совпадение)
HTTP mcp-session-id header is required...	Запрос сессии был отправлен без заголовка сессии	Сначала отправьте initialize, затем включите mcp-session-id в POST/GET/DELETE /mcp
HTTP Session not found...	Сессия истекла после MCP_SESSION_TTL_MS миллисекунд простоя или уже закрыта	Повторно запустите initialize для создания новой сессии, затем повторите с новым заголовком
HTTP 405 Method Not Allowed на /mcp	Неподдерживаемый метод для конечной точки MCP	Используйте только POST, GET, DELETE или OPTIONS
HTTP Invalid request	Недопустимое тело JSON или тело запроса превысило HARNESS_MAX_BODY_SIZE_MB	Проверьте размер/форму полезной нагрузки JSON; увеличьте HARNESS_MAX_BODY_SIZE_MB при необходимости
Unknown resource_type "..." от инструментов	Тип ресурса написан с ошибкой или отфильтрован через HARNESS_TOOLSETS	Вызовите harness_describe (с необязательным search_term) для обнаружения допустимых типов
Missing required field "... for path parameter ..."	Вызов с областью проекта/организации не содержит идентификаторы	Установите HARNESS_ORG/HARNESS_PROJECT или передайте org_id/project_id при каждом вызове инструмента
resource_scope "org" requires org_id... или resource_scope "project" requires project_id...	Ресурс с несколькими областями был принудительно ограничен областью организации/проекта без достаточных идентификаторов	Передайте недостающие org_id/project_id, настройте HARNESS_ORG/HARNESS_PROJECT или используйте resource_scope: "account" при поддержке
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true блокирует создание/обновление/удаление/выполнение	Установите HARNESS_READ_ONLY=false, если предполагаются операции записи
Запуск конвейера не проходит предварительную проверку из-за неразрешенных обязательных входных данных	Предоставленный inputs не покрыл обязательные плейсхолдеры времени выполнения	Получите runtime_input_template, укажите недостающие простые ключи или используйте input_set_ids для структурных входных данных
Сокращение CI конвейера (branch, tag, pr_number, commit_sha) не применилось	inputs.build уже был предоставлен, поэтому расширение сокращения было намеренно пропущено	Удалите inputs.build для использования расширения сокращения или сохраните полную явную структуру build
Запуск конвейера загрузил неправильную ревизию YAML	Определение конвейера хранится в Git, и запуск не указал желаемую ветку конвейера	Передайте params.pipeline_branch в действии run; это соответствует Harness pipelineBranchName
wait: true вернул _wait.error	Триггер конвейера выполнен успешно, но опрос на стороне сервера не удался	Повторно проверьте execution_id с помощью harness_get(resource_type="execution", ...) перед решением о повторном запуске
wait: true вернул execution_timed_out: true	Выполнение не достигло конечного статуса до wait_timeout_seconds	Используйте возвращенный execution_id для повторной проверки статуса; дождитесь конечного статуса перед запуском harness_diagnose
Журналы выполнения пусты или загрузка блобов возвращает 403	URL-адреса блобов журналов, размещенных в Harness, требуют настроенного пути клиента/аутентификации Harness, особенно для внутренних или самостоятельно управляемых хостов	Держите HARNESS_BASE_URL направленным на целевой хост Harness и используйте harness_get(resource_type="execution_log", ...) или harness_diagnose(..., include_logs=true) вместо обхода MCP-клиента
Operation declined by user / Operation cancelled by user	Пользователь отклонил или отменил диалог подтверждения запроса — авторитетно	Проверьте детали операции с пользователем; confirm: true не обходит явный отказ. Пользователь должен принять запрос
Operation blocked: the client could not surface a usable confirmation prompt	Клиент не поддерживает запрос, elicitInput не удался или вернул вырожденное принятие	Повторите с confirm: true для неинтерактивной автоматизации или используйте клиент, поддерживающий запрос
body.template_yaml (or body.yaml) is required для создания/обновления шаблона	API шаблонов ожидают полную полезную нагрузку YAML	Предоставьте полную строку template_yaml в body; для удаления передайте version_label для удаления одной версии (опустите для удаления всех версий)
HARNESS_BASE_URL must use HTTPS при запуске	HARNESS_BASE_URL установлен на HTTP URL	Используйте HTTPS или установите HARNESS_ALLOW_HTTP=true для локальной разработки

Лицензия

MIT