Labsco
harness logo

Harness

★ 78

from harness

Access and interact with Harness platform data, including pipelines, repositories, logs, and artifact registries.

🔥🔥🔥🔥✓ VerifiedAccount requiredAdvanced setup
#automation#payments#database#cloud#devops#git#maps#security

Harness MCP Server 2.0

An MCP (Model Context Protocol) server that gives AI agents full access to the Harness.io platform through 11 consolidated tools and 219 resource types.

Why Use This MCP Server

Most MCP servers map one tool per API endpoint. For a platform as broad as Harness, that means 240+ tools — and LLMs get worse at tool selection as the count grows. Context windows fill up with schemas, and every new endpoint means new code.

This server is built differently:

  • 11 tools, 219 resource types. A registry-based dispatch system routes harness_list, harness_get, harness_create, etc. to any Harness resource — pipelines, services, environments, orgs, projects, feature flags, cost data, and more. The LLM picks from 11 tools instead of hundreds.
  • Full platform coverage. 38 default toolsets spanning CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, Internal Developer Portal, Software Supply Chain, Infrastructure as Code Management, Governance, Service Overrides, Knowledge Graph, Visualizations, and more. Opt-in Ansible coverage is available when you need inventory and playbook data.
  • Multi-project workflows out of the box. Agents discover organizations and projects dynamically — no hardcoded env vars needed. Ask "show failed executions across all projects" and the agent can navigate the full account hierarchy.
  • 32 prompt templates. Pre-built prompts for common workflows: build & deploy apps end-to-end, debug failed pipelines, review DORA metrics, triage vulnerabilities, optimize cloud costs, audit access control, plan feature flag rollouts, review pull requests, approve pending pipelines, and more.
  • Works everywhere. Stdio transport for local clients (Claude Desktop, Cursor, Devin Desktop), HTTP transport for remote/shared deployments, Docker and Kubernetes ready.
  • Zero-config start. Just provide a Harness API key. Account ID is auto-extracted from PAT and SAT tokens, org/project defaults are optional, and toolset filtering lets you expose only what you need.
  • Extensible by design. Adding a new Harness resource means adding a declarative data file — no new tool registration, no schema changes, no prompt updates.

Tools Reference

The server exposes 11 MCP tools. Most API tools accept org_id and project_id as optional overrides — if omitted, they fall back to HARNESS_ORG and HARNESS_PROJECT. harness_describe is local metadata only and does not use org/project scope.

URL support: Most API-facing tools accept a url parameter — paste a Harness UI URL and the server auto-extracts org, project, resource type, resource ID, pipeline ID, and execution ID. harness_describe does not accept url.

Scope support: Resource types with account/org/project variants expose supportedScopes in harness_describe. Pass resource_scope when you need a specific level:

  • resource_scope: "account" sends only accountIdentifier.
  • resource_scope: "org" sends accountIdentifier and orgIdentifier.
  • resource_scope: "project" sends account, org, and project identifiers.

Current multi-scope resources include connector, service, environment, infrastructure, secret, file_store, and template. If resource_scope is omitted, the registry uses the resource's default scope and configured defaults, except resources marked as optional scope may omit org/project unless explicitly passed. Harness URLs can also set the scope automatically when the path contains account-level or project-level context.

Structured output: Every tool declares an MCP outputSchema. harness_list normalizes list-like Harness responses into object-shaped structured content so strict clients can validate it: top-level arrays become { "items": [...], "total": <count>, "page": <page> }, and common wrapper keys such as content, data, body, objects, or features are hoisted to items when needed. The text response still contains the compact JSON payload returned to all clients.

