Harness

Harness MCP Server 2.0

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

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

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

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

• 11 инструментов, 255 типов ресурсов. Система диспетчеризации на основе реестра направляет harness_list, harness_get, harness_create и т.д. к любому ресурсу Harness — конвейерам, сервисам, окружениям, организациям, проектам, флагам функций, данным о затратах и многому другому. LLM выбирает из 11 инструментов вместо сотен.
• Полное покрытие платформы. 41 набор инструментов по умолчанию, охватывающий 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

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

Манифест пакета 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 (запросы инициализации + сеанса)
/mcp	GET	Поток SSE для сообщений, инициируемых сервером (прогресс, запросы)
/mcp	DELETE	Завершение активного MCP-сеанса
/mcp	OPTIONS	Предварительная проверка CORS
/health	GET	Проверка работоспособности — возвращает { "status": "ok", "sessions": <count> }
/.well-known/oauth-protected-resource	GET	Метаданные RFC 9728, когда HARNESS_MCP_MODE=oauth
/.well-known/oauth-protected-resource/mcp	GET	Метаданные RFC 9728 с учетом пути для ресурса по умолчанию /mcp

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

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

• Установите HARNESS_MCP_AUTH_TOKEN для общих или удаленно доступных однопользовательских и многопользовательских развертываний. При установке каждый запрос POST, GET и DELETE к /mcp должен включать Authorization: Bearer <token>.
• Режим OAuth принимает токены доступа HarnessID вместо HARNESS_MCP_AUTH_TOKEN и может привязываться к адресу, отличному от loopback, без отказа от неаутентифицированного доступа.
• Привязки к адресам, отличным от 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, поэтому сеанс может уменьшить, но не расширить настроенный предел утверждения.

Режим OAuth HarnessID

Установите HARNESS_MCP_MODE=oauth, чтобы удаленные MCP-клиенты могли обнаруживать HarnessID и выполнять OAuth 2.1 Authorization Code с PKCE. Режим OAuth доступен только с HTTP-транспортом. Встроены производственные значения по умолчанию для HarnessID, ресурса MCP и маршрутизации API:

HARNESS_MCP_MODE=oauth

По умолчанию используется издатель https://id.harness.io/idp/realms/HarnessIDP, ресурс https://mcp.harness.io/mcp, OAuth-клиент mcp-client и база API Harness https://mcp.harness.io/cli. Переопределяйте их только для QA, локальной разработки или другой среды Harness.

HARNESS_API_KEY не должен быть установлен в этом режиме. HARNESS_MCP_OAUTH_JWKS_URI по умолчанию — <issuer>/protocol/openid-connect/certs, а HARNESS_ACCOUNT_ID не нужен, поскольку учетная запись берется из токена.

Сервер публикует метаданные защищенного ресурса RFC 9728 и возвращает этот запрос, когда клиент не прошел аутентификацию:

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

Он проверяет подпись RS256 токена доступа HarnessID, iss, срок действия и sub с использованием настроенной конечной точки JWKS, а также проверяет, что токен был выдан HARNESS_MCP_OAUTH_CLIENT_ID через утверждение azp. HARNESS_MCP_OAUTH_RESOURCE — это идентификатор защищенного ресурса RFC 9728, используемый для обнаружения и запросов. Текущие токены доступа HarnessID используют aud: account, а не URL MCP, поэтому ресурс не сравнивается с aud.

Идентификатор учетной записи берется из утверждения HARNESS_MCP_OAUTH_ACCOUNT_CLAIM токена (по умолчанию account_id), которое заполняется областью organization HarnessID. Каждый сеанс хранит токен доступа вызывающего абонента и пересылает его в API Harness как Authorization: Bearer, поэтому RBAC Harness и записи аудита отражают вошедшего пользователя, а не общий PAT. Сеанс привязан к sub и учетной записи, с которыми он был создан: последующий запрос может содержать обновленный токен, но токен для другого пользователя или учетной записи отклоняется.

Клиентам обычно нужен только URL ресурса MCP:

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

