The consolidation is the whole design argument: Harness is broad enough that one-tool-per-endpoint would give an agent hundreds of choices and fill the context with schemas, so the verbs stay fixed and a resource type rides along as an argument. harness_describe and harness_status make that navigable — the agent asks what resource types exist and what is failing right now before it reaches for a specific action.
Harness's official server for its CI/CD and platform suite. Rather than one tool per endpoint, it uses 11 consolidated tools that a registry dispatches to 240 resource types, spanning 39 default toolsets. It runs over stdio or HTTP.
- The CRUD verbs applied to any Harness resource by type: harness_list with filtering and pagination, harness_get, harness_create, harness_update and harness_delete — each able to auto-extract scope and identifiers from a pasted Harness URL
- harness_execute runs actions across the platform: run, retry or interrupt a pipeline, kill or restore a feature flag, test a connector, sync a GitOps app, or run a chaos experiment, with wait:true to block until a pipeline reaches a terminal state
- harness_diagnose analyzes a failure, tests connectivity, checks health or troubleshoots a GitOps sync, defaulting to pipeline-execution diagnosis
- harness_status gives a live project overview — recent failed executions, currently running ones, recent deployments — the tool for 'what's happening in my project right now?'
- harness_search ranks results across multiple resource types, and harness_describe returns local metadata about which resource types and operations exist, with no API call, so an agent can discover what it can act on
- harness_schema fetches the YAML schema or examples for a resource type — pipeline and template schemas bundled, connector, environment, service, secret and infrastructure schemas fetched live
- Coverage spanning CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, the Internal Developer Portal, Software Supply Chain and Governance, with opt-in Ansible
- Multi-project navigation without hardcoded scope — agents discover organizations and projects dynamically, so 'show failed executions across all projects' walks the account hierarchy on its own
A Harness API key — a PAT or SAT token in the form <prefix>.<accountId>.<tokenId>.<secret> — held in HARNESS_API_KEY. The account ID is auto-extracted from the token, so HARNESS_ACCOUNT_ID is only needed for keys without an embedded account segment, and org/project defaults are optional. Run it with npx harness-mcp-v2 over stdio, or with the http argument on a port for a shared deployment, where each session supplies its key as an x-harness-api-key header so the Harness audit trail reflects the real user. A hosted endpoint exists but uses Harness Platform OAuth and must be enabled per account by Harness Support.
One command plus a key — HARNESS_API_KEY=pat.xxx.xxx.xxx npx harness-mcp-v2@latest, then supply credentials