ToolDescription
harness_describeDiscover available resource types, operations, and fields. No API call — returns local registry metadata.
harness_schemaFetch exact YAML/JSON Schema definitions and examples for creating/updating resources. Pipeline/template schemas are bundled; connector, environment, service, secret, and infrastructure schemas are scope-aware entity schemas fetched from bundled snapshots or NG /yaml-schema. Supports deep drilling via path.
harness_listList resources of a given type with filtering, search, and pagination.
harness_getGet a single resource by its identifier.
harness_createCreate a new resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via elicitation.
harness_updateUpdate an existing resource. Supports inline and remote (Git-backed) pipelines. Prompts for user confirmation via elicitation.
harness_deleteDelete a resource. Prompts for user confirmation via elicitation. Destructive.
harness_executeExecute an action on a resource (run/retry pipeline, import pipeline from Git, toggle flag, sync app). Prompts for user confirmation via elicitation. For pipeline runs, use the runtime-input workflow below (supports branch/tag/pr_number/commit_sha shorthand expansion).
harness_searchSearch across Harness resource types with a single query. Uses semantic routing (local all-MiniLM-L6-v2 ONNX embeddings, 384-dim) to predict relevant resource types from a knowledge corpus indexed at startup — typically narrowing from ~163 types to 1–8 before scatter-gather. Falls back to full keyword scatter-gather when semantic confidence is low. Response includes semantic_routed and types_skipped when routing fires. See docs/search-guidelines.md for how to make new resource types discoverable.
harness_diagnoseDiagnose pipeline, connector, delegate, and gitops_application resources (aliases: execution -> pipeline, gitops_app -> gitops_application). For pipelines, returns stage/step timing and failure details; for connectors/delegates/GitOps apps, returns targeted health and troubleshooting signals.
harness_statusGet a real-time project health dashboard — recent executions, failure rates, and deep links.

Schema Lookup Workflow

Use harness_schema before creating or updating YAML-backed resources so agents can copy exact field names and constraints instead of guessing from prose.

  • Bundled schemas include pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, and agent-pipeline.
  • Entity schemas include connector, environment, service, secret, and infrastructure. They are scope-aware (account, org, or project) and require org_id/project_id when the selected scope requires them.
  • Vendored entity snapshots are used first when they match the runtime account; otherwise the tool falls back to the Harness NG /yaml-schema API and caches the result.
  • Omit path for a field/section summary, then pass a dot-separated path to inspect a nested definition.

Examples:

{ "resource_type": "pipeline", "path": "pipeline.stages" }
{
  "resource_type": "connector",
  "scope": "project",
  "org_id": "default",
  "project_id": "payments"
}

Maintainers can refresh the vendored entity snapshots with pnpm sync-entity-schemas when Harness entity YAML schemas change.

Tool Examples

Discover what resources are available:

{ "resource_type": "pipeline" }

List organizations in the account:

{ "resource_type": "organization" }

List projects in an organization:

{ "resource_type": "project", "org_id": "default" }

List pipelines in a project:

{ "resource_type": "pipeline", "search_term": "deploy", "size": 10 }

Get a specific service:

{ "resource_type": "service", "resource_id": "my-service-id" }

Run a pipeline:

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "my-pipeline",
  "inputs": { "tag": "v1.2.3" },
  "wait": true
}

Toggle a feature flag:

{
  "resource_type": "feature_flag",
  "action": "toggle",
  "resource_id": "new_checkout_flow",
  "enable": true,
  "environment": "production"
}

Search across all resource types:

{ "query": "payment-service" }

Diagnose an execution by ID (summary mode — default):

{ "execution_id": "abc123XYZ" }

Diagnose from a Harness URL:

{ "url": "https://app.harness.io/ng/account/.../pipelines/myPipeline/executions/abc123XYZ/pipeline" }

Diagnose connector connectivity:

{ "resource_type": "connector", "resource_id": "my_github_connector" }

Diagnose delegate health:

{ "resource_type": "delegate", "resource_id": "delegate-us-east-1" }

Diagnose a GitOps application (with options):

{
  "resource_type": "gitops_application",
  "resource_id": "checkout-app",
  "options": { "agent_id": "gitops-agent-1" }
}