Клиент читает метаданные защищенного ресурса, обнаруживает HARNESS_MCP_OAUTH_ISSUER, а затем использует метаданные RFC 8414 этого сервера авторизации. Если клиент не поддерживает динамическую регистрацию клиентов, используйте предварительно зарегистрированный идентификатор клиента mcp-client.

См. OAuth HarnessID для самостоятельно размещенного MCP-сервера для контрольного списка QA Keycloak и команд проверки.

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

Установите 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 Platform. Она не использует HARNESS_API_KEY в конфигурации клиента. Доступность размещенного MCP настраивается для каждой учетной записи Harness, поэтому вам потребуется работать с Harness Support, чтобы включить/настроить эту опцию перед использованием.

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

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

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

Пример с записями как размещенного, так и локального MCP:

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

Графические приложения (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

MCP-сервер Harness полностью совместим с 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

Добавьте MCP-сервер Harness в ваш 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, чтобы предоставить MCP-сервер Harness через вашу существующую инфраструктуру шлюза 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 с ключами API для каждой сессии) или oauth (HTTP с проверкой access-токена HarnessID)
HARNESS_API_KEY	Да*	--	Персональный access-токен Harness или токен сервисного аккаунта. Обязателен в режиме single-user. НЕ должен быть задан в режимах multi-user или oauth, где каждая сессия приносит собственные учетные данные
HARNESS_ACCOUNT_ID	Нет	(из PAT/SAT)	Идентификатор аккаунта Harness. Автоматически извлекается из токенов PAT/SAT в однопользовательском режиме; многопользовательские сессии могут предоставить свой через x-harness-account-id, когда ключ API не содержит его встроенным
HARNESS_BASE_URL	Нет	https://app.harness.io (https://mcp.harness.io/cli в режиме OAuth)	Базовый URL API/UI Harness. Режим OAuth по умолчанию маршрутизируется через размещенный MCP /cli прокси; другие режимы используют SaaS API Harness напрямую
HARNESS_MCP_OAUTH_ISSUER	Нет	https://id.harness.io/idp/realms/HarnessIDP	Издатель HarnessID, сопоставляемый точно с утверждением iss access-токена
HARNESS_MCP_OAUTH_RESOURCE	Нет	https://mcp.harness.io/mcp	Публичный канонический URL MCP, публикуемый как идентификатор ресурса RFC 9728
HARNESS_MCP_OAUTH_JWKS_URI	Нет	<issuer>/protocol/openid-connect/certs	Конечная точка JWKS HarnessID, используемая для проверки подписей RS256 access-токенов
HARNESS_MCP_OAUTH_CLIENT_ID	Нет	mcp-client	Клиент HarnessID, для которого должен быть выпущен access-токен, проверяется по утверждению azp токена
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	Нет	account_id	Утверждение access-токена, содержащее идентификатор аккаунта Harness, заполняется областью organization HarnessID
HARNESS_MCP_OAUTH_SCOPES	Нет	openid profile email organization	Области, разделенные пробелами, объявляемые в метаданных защищенного ресурса RFC 9728
HARNESS_FME_API_KEY	Нет	--	Необязательные учетные данные администратора FME/Split для однопользовательского/самостоятельно размещенного режима, используемые для ресурсов fme_ только в устаревшем (workspace_id) режиме. Устаревший FME недоступен в режиме OAuth, поэтому токены HarnessID никогда не отправляются в api.split.io; вместо этого используйте собственную область org_id+project_id Harness. Не должен быть задан в режимах multi-user или oauth
HARNESS_FME_BASE_URL	Нет	https://api.split.io	Базовый URL Admin API Split/FME, используемый ресурсами fme_ только в устаревшем (workspace_id) режиме. HTTP URL требуют HARNESS_ALLOW_HTTP=true для локальной разработки. Собственный режим Harness (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 при установке. Требуется по умолчанию для не-loopback однопользовательских и многопользовательских привязок. Должен быть снят в режиме oauth
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	Максимальное время удержания событий аудита перед сбросом через webhook
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	Полностью отключает семантический поиск; выполняется откат к keyword 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, что и производственный поисковый сервис. Она использует простой bag-of-chars эмбеддинг, поэтому загрузка модели не требуется — результаты семантически правдоподобны, но не производственного качества.

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

