Harness MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HARNESS_API_KEY | Yes | Harness personal access token or service account token. | |
| HARNESS_BASE_URL | No | Base URL for Harness API. Override for self-managed Harness. | https://app.harness.io |
| HARNESS_ACCOUNT_ID | No | Harness account identifier. Required when the API key is not a PAT token (i.e., not in format pat.<accountId>.<tokenId>.<secret>). | |
| HARNESS_DEFAULT_ORG_ID | No | Default organization identifier. | default |
| HARNESS_DEFAULT_PROJECT_ID | No | Default project identifier. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| harness_listA | List Harness resources with filtering and pagination. Accepts a Harness URL to auto-extract scope. |
| harness_getA | Get a Harness resource by ID. Accepts a Harness URL to auto-extract identifiers. For failure analysis, prefer harness_diagnose. |
| harness_createA | Create a Harness resource. For pipelines: use body.yamlPipeline (YAML string, recommended) or body.pipeline (JSON). For remote pipelines, pass git details in params: external Git (store_type='REMOTE', connector_ref, repo_name, branch, file_path) or Harness Code (store_type='REMOTE', is_harness_code_repo=true, repo_name, branch, file_path). For others: call harness_describe for the body format. |
| harness_updateA | Update an existing Harness resource. You can pass a Harness URL to auto-extract identifiers. Response includes openInHarness link to the updated resource when applicable. |
| harness_deleteA | Delete a Harness resource. You can pass a Harness URL to auto-extract identifiers. This is destructive and cannot be undone. |
| harness_executeA | Execute an action on a Harness resource: run/retry/interrupt pipelines, kill/restore FME feature flags, test connectors, sync GitOps apps, run chaos experiments. You can pass a Harness URL to auto-extract identifiers. |
| harness_diagnoseA | Diagnose a Harness resource — analyze failures, test connectivity, check health, or troubleshoot GitOps sync issues. Defaults to pipeline execution diagnosis. Accepts a Harness URL to auto-detect the resource type. |
| harness_searchA | Search across multiple Harness resource types. Returns results ranked by relevance. Accepts a Harness URL for scope. |
| harness_describeA | Describe available Harness resource types, their supported operations, and fields. No API call — returns local metadata only. Use this to discover what resource_types you can use with other harness_ tools. |
| harness_statusA | Get a live project health overview: recent failed executions, currently running executions, and recent deployment activity. You can pass a Harness URL to auto-extract org and project. Ideal first question: 'what's happening in my project right now?' |
| harness_schemaA | Fetch Harness YAML schema for a resource type. Returns the JSON Schema definition so you know the exact body structure for harness_create/harness_update. Use without path for a summary of fields and available sections. Use with path to drill into a specific section (e.g. path='scheduled_trigger' for cron trigger spec). Available schemas: pipeline, template, trigger. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| debug-pipeline-failure | Analyze a failed pipeline execution and suggest fixes. Accepts an execution ID, pipeline ID, or Harness URL. |
| create-pipeline | Generate a new Harness pipeline YAML from requirements |
| optimize-costs | Analyze cloud cost data and recommend optimizations for a Harness project |
| security-review | Review security issues across Harness resources and suggest remediations |
| onboard-service | Walk through onboarding a new service into Harness with environments and a deployment pipeline |
| dora-metrics-review | Review DORA metrics (deployment frequency, change failure rate, MTTR, lead time) and suggest improvements |
| setup-gitops-application | Guide through onboarding a GitOps application — verify agent, cluster, repo, and create the application |
| chaos-resilience-test | Design and run a chaos experiment to test service resilience |
| feature-flag-rollout | Plan and execute a progressive FME feature flag rollout across environments |
| migrate-pipeline-to-template | Analyze an existing pipeline and extract reusable stage/step templates from it |
| delegate-health-check | Check delegate connectivity, health, and token status with troubleshooting guidance |
| developer-portal-scorecard | Review IDP scorecards for services and identify gaps to improve developer experience |
| cloud-cost-breakdown | Deep-dive into cloud costs by service, environment, or cluster with trend analysis |
| commitment-utilization-review | Analyze reserved instance and savings plan utilization to find waste and optimize commitments |
| cost-anomaly-investigation | Investigate cost anomalies — determine root cause, impacted resources, and remediation |
| rightsizing-recommendations | Review and prioritize rightsizing recommendations, optionally create Jira or ServiceNow tickets |
| vulnerability-triage | Triage security vulnerabilities across pipelines and artifacts, prioritize by severity and exploitability |
| sbom-compliance-check | Audit SBOM and compliance posture for artifacts — license risks, policy violations, component vulnerabilities |
| supply-chain-audit | End-to-end software supply chain security audit — provenance, chain of custody, policy compliance |
| security-exemption-review | Review pending security exemptions and make batch approval or rejection decisions |
| access-control-audit | Audit user permissions, over-privileged accounts, and role assignments to enforce least-privilege |
| code-review | Review a Harness Code pull request — analyze diff, commits, checks, and comments to provide structured feedback |
| pr-summary | Auto-generate a pull request title and description from the commit history and diff of a branch |
| branch-cleanup | Analyze branches in a repository and recommend stale or merged branches to delete |
| pending-approvals | Find pipeline executions waiting for approval and present them for action |
| build-deploy-app | End-to-end workflow: scan a repo, generate CI/CD pipelines in Harness, build a Docker image, generate K8s manifests, and deploy |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| execution-summary | Recent pipeline execution summaries (last 10). |
| pipeline schema | Harness JSON Schema definitions. Valid schema names: pipeline, template, trigger. Use these to understand the required body format for harness_create. |
| template schema | Harness JSON Schema definitions. Valid schema names: pipeline, template, trigger. Use these to understand the required body format for harness_create. |
| trigger schema | Harness JSON Schema definitions. Valid schema names: pipeline, template, trigger. Use these to understand the required body format for harness_create. |
TDQS
Scored across 11 tools
Each tool has a distinct verb (create, delete, describe, diagnose, execute, get, list, schema, search, status, update) with clear, non-overlapping purposes. Descriptions provide enough detail to differentiate, e.g., harness_get retrieves by ID while harness_list applies filters.
All tools follow the exact pattern 'harness_<verb>' with lowercase snake_case. The verb choice is consistent and descriptive, creating a predictable and easy-to-navigate naming convention.
11 tools cover the core operations for Harness resources (CRUD, search, status, diagnosis, execution, schema discovery) without being overwhelming. Each tool serves a clear purpose within the DevOps platform domain.
The tool set covers creation, retrieval, listing, updating, deletion, schema validation, search, status monitoring, diagnosis, and execution actions. A minor gap is the lack of a dedicated tool for fetching detailed execution logs or history, but harness_status and harness_diagnose partially address this.