Get the latest execution report for a pipeline:

{ "pipeline_id": "my-pipeline" }

Full diagnostic mode with YAML and failed step logs:

{ "execution_id": "abc123XYZ", "summary": false }

Summary mode with logs enabled (best of both):

{ "execution_id": "abc123XYZ", "include_logs": true }

Get project health status:

{ "org_id": "default", "project_id": "my-project", "limit": 5 }

List database schemas filtered by migration type:

{ "resource_type": "database_schema", "migration_type": "Liquibase" }

List database instances for a schema:

{ "resource_type": "database_instance", "dbschema_id": "my_schema" }

Get the resolved LLM authoring pipeline for a schema and instance:

{ "resource_type": "database_llm_authoring_pipeline", "resource_id": "my_schema", "dbinstance_id": "prod_db" }

List snapshot object names (e.g. tables) for a schema instance:

{
  "resource_type": "database_snapshot_object",
  "dbschema_id": "my_schema",
  "dbinstance_id": "prod_db",
  "object_type": "Table"
}

Get full snapshot metadata for specific named objects:

{
  "resource_type": "database_snapshot_object",
  "resource_id": "prod_db",
  "params": {
    "dbschema_id": "my_schema",
    "object_type": "Table",
    "object_names": ["users", "orders"]
  }
}

Use this sequence to reduce execution-time input errors:

  1. Discover required runtime inputs
  • harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
  • The returned template shows <+input> placeholders that need values.
  1. Choose input strategy

  • Simple variables: pass flat key-value inputs (for example {"branch":"main","env":"prod"}).

  • Complex/structural inputs: use input_set_ids (CI codebase/build blocks and nested template inputs are best handled this way).

  • CI codebase shorthand keys (pipeline run only):

    Shorthand keyExpanded structure
    branchbuild.type=branch, build.spec.branch=<value>
    tagbuild.type=tag, build.spec.tag=<value>
    pr_numberbuild.type=PR, build.spec.number=<value>
    commit_shabuild.type=commitSha, build.spec.commitSha=<value>

  • Constraint: shorthand expansion is skipped when inputs.build is already present (explicit build wins).

  1. Execute the run

  • harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)

  • For Git-backed pipelines whose YAML should be loaded from a non-default branch, pass params.pipeline_branch (sent to Harness as pipelineBranchName):

    {
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}
  1. Optional: combine both
  • Use input_set_ids for the base shape and inputs for simple overrides.

If required fields are unresolved, the tool returns a pre-flight error with expected keys and suggested input sets. You can inspect available shorthand mappings with harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Dynamic Pipeline Execution

Use pipeline_dynamic_execution.run when an agent or external system generates the full v0 pipeline YAML at runtime and needs to run it against an existing Harness pipeline shell. This is not a replacement for normal pipeline.run: the saved v0 pipeline must already exist, account-level and pipeline-level Allow Dynamic Execution must be enabled, and the caller needs Edit plus Execute permissions on the pipeline.

{
  "resource_type": "pipeline_dynamic_execution",
  "action": "run",
  "resource_id": "deploy_app",
  "body": {
    "yaml": "pipeline:\n  identifier: deploy_app\n  name: Deploy App\n  stages: []"
  },
  "params": {
    "module_type": "CD",
    "notes": "agent-generated dynamic run",
    "notify_only_user": true
  }
}

Constraints:

  • body must be an object with a yaml field. Raw string bodies are rejected by the public harness_execute schema.
  • body.yaml may be a YAML string or a JSON pipeline object; JSON is serialized to YAML before the request.
  • Runtime <+input> placeholders are not resolved by this API. Submit fully resolved YAML.
  • Input sets, selective stage execution, retry, and triggers are not supported by the dynamic execution endpoint.
  • The action is high_write and uses the normal confirmation/auto-approval path. The response projects the API envelope to { "execution_id": "...", "status": "..." } and includes an openInHarness execution link when scope data is available.