HARNESS_BASE_URL должен использовать HTTPS по умолчанию. Если вы укажете URL без HTTPS (например, 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; настройте файловые или webhook-приемники для долговременного сбора аудита:

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

Каждое событие включает имя инструмента, тип ресурса, операцию, идентификаторы, временную метку, риск, результат, HTTP-метод/путь, длительность и метод подтверждения, когда применимо. Приемники аудита — это телеметрия best-effort; проблемы доставки логируются и никогда не воспроизводятся и не изменяют базовую операцию 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 как branch). Этот явный селектор определения имеет приоритет над псевдонимом params.branch. inputs.branch независимо выбирает ветку CI codebase:

  {
    "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. Используйте каждый возвращённый inputs[].details.name как ключ верхнего уровня в harness_execute.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).

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

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

{
  "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 отклоняет запуск как не включенный, проверьте как настройку «Разрешить динамическое выполнение» на уровне аккаунта, так и переключатель на уровне конвейера в разделе Конвейер -> Дополнительные параметры -> Настройки динамического выполнения.

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

Используйте 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,5 раза и ограничивается 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"
}

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

255 типов ресурсов, организованных в 41 набор инструментов. Каждый тип ресурса поддерживает подмножество операций 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	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	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 блоба.

Список file_content возвращает каждый путь в ref; get возвращает содержимое файла или каталога (опустите или передайте пустой path для корня репозитория; вложенные пути сохраняют слэши). Опустите git_ref, чтобы использовать ветку репозитория по умолчанию — не угадывайте main.

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

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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 через универсальные инструменты. Он поддерживает область действия аккаунта, организации и проекта; передайте 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/api/templates...). Создание и обновление требуют полной строки YAML шаблона в body.template_yaml или body.yaml; version_label нацелен на конкретную версию для обновления/удаления, тогда как удаление без version_label удаляет все версии.

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

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

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 для повторно используемых наборов переменных на уровне аккаунта, организации или проекта. Реестр провайдеров ограничен областью аккаунта.

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

RBAC для набора переменных и реестра провайдеров (iac_variableset_*, iac_providerregistry_*) в настоящее время экспериментальны в Harness — проверки доступа всегда разрешают, пока iac-server не активирует принудительное применение. RBAC реестра модулей (iac_registry_view / iac_registry_edit) активен и может применяться. 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 для модуля с областью организации или проекта) — ответ — ресурс модуля.
6. harness_list / harness_create / harness_update на iacm_provider для реестра провайдеров аккаунта (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="...") для проверки различий ресурсов до/после для плана, применения или уничтожения активности.

Ответы списков IaCM предоставляют page_count как количество для текущей страницы только (кроме iacm_variable_set, который не разбит на страницы). Когда has_more истинно, продолжайте запрашивать следующую страницу с 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_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment			x	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; отправляйте правки заголовка/описания отдельным вызовом обновления.

Используйте harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) для чтения комментариев PR. Используйте pr_comment для операций записи комментариев.

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

