Harness MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

harness_status

Read-only

Get a live project health overview with recent failed and running executions plus deployment activity; pass a Harness URL to auto-extract org and project.

Instructions

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?'

Input Schema

Name	Required	Description
`url`	No	A Harness UI URL — org and project are extracted automatically
`limit`	No	Max items per section (default 5, max 20)
`org_id`	No	Org identifier. Required unless a Harness URL is passed (no configured default).
`project_id`	No	Project identifier. Required for project-scoped resources unless a Harness URL is passed (no configured default).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv3.2.35Oct 24, 2026

changedInput schema / properties / org_id / description

Previous value: -"Organization identifier. Required for org- and project-scoped resources unless a Harness URL is passed. This session has no configured default (common in hosted/multi-user HTTP) — pass the current org_id on the first call. Do not omit it."New value: +"Org identifier. Required unless a Harness URL is passed (no configured default)."

changedInput schema / properties / project_id / description

Previous value: -"Project identifier. Required for project-scoped resources unless a Harness URL is passed. This session has no configured default (common in hosted/multi-user HTTP) — pass the current project_id on the first call. Do not omit it."New value: +"Project identifier. Required for project-scoped resources unless a Harness URL is passed (no configured default)."

changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +{}
```

removedOutput schema / properties / failed_executions

Removed value: -{
-  "description": "Recent failed executions",
-  "items": {
-    "additionalProperties": {},
-    "properties": {},
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / openInHarness

Removed value: -{
-  "description": "Deep link to project in Harness UI",
-  "type": "string"
-}

removedOutput schema / properties / project

Removed value: -{
-  "additionalProperties": {},
-  "description": "Project scope",
-  "properties": {
-    "org": {
-      "description": "Organization identifier",
-      "type": "string"
-    },
-    "project": {
-      "description": "Project identifier",
-      "type": "string"
-    }
-  },
-  "required": [
-    "org",
-    "project"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / recent_activity

Removed value: -{
-  "description": "Recent execution activity",
-  "items": {
-    "additionalProperties": {},
-    "properties": {},
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / running_executions

Removed value: -{
-  "description": "Currently running executions",
-  "items": {
-    "additionalProperties": {},
-    "properties": {},
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / summary

Removed value: -{
-  "additionalProperties": false,
-  "description": "Execution health summary",
-  "properties": {
-    "health": {
-      "description": "Overall project health",
-      "enum": [
-        "healthy",
-        "degraded",
-        "failing"
-      ],
-      "type": "string"
-    },
-    "total_failed": {
-      "description": "Count of failed executions",
-      "type": "number"
-    },
-    "total_recent": {
-      "description": "Count of recent executions",
-      "type": "number"
-    },
-    "total_running": {
-      "description": "Count of running executions",
-      "type": "number"
-    }
-  },
-  "required": [
-    "total_failed",
-    "total_running",
-    "total_recent",
-    "health"
-  ],
-  "type": "object"
-}

removedOutput schema / required

Removed value: -[
-  "project",
-  "summary",
-  "failed_executions",
-  "running_executions",
-  "recent_activity"
-]

Changed2 schema fields changedv3.2.22Sep 1, 2026

changedInput schema / properties / org_id / description

Previous value: -"Organization identifier (overrides default)"New value: +"Organization identifier. Required for org- and project-scoped resources unless a Harness URL is passed. This session has no configured default (common in hosted/multi-user HTTP) — pass the current org_id on the first call. Do not omit it."

changedInput schema / properties / project_id / description

Previous value: -"Project identifier (overrides default)"New value: +"Project identifier. Required for project-scoped resources unless a Harness URL is passed. This session has no configured default (common in hosted/multi-user HTTP) — pass the current project_id on the first call. Do not omit it."

First observedv3.2.10Jul 16, 2026

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results are 'live' and grouped into three sections, but says nothing about the cost of aggregating multiple sources, rate limits, or what happens when a section is empty. Useful but modest added context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is returned before the convenience of URL scoping and the example use case. Every sentence carries distinct information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations cover safety, so the description needn't explain return values or permissions. What it does provide — the three result sections and the URL shortcut — is enough for correct invocation; only the absence of any alternative-tool routing keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so org_id, project_id, url, and limit are all already documented in the schema. The description only restates that a Harness URL auto-extracts org and project, which duplicates the schema's own description of url. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Get a live project health overview') and enumerates exactly what the response aggregates: recent failed executions, running executions, and deployment activity. That composite scope clearly separates it from the generic CRUD siblings like harness_list and harness_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a concrete usage trigger — 'Ideal first question: what's happening in my project right now?' — which tells the agent this is an entry-point/triage call. It also notes the URL shortcut for scoping. However, it never names an alternative or states when to prefer harness_list/harness_diagnose instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server