If Harness rejects the run as not enabled, check both the account-level Allow Dynamic Execution setting and the pipeline-level toggle under Pipeline -> Advanced Options -> Dynamic Execution Settings.

Execution Input Forensics

Use execution_inputs after a run to inspect the merged input YAML that produced a specific execution. This is useful when a failure depends on input-set merging, Git-backed input set branches, or trigger/runtime values that are hard to reconstruct from the execution page alone.

{
  "resource_type": "execution_inputs",
  "resource_id": "PLAN_EXECUTION_ID",
  "params": {
    "resolve_expressions": true,
    "resolve_expressions_type": "RESOLVE_ALL_EXPRESSIONS"
  }
}

The get response is projected to:

  • executionId - the plan execution ID from resource_id.
  • inputSetYaml - merged runtime input YAML used for the run, or null.
  • inputSetTemplateYaml - input template at execution time, or null.
  • resolvedYaml - expression-resolved YAML when resolve_expressions=true, otherwise usually null.
  • inputSetDetails - contributing saved input sets as { identifier, name } pairs.
  • inputSetBranchName - source branch for Git-backed input sets, or null.

execution_inputs is get-only and read-risk. If resolve_expressions is omitted, the server omits the API query parameters and Harness uses its default UNKNOWN resolution mode.

Pipeline Execute Wait Mode

For pipeline.run, pipeline.retry, and pipeline_v1.run, pass wait: true to let the server poll until the execution reaches a terminal status. This keeps a pipeline launch and status check in one tool call instead of asking the client or LLM to run a polling loop.

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "inputs": { "branch": "main" },
  "wait": true,
  "wait_timeout_seconds": 900,
  "wait_poll_interval_seconds": 5
}

Wait mode behavior:

  • Default timeout is 600 seconds; allowed range is 10 seconds to 7200 seconds.
  • Initial poll interval defaults to 3 seconds, backs off by 1.5x, and caps at 30 seconds.
  • On success or failure, the response includes fields such as execution_id, execution_status, execution_terminal, execution_elapsed_ms, and execution_poll_count.
  • If the timeout fires, the original trigger still succeeded; the response includes execution_timed_out: true and _wait.hint with the last observed status.
  • If polling fails after the trigger succeeds, the response includes _wait.error and a recheck hint. Do not blindly rerun the pipeline unless you have confirmed the first execution is not running.
  • Failed terminal statuses include _diagnose_hint pointing to harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Ask the AI DevOps Agent to create a pipeline:

{
  "prompt": "Create a pipeline that builds a Go app with Docker and deploys to Kubernetes",
  "action": "CREATE_PIPELINE"
}

Update a service via natural language:

{
  "prompt": "Add a sidecar container for logging",
  "action": "UPDATE_SERVICE",
  "conversation_id": "prev-conversation-id",
  "context": [{ "type": "yaml", "payload": "<existing service YAML>" }]
}

Pipeline Storage Modes

Harness pipelines can be stored in three ways:

ModeDescriptionWhen to use
InlinePipeline YAML stored in HarnessDefault. Simplest setup, no Git required.
Remote (External Git)Pipeline YAML stored in GitHub, GitLab, Bitbucket, etc.Teams using Git-backed pipeline-as-code with an external provider.
Remote (Harness Code)Pipeline YAML stored in a Harness Code repositoryTeams using Harness's built-in Git hosting.

Create an inline pipeline (default):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: My Pipeline\n  identifier: my_pipeline\n  stages:\n    - stage:\n        name: Build\n        type: CI\n        spec:\n          execution:\n            steps:\n              - step:\n                  type: Run\n                  name: Echo\n                  spec:\n                    command: echo hello"
  }
}

Create a remote pipeline (External Git — e.g. GitHub):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Add deploy pipeline via MCP"
  }
}