Ресурсы управления релизами (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 с областью аккаунта через заголовок Harness-Account. Область организации/проекта использует область на основе заголовков, когда предоставлены 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, как описано для каждого ресурса.

Vibe

Набор инструментов vibe, включенный по умолчанию, покрывает контракт Vibe Orchestrator BFF в рамках ${HARNESS_BASE_URL}/vibe/v1. Он использует существующее подключение Harness и заголовок учетной записи, без добавления параметров запроса account/org/project или полей области видимости в тела запросов. Команда проверила поток Vibe с использованием аутентификации Harness API-key (PAT/SAT), поэтому для сессий по умолчанию не требуется настройка opt-in. Подобранные документы OpenAPI описывают аутентификацию bearer/session; режим OAuth сервера пересылает bearer-токен текущей сессии. Автоматизированные регрессионные тесты проверяют оба пути заголовков; аутентификация через шлюз остается subject to конфигурации целевой среды.

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

API поддерживает два пути приема. Сохраняйте эти формы запросов, нативные для API:

Источник, доступный агенту кодирования	Поток API
Ссылка/коннектор репозитория GitHub	harness_create с resource_type="vibe_project" и body.mode плюс поля, специфичные для режима. Контракт называет github_link и github_connector, но не определяет формы их URL, ветки или полей коннектора; эти поля пересылаются в бэкенд без изобретения маппинга.
ZIP-файл	Вызовите prepare с именем приложения и метаданными файла, загрузите байты на возвращенную подписанную цель, затем вызовите deploy.
Локальный исходный каталог	Агент кодирования архивирует исходный код целевого рабочего пространства в ZIP локально, затем следует потоку ZIP. Локальный путь или контекст разговора не является поддерживаемым API способом загрузки исходников.

При упаковке каталога включайте исходники, манифесты, lock-файлы, конфигурацию и предполагаемые незакоммиченные правки, необходимые для сборки. Исключайте учетные данные, .git, установленные зависимости и сгенерированные артефакты. Упаковка и подписанная загрузка происходят там, где файлы доступны; размещенный MCP-сервер не может читать локальный каталог агента кодирования.

Для существующего ZIP подготовьте загрузку:

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

Передайте это в harness_execute. Размер должен описывать фактический ZIP; size_bytes, content_type и md5 являются опциональными и nullable. Дополнительные поля подготовки сохраняются для проверки бэкендом, как разрешено OpenAPI. Подготовка возвращает projectId, sourceId и upload, включая uploadUrl, method, headers и expiresAt каждого файла. Загрузите байты файла напрямую, используя этот подписанный URL, метод и заголовки; сохраняйте URL точно и не добавляйте учетные данные Harness в запрос к хранилищу. Действие подготовки не читает и не загружает локальные файлы.

После успешной загрузки явно выполните развертывание:

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

Для JSON-импортов используйте возвращенный id вместо этого. Развертывание также принимает body: {"project_id": "<Vibe app id>"} или params.app_id; поле провода API — snake_case project_id, даже если подготовка возвращает camelCase projectId. Верхнеуровневый project_id универсального инструмента — это идентификатор области Harness и никогда не используется как идентификатор приложения Vibe. Импорт и подготовка создают приложение/исходники; ни один из них не запускает развертывание. Записи не повторяются автоматически, и развертывание использует существующую политику подтверждения высокого риска.

Читайте прогресс с помощью harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Он сохраняет URL приложений, этапы выполнения, подшаги, сбои, строки журналов и детали анализатора сборки. Действие выполнения events принимает resource_id или params.app_id и потребляет конечную точку SSE как конечный пакет: до 20 JSON-событий или пять секунд после подключения, с лимитом ответа 1 МиБ. Эти лимиты принадлежат конечной точке Vibe. HARNESS_API_TIMEOUT_MS соединения также ограничивает потребление соединения и потока вместе; истечение возвращает ошибку тайм-аута. Завершенный пакет возвращает events и stop_reason (end, event_limit или duration_limit) и закрывает поток. Ни первоначальные сбои подключения, ни разорванные потоки не повторяются. События — это временные диффы без документированного курсора воспроизведения; используйте lifecycle get для авторитетного снимка. Оба чтения lifecycle доступны в режиме только для чтения.

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

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
fme_workspace	x
fme_environment	x	x	x	x	x
fme_feature_flag	x	x	x	x	x	kill, restore, reallocate, archive, unarchive
fme_feature_flag_definition	x	x	x	x	x	kill, restore, reallocate
fme_rollout_status	x
fme_rule_based_segment	x	x	x		x
fme_rule_based_segment_definition	x			x		enable, disable, change_request
fme_traffic_type	x
fme_identity			x	x
fme_standard_segment	x	x
fme_segment_keys	x			x
fme_segment	x	x	x	x	x
fme_segment_definition	x	x	x	x	x	list_keys, add_keys, remove_keys
fme_metric	x	x	x	x	x
fme_event_type	x	x

Ресурсы 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. Покрытие нативного режима Harness в настоящее время уже:

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

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

• fme_feature_flag — двухрежимный, обе ветви полностью подключены. Harness-native (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-native (org_id+project_id) — в MCP никогда не было контракта workspace_id для этих операций. Нативный список требует feature_flag_name и использует offset/limit (по умолчанию 100, максимум 100); он не принимает environment_id. Delete и execute требуют environment_id. Kill/restore/reallocate — те же действия, что и для fme_feature_flag. Тело get/create/update соответствует устаревшему (treatments, defaultTreatment, defaultRule, необязательные rules/baselineTreatment/trafficAllocation/comment), плюс необязательный title в режиме Harness-native. Нативное обновление — это 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-native отклоняется для каждой операции (list/get/create/delete) — используйте fme_segment вместо этого; этот ресурс поддерживает только устаревший контракт workspace_id.

• fme_rule_based_segment_definition — (Устарел — см. fme_segment_definition.) Режим Harness-native отклоняется для каждой операции/действия (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 — устарел. Устаревший workspace_id по-прежнему обращается к Split v2. Harness-native отклоняется — используйте fme_segment.

• fme_segment_keys — list/update остаются устаревшими (workspace_id / environment_id+segment_name). Harness-native (org_id+project_id) отклоняется — используйте fme_segment_definition execute list_keys/add_keys/remove_keys.

• fme_segment — Только нативный (org_id+project_id). CRUD. list/get/update/delete требуют segment_type: STANDARD | LARGE | RULE_BASED. Тело create: name, trafficType, segmentType; необязательные description, tags, owners.

• fme_segment_definition — Только нативный. CRUD плюс execute list_keys/add_keys/remove_keys. Обновление — только описание. Delete завершается ошибкой с hasDependents, пока остаются ключи.

• fme_metric — Только Harness-native (без поддержки устаревшего workspace_id). list/get/create/update/delete подключены к /fme/api/v4/metrics (list's harness_list size сопоставляется с limit). create требует spread, даже если бэкенд CreateMetricRequest оставляет его необязательным (по умолчанию PER) — это более строгий контракт только на стороне MCP, поскольку его пропуск молча меняет семантику метрики RATE. update — это JSON Merge Patch; name/trafficType неизменяемы и не принимаются. delete — это постоянное жесткое удаление (без архивации/восстановления) — классифицируется как destructive.

• fme_event_type — Только Harness-native (без поддержки устаревшего workspace_id). Только чтение: list/get подключены к /fme/api/v4/event-types; id — это имя события. Видны только типы событий с событиями за последние 30 дней; get возвращает 404 для типа события вне области типа трафика запрашивающего рабочего пространства или неактивного дольше 30 дней. Фильтры списка: name (подстрока), traffic_type (по ID или имени), offset/limit (harness_list size сопоставляется с limit). Используйте это для обнаружения реальных ID типов событий перед ссылкой на них в fme_metric's baseEventTypes/filterEventType или фильтре event_type_ids, вместо угадывания ID.

В однопользовательском/самостоятельно размещенном режиме аутентификация в устаревшем режиме использует 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 поддерживает полное управление жизненным циклом в устаревшем режиме: create (требует traffic_type_id), list, get, update метаданных, delete и execute-действия 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_argo_project	x
gitops_app_project_mapping	x		x	x	x	import
gitops_autocreate_log	x
gitops_application	x	x				sync
gitops_cluster	x	x
gitops_repository	x	x
gitops_applicationset	x	x
gitops_repo_credential	x	x
gitops_app_event	x
gitops_pod_log		x
gitops_managed_resource	x
gitops_resource_action	x
gitops_dashboard		x
gitops_app_resource_tree		x
gitops_cluster_link	x		x		x

Chaos Engineering

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

Управление затратами в облаке (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
ai_budget	x	x	x	x	x
ai_budget_overview		x
ai_budget_consumption	x
ai_budget_override_request	x	x	x			approve, reject

Аналитика инженерных процессов (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

Хранилище свидетельств

Хранилище свидетельств хранит атестации in-toto (свидетельства SDLC). Список поддерживает область действия учетной записи/организации/проекта через resource_scope. Одиночные фильтры свободного текста (конвейер, артефакт отдельно, 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, когда запрошенный результат — одобрение на уровне учетной записи, организации или проекта.

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

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
user	x	x
user_group	x	x	x	x	x
service_account	x	x	x		x
role	x	x	x		x
role_assignment	x		x
resource_group	x	x	x		x
permission	x

Управление

Тип ресурса	Список	Получить	Создать	Обновить	Удалить	Выполнить действия
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	Description	Parameters
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	Интерактивное создание Harness AI-агента — проверка существующих агентов (определение текущего формата спецификации agent.uses против устаревшего agent.step.group.steps при обновлении), сбор требований, генерация спецификации агента в соответствующем формате, подтверждение с пользователем, затем создание или обновление через 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	Description	Parameters
optimize-costs	Анализ данных о затратах на облако, выявление рекомендаций и аномалий, приоритизированных по потенциальной экономии	projectId (необязательный)
cloud-cost-breakdown	Глубокий анализ затрат на облако по сервисам, окружениям или кластерам с анализом трендов и обнаружением аномалий	perspectiveId (необязательный), projectId (необязательный)
commitment-utilization-review	Анализ использования зарезервированных экземпляров и планов сбережений для поиска потерь и оптимизации обязательств	projectId (необязательный)
cost-anomaly-investigation	Расследование аномалий затрат — определение первопричины, затронутых ресурсов и мер по исправлению	projectId (необязательный)
rightsizing-recommendations	Анализ и приоритизация рекомендаций по изменению размеров, опциональное создание тикетов Jira или ServiceNow	projectId (необязательный), minSavings (необязательный)

DevSecOps

Prompt	Description	Parameters
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 Ресурсы

Resource URI	Description	MIME Type
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
agent-docs:///legacy-format	Справочник по устаревшему формату спецификации агента (agent.step.group.steps / PLUGIN_TASK), читается промптом create-agent при обновлении существующего агента в устаревшем формате	text/markdown

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

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

• ansible — Harness Ansible (инвентаризации, плейбуки, хосты, активность). Опционально, поскольку ограничено проектом и добавляет концепции, которые многим пользователям не нужны.
• autonomous_work — Development Harness (автономная работа). Опционально; см. описание набора инструментов для области действия.
• observability-evaluations — Планируемые правила оценки производственной телеметрии. Опционально, поскольку зависит от развернутой плоскости управления оценкой.
• registries-v3 — Harness Artifact Registry v3 (пакеты, версии, файлы, метаданные, сканирования, исключения брандмауэра). Опционально до появления записи v3, чтобы агентам не приходилось различать реестры/артефакты v1 и пакеты/версии v3.

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

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

# 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, fme_metric, fme_event_type
gitops	gitops_agent, gitops_argo_project, gitops_app_project_mapping, gitops_autocreate_log, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree, gitops_cluster_link
chaos	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
autonomous_work (по желанию)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
access_control	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
observability-evaluations (по желанию)	observability_evaluation_rule
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
registries-v3 (по желанию)	package_v3, version_v3, file_v3, registry_metadata_v3, package_metadata_v3, version_metadata_v3, file_metadata_v3, metadata_key_v3, metadata_value_v3, artifact_scan_v3, bulk_scan_evaluation_v3, firewall_exception_v3, firewall_exception_version_v3
release-management	release_process, release_activity, release, release_execution_phase, release_execution_task, release_execution_activity, release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_input, release_execution_activity_output
vibe	vibe_project, vibe_app_lifecycle

Архитектура

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

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

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.
• Границы пагинации enforced. Запросы списков ограничены 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 branch
wait: true вернул _wait.error	Триггер конвейера выполнен успешно, но опрос на стороне сервера не удался	Повторно проверьте execution_id с помощью harness_get(resource_type="execution", ...) перед решением о повторном запуске
wait: true вернул execution_timed_out: true	Выполнение не достигло конечного статуса до wait_timeout_seconds	Используйте возвращенный execution_id для повторной проверки статуса; дождитесь конечного статуса перед запуском harness_diagnose
Журналы выполнения пусты или загрузка blob возвращает 403	URL-адреса blob-журналов, размещенных в 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