Harness MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

harness_diagnose

Read-only

Diagnose Harness pipeline, connector, delegate, and GitOps issues by analyzing failures, testing connectivity, checking health, and troubleshooting sync; defaults to pipeline execution diagnosis.

Instructions

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. When a TYPESAFE_API_KEY is configured, pipeline failures additionally include an advisory "triage" field classifying each failed step (category: infra_flake, test_failure, config_error, dependency_failure, permission_error, timeout; plus confidence) — failure messages, delegate info, and fetched log snippets are sent to the configured TypeSafe API to produce it; the field is omitted when the key is absent, triage is disabled, or classification times out or is low-confidence.

Input Schema

Name	Required	Description
`url`	No	A Harness URL — resource type, org, project, and ID are extracted automatically
`org_id`	No	Org identifier. Required unless a Harness URL is passed (no configured default).
`options`	No	Resource-specific options. Pipeline: execution_id, pipeline_id, summary, include_yaml, include_logs, include_all_step_logs (capped by max_all_step_logs, default 25, to avoid OOM on large matrix/loop pipelines), return_download_url, log_snippet_lines, max_failed_steps (needs a completed execution; a ?step= URL with include_logs fetches that step). GitOps: agent_id.
`project_id`	No	Project identifier. Required for project-scoped resources unless a Harness URL is passed (no configured default).
`resource_id`	No	Primary identifier of the resource (connector ID, delegate name). Auto-detected from url if provided.
`resource_type`	No	Resource type to diagnose. Auto-detected from url if provided. Defaults to pipeline.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.2.35Oct 24, 2026

changedInput schema / properties / options / description

Previous value: -"Resource-specific diagnostic options. Pipeline: execution_id, pipeline_id, summary, include_yaml, include_logs, include_all_step_logs (boolean, fetch logs for ALL steps not just failed/deepest — logs are fetched in batches of 3 for memory safety, capped at max_all_step_logs, use for pipeline summarization), max_all_step_logs (number, default 25, max steps to include in all_step_logs — prevents OOM on large matrix/loop pipelines), return_download_url (boolean, return signed logs.zip URLs instead of inline log text), log_snippet_lines, max_failed_steps. Pipeline diagnosis requires a completed execution. When a Harness URL contains ?step=<nodeExecutionId>, setting include_logs:true fetches that specific step's log regardless of pass/fail status and returns it as requested_step_log alongside any failed_step_logs. GitOps: agent_id. Call harness_describe for details."New value: +"Resource-specific options. Pipeline: execution_id, pipeline_id, summary, include_yaml, include_logs, include_all_step_logs (capped by max_all_step_logs, default 25, to avoid OOM on large matrix/loop pipelines), return_download_url, log_snippet_lines, max_failed_steps (needs a completed execution; a ?step= URL with include_logs fetches that step). GitOps: agent_id."

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

removedOutput schema / description

Removed value: -"Diagnostic data — shape varies by resource_type"

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

Changed1 schema field changedv3.2.16Jul 29, 2026

changedInput schema / properties / options / description

Previous value: -"Resource-specific diagnostic options. Pipeline: execution_id, pipeline_id, summary, include_yaml, include_logs, return_download_url (boolean, return signed logs.zip URLs instead of inline log text), log_snippet_lines, max_failed_steps. Pipeline diagnosis requires a completed execution. When a Harness URL contains ?step=<nodeExecutionId>, setting include_logs:true fetches that specific step's log regardless of pass/fail status and returns it as requested_step_log alongside any failed_step_logs. GitOps: agent_id. Call harness_describe for details."New value: +"Resource-specific diagnostic options. Pipeline: execution_id, pipeline_id, summary, include_yaml, include_logs, include_all_step_logs (boolean, fetch logs for ALL steps not just failed/deepest — logs are fetched in batches of 3 for memory safety, capped at max_all_step_logs, use for pipeline summarization), max_all_step_logs (number, default 25, max steps to include in all_step_logs — prevents OOM on large matrix/loop pipelines), return_download_url (boolean, return signed logs.zip URLs instead of inline log text), log_snippet_lines, max_failed_steps. Pipeline diagnosis requires a completed execution. When a Harness URL contains ?step=<nodeExecutionId>, setting include_logs:true fetches that specific step's log regardless of pass/fail status and returns it as requested_step_log alongside any failed_step_logs. GitOps: agent_id. Call harness_describe for details."

First observedv3.2.10Jul 16, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond annotations, the description discloses a significant behavioral trait: when TYPESAFE_API_KEY is configured, failure messages, delegate info, and log snippets are sent to an external TypeSafe API to produce an advisory triage field. It also explains omission conditions (key absent, triage disabled, timeout, low confidence), which materially changes how an agent should interpret results.

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

Conciseness4/5

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

The description is front-loaded with the main diagnostic purpose and defaults before diving into the TypeSafe triage caveat. It is dense but mostly earns its length; the triage explanation is long, though the external data-sending and omission conditions are important for correct interpretation.

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

Completeness5/5

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

Given the complexity, annotations, full schema coverage, and an output schema, the description is complete enough for correct invocation. It covers default behavior, URL-based auto-detection, resource scope, and the key external-data caveat for the triage field.

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 the schema already documents parameters such as url, options, and resource_type in detail. The description reiterates URL auto-detection and default pipeline behavior but does not add parameter semantics beyond what the schema provides, so the baseline of 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?

The description uses a specific verb and resource: 'Diagnose a Harness resource,' then enumerates concrete diagnostic modes (failures, connectivity, health, GitOps sync). It also states the default behavior ('pipeline execution diagnosis') and URL auto-detection, which clearly differentiates it from generic siblings like harness_get and harness_list.

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?

Usage context is clear: the tool diagnoses resources, defaults to pipeline execution diagnosis, and accepts a Harness URL for auto-detection. However, it does not explicitly state when to choose harness_diagnose over siblings such as harness_get, harness_status, or harness_describe, nor does it list exclusions.

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

Deploy Server