Skip to main content
Glama
harness

Harness MCP Server

Official
by harness

harness_execute

Destructive

Execute actions on Harness resources: run/retry pipelines, toggle feature flags, test connectors, sync GitOps apps, and run chaos experiments. Optionally wait for pipeline completion.

Instructions

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. Pass wait: true for pipeline run/retry to block until the execution reaches a terminal status — single tool call instead of an LLM polling loop. For HQL batch operations pass queries with resource_type='hql_query' and action='validate' or 'run'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHarness UI URL — auto-extracts org, project, type, and ID
bodyNoAdditional body payload for the action
waitNoFor pipeline run/retry actions: block until the execution reaches a terminal status (Success/Failed/Aborted/Errored/Expired). Server-side polling — a single tool call gives the agent the final outcome instead of an LLM polling loop. Ignored for other actions.
actionYesAction to execute (e.g. run, retry, interrupt, toggle, test_connection, sync)
inputsNoPipeline runtime inputs: key-value pairs like {branch: 'main'} (auto-resolved), or full YAML string. Check runtime_input_template first via harness_get.
org_idNoOrganization identifier (overrides default)
paramsNoAction-specific parameters. Call harness_describe for available fields per resource_type.
confirmNoSet to true to confirm the operation. Only required when the action's risk is medium_write or above (e.g. pipeline.run is high_write; hql_query.run/validate are read and need no confirmation) AND the client cannot surface a confirmation prompt — e.g. managed MCP that does not advertise elicitation, or an elicitation that fails at runtime. Has no effect for low-risk actions. Does NOT override an explicit decline from a client that completed an elicitation prompt — a user's decline is authoritative.
queriesNoBatch HQL queries — use with resource_type='hql_query' and action='validate' or 'run'. Fans out in parallel, returns per-query results.
project_idNoProject identifier (overrides default)
resource_idNoPrimary resource identifier
input_set_idsNoInput set IDs for complex pipelines. List available: harness_list(resource_type='input_set', filters={pipeline_id: '...'}).
resource_typeNoResource type with executable actions. Auto-detected from url.
resource_scopeNoScope for the operation. account: omit org/project (e.g. /v1/templates). org: org only. project: org+project. Auto-detected from url when present.
wait_timeout_secondsNoMax seconds to wait when wait=true. Default 600 (10 min). Max 7200 (2 h). When the timeout fires, returns execution_timed_out=true with the last observed status.
wait_poll_interval_secondsNoInitial poll interval when wait=true (seconds). Default 3. Backoff multiplier 1.5x, capped at 30s.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Description adds significant behavioral context beyond annotations: server-side polling with wait, timeout returning execution_timed_out=true, backoff interval, confirm semantics for medium_write+ risk and interaction with client elicitation, auto-detection from URL, parallel fan-out for HQL queries. No contradiction with annotations (destructiveHint=true aligns with kill/interrupt actions).

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?

The description is a single dense paragraph, but every sentence serves a distinct purpose: stating scope, URL extraction, wait behavior, HQL batching, confirm requirements. It front-loads the primary purpose and avoids filler.

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 tool's complexity (16 params, many resource types), the description covers the core behaviors—wait, confirm, queries, URL extraction—and relies on output schema for return details. It appropriately references harness_describe for more detail, making it sufficient for correct invocation.

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

Parameters4/5

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

Schema already describes all parameters with 100% coverage, so baseline is 3. The description enhances this by linking inputs to harness_get for runtime_input_template and params to harness_describe, and clarifying wait/queries/confirm usage. This adds practical guidance beyond schema descriptions.

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 opens with a specific verb ('Execute an action') and enumerates concrete use cases (run/retry/interrupt pipelines, kill/restore FME feature flags, test connectors, sync GitOps apps, run chaos experiments), clearly distinguishing this from sibling tools like harness_get/list/create/delete. It also mentions URL auto-extraction and HQL batch operations, further specifying scope.

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 usage guidance by pointing to prerequisites: check runtime_input_template via harness_get for inputs, and call harness_describe for action-specific params. It also explains when the wait option is applicable ('for pipeline run/retry') and that it is ignored for other actions, and when to pass queries for HQL operations. It doesn't explicitly exclude pure read-only retrieval, but sibling names make that implicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/harness/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server