Create a remote pipeline (Harness Code — no connector needed):

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Build App\n  identifier: build_app\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/build-app.yaml",
    "commit_msg": "Add build pipeline via MCP"
  }
}

Update a remote pipeline:

// harness_update
{
  "resource_type": "pipeline",
  "resource_id": "deploy_service",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages:\n    - stage:\n        name: Deploy\n        type: Deployment"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Update deploy pipeline via MCP",
    "last_object_id": "abc123",
    "last_commit_id": "def456"
  }
}

Import a pipeline from an external Git repo:

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline",
    "pipeline_description": "Imported from GitHub"
  }
}

Import a pipeline from a Harness Code repo:

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline"
  }
}

Create a connector:

{
  "resource_type": "connector",
  "body": { "connector": { "name": "My Docker Hub", "identifier": "my_docker", "type": "DockerRegistry" } }
}

Delete a trigger:

{
  "resource_type": "trigger",
  "resource_id": "nightly-trigger",
  "pipeline_id": "my-pipeline"
}

List input sets for a pipeline:

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline"
}

Get a specific input set:

{
  "resource_type": "input_set",
  "resource_id": "prod-inputs",
  "pipeline_id": "my-pipeline"
}

Create an input set:

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production"
}

Update an input set:

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production\n      - name: replicas\n        type: String\n        value: \"3\""
}

Delete an input set:

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline"
}

Resource Types

219 resource types organized across 38 toolsets. Each resource type supports a subset of CRUD operations and optional execute actions.

Platform

Resource TypeListGetCreateUpdateDeleteExecute Actions
organizationxxxxx
projectxxxxx

Pipelines

Resource TypeListGetCreateUpdateDeleteExecute Actions
pipelinexxxxxrun, retry
pipeline_v1 (Alpha)xxxxxrun
pipeline_dynamic_executionrun
executionxxinterrupt
execution_inputsx
triggerxxxxx
pipeline_summaryx
input_setxxxxx
runtime_input_templatex
approval_instancexapprove, reject

Only one pipeline YAML resource type is loaded at startup. By default HARNESS_PIPELINE_VERSION=0 exposes pipeline and hides pipeline_v1; set HARNESS_PIPELINE_VERSION=1 to expose pipeline_v1 and hide pipeline. In HTTP mode, include x-harness-pipeline-version: 0 or 1 on the initialize request to choose the version for that session.

AI Agents

Resource TypeListGetCreateUpdateDeleteExecute Actions
agentxxxxx
agent_runx

Services

Resource TypeListGetCreateUpdateDeleteExecute Actions
servicexxxxx

Environments

Resource TypeListGetCreateUpdateDeleteExecute Actions
environmentxxxxxmove_configs

Connectors

Resource TypeListGetCreateUpdateDeleteExecute Actions
connectorxxxxxtest_connection
connector_cataloguex

Infrastructure

Resource TypeListGetCreateUpdateDeleteExecute Actions
infrastructurexxxxxmove_configs

Secrets

Resource TypeListGetCreateUpdateDeleteExecute Actions
secretxx

Execution Logs

Resource TypeListGetCreateUpdateDeleteExecute Actions
execution_logx

Audit Trail

Resource TypeListGetCreateUpdateDeleteExecute Actions
audit_eventxx

Delegates

Resource TypeListGetCreateUpdateDeleteExecute Actions
delegatex
delegate_tokenxxxxrevoke, get_delegates

Code Repositories

Resource TypeListGetCreateUpdateDeleteExecute Actions
repositoryxxxx
branchxxxx
commitxxxdiff, diff_stats
file_contentxblame
tagxxx
repo_rulexx
space_rulexx

commit creation commits one or more file actions directly through the Harness Code API without cloning. Pass body.title, body.branch, and body.actions; each action is CREATE, UPDATE, DELETE, or MOVE, and UPDATE requires the current blob SHA.

