Skip to main content
Glama
harness

Harness MCP Server

Official
by harness

harness_execute

Destructive

Run, retry, or interrupt pipelines; toggle feature flags; test connectors; sync GitOps apps; run chaos experiments on Harness. Auto-extracts identifiers from a URL and can 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?

The description discloses key behavioral traits beyond annotations: it explains the destructive nature (alignment with destructiveHint=true), the wait mechanism for pipeline operations, the confirm parameter for high-risk actions, and the HQL batch behavior. It also clarifies that wait is ignored for non-pipeline actions. No contradictions with annotations.

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 quite long but well-structured, front-loading the key actions and then detailing parameters. Every sentence adds value, covering multiple resource types and edge cases. It could be slightly more concise, but it is organized and easy to parse.

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 (16 parameters, many enums, nested objects, and an output schema), the description is remarkably complete. It covers all major use cases (pipelines, feature flags, connectors, GitOps, chaos, HQL) and explains the wait, confirm, and URL extraction features. It leaves little ambiguity for an AI agent.

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 description coverage is 100%, so baseline is 3. The description adds meaningful extra context beyond the schema, such as how wait blocks until terminal status, how confirm works with risk levels, and how queries fan out for HQL. This elevates the score above baseline.

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 clearly states that the tool executes actions on Harness resources, listing specific actions like run/retry/interrupt pipelines, kill/restore FME feature flags, test connectors, sync GitOps apps, and run chaos experiments. It distinguishes itself from sibling CRUD tools (harness_create, harness_delete, etc.) by focusing on execution rather than creation or deletion.

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?

The description provides clear context for when to use the tool, such as for executing actions on resources, using a Harness URL to auto-extract identifiers, and using wait:true for pipeline run/retry. It also mentions HQL batch operations. However, it does not explicitly state when NOT to use it or provide direct alternatives from sibling tools, though the sibling names imply differentiation.

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