Artifact Registries

Resource TypeListGetCreateUpdateDeleteExecute Actions
registryxx
artifactx
artifact_versionx
artifact_filex

File Store

Resource TypeListGetCreateUpdateDeleteExecute Actions
file_storexxxxxlist_children

file_store manages Harness File Store files and folders through the generic tools. It supports account, org, and project scope; pass resource_scope="account"|"org"|"project" or paste a Harness File Store URL so the server can derive scope and IDs.

Common calls:

# List the account-level File Store.
harness_list(resource_type="file_store", resource_scope="account")

# Create a folder at the current scope root.
harness_create(resource_type="file_store", body={
  name: "scripts",
  type: "FOLDER",
  parent_identifier: "Root"
})

# Upload a UTF-8 script file. Use content_base64 instead for binary data.
harness_create(resource_type="file_store", body={
  name: "deploy.sh",
  type: "FILE",
  parent_identifier: "Root",
  content: "#!/usr/bin/env bash\n./deploy",
  mime_type: "text/x-shellscript",
  file_usage: "SCRIPT"
})

# Rename metadata without replacing file content.
harness_update(resource_type="file_store", resource_id="deploy_script", body={
  name: "deploy-prod.sh",
  type: "FILE",
  parent_identifier: "Root"
})

# List first-level children of a folder. This is a read-risk execute action.
harness_execute(resource_type="file_store", action="list_children",
  resource_id="scripts_folder", params={folder_name: "scripts"})

Multipart body constraints:

  • Create/update accept JSON body, then convert it to multipart/form-data for /ng/api/file-store.
  • name, type (FILE or FOLDER), and parent_identifier are required; use the literal "Root" only for the root of the selected scope.
  • FILE create requires exactly one of content (UTF-8 string) or content_base64 (valid non-empty base64). FILE update can omit content for metadata-only updates, or provide exactly one content field to replace content.
  • FOLDER create/update must omit content and content_base64.
  • Optional file_usage must be MANIFEST_FILE, CONFIG, or SCRIPT; optional scalar metadata such as description, mime_type, path, and tags must be strings.
  • Upload content is capped at 100 MB. Confirmation prompts redact content, content_base64, and contentBase64 previews before elicitation.

list_children accepts either shorthand (resource_id plus params.folder_name, or params.file_store_id/params.folder_identifier plus params.folder_name) or a full FileStoreNode body with identifier, name, and type: "FOLDER". Full bodies use Harness camelCase parentIdentifier; shorthand may use params.parent_identifier.

Templates

Resource TypeListGetCreateUpdateDeleteExecute Actions
templatexxxxx

Template operations use the Harness Template service paths (/template/api/templates...). Create and update require the full template YAML string in body.template_yaml or body.yaml; version_label targets a specific version for update/delete, while deleting without version_label deletes all versions.

Dashboards

Resource TypeListGetCreateUpdateDeleteExecute Actions
dashboardxx
dashboard_datax

Database DevOps

Resource TypeListGetCreateUpdateDeleteExecute Actions
database_schemaxxxxx
database_instancexxxxx
database_snapshot_objectxx
database_llm_authoring_pipelinex

Infrastructure as Code Management (IaCM)

IaCM resources are default-enabled and mostly project-scoped. Start with iacm_workspace to find workspace identifiers, then use that workspace_id for workspace resources, costs, and activity diffs. The module registry is account-scoped.

Resource TypeListGetCreateUpdateDeleteExecute Actions
iacm_workspacexx
iacm_resourcex
iacm_modulexx
iacm_workspace_costsx
iacm_activity_resource_changex

Typical workflow:

  1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") to find the workspace.
  2. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") to inspect Terraform resources, outputs, and data sources.
  3. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") to review per-execution cost entries.
  4. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") to inspect before/after resource diffs for a plan, apply, or destroy activity.

IaCM list responses expose page_count as the count for the current page only. When has_more is true, keep requesting the next 1-based page and sum page counts if you need a total.

Internal Developer Portal (IDP)

Resource TypeListGetCreateUpdateDeleteExecute Actions
idp_entityxx
scorecardxx
scorecard_checkxx
scorecard_statsx
scorecard_check_statsx
idp_scorexx
idp_workflowxexecute
idp_tech_docx

Pull Requests

Resource TypeListGetCreateUpdateDeleteExecute Actions
pull_requestxxxxclose, merge
pr_reviewerxxsubmit_review
pr_commentxx
pr_checkx
pr_activityx

Use harness_execute(resource_type="pull_request", action="close", ...) for an explicit close operation. harness_update also accepts body.state (open or closed) and routes state changes to the dedicated Harness Code PR state endpoint; send title/description edits in a separate update call.

Feature Flags

Resource TypeListGetCreateUpdateDeleteExecute Actions
fme_workspacex
fme_environmentx
fme_feature_flagxxxxxkill, restore, archive, unarchive
fme_feature_flag_definitionxxx
fme_rollout_statusx
fme_rule_based_segmentxxxx
fme_rule_based_segment_definitionxxenable, disable, change_request
fme_traffic_typex
fme_identityxx
fme_standard_segmentxx
fme_segment_keysxx

FME (Split.io) resources — fme_* resources use the Split.io API (api.split.io) and are scoped by workspace ID rather than org/project. In single-user/self-hosted mode, auth uses a Bearer token from HARNESS_FME_API_KEY, falling back to a non-placeholder HARNESS_API_KEY. HARNESS_FME_API_KEY may be a legacy Split admin key or an FME-entitled Harness PAT/SAT, but it is rejected in multi-user mode so shared deployments cannot override each session user's credential. Hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate direct Split.io requests. fme_feature_flag supports full lifecycle management: create (requires traffic_type_id), list, get, update metadata, delete, and kill/restore/archive/unarchive execute actions. Use fme_traffic_type to discover traffic type IDs, fme_identity to create/update identity attributes, and fme_standard_segment / fme_segment_keys to inspect standard segments and add member keys. fme_rule_based_segment provides CRUD for targeting segments, while fme_rule_based_segment_definition manages environment-specific segment rules with enable/disable and change request approval flows.

GitOps

Resource TypeListGetCreateUpdateDeleteExecute Actions
gitops_agentxx
gitops_applicationxxsync
gitops_clusterxx
gitops_repositoryxx
gitops_applicationsetxx
gitops_repo_credentialxx
gitops_app_eventx
gitops_pod_logx
gitops_managed_resourcex
gitops_resource_actionx
gitops_dashboardx
gitops_app_resource_treex

Chaos Engineering

Resource TypeListGetCreateUpdateDeleteExecute Actions
chaos_experimentxxxxrun, stop
chaos_experiment_runx
chaos_experiment_variablex
chaos_component_variablex
chaos_input_setxxxxx
chaos_experiment_templatexxxcreate_from_template
chaos_probexxxxenable, verify
chaos_probe_in_runx
chaos_probe_templatexxx
chaos_infrastructurex
chaos_k8s_infrastructurexxcheck_health
chaos_environmentx
chaos_hubxxxxx
chaos_hub_faultx
chaos_faultxxx
chaos_fault_templatexxx
chaos_fault_experiment_runx
chaos_actionxxx
chaos_action_templatexxx
chaos_loadtestxxxxrun, stop
chaos_application_mapxx
discovered_namespacex
discovered_servicex
discovered_network_mapx
chaos_guard_conditionxxx
chaos_guard_rulexxxenable
chaos_recommendationxx
chaos_riskxx
chaos_dr_testxx

Cloud Cost Management (CCM)

Resource TypeListGetCreateUpdateDeleteExecute Actions
cost_perspectivexxxxx
cost_breakdownx
cost_timeseriesx