Harness
Harness Core CD APIs for managing pipelines, executions, services, environments, infrastructure, input sets, triggers, and templates.
Verdict
Common use cases
- Check pipeline status during daily standup
- Audit failed deployments from last sprint
- List active environments before a release
- Find which services use a specific template
- Track execution history for compliance reports
Integration
- Vendor
- Harness
- Category
- developer-tools
- Auth
- API_KEY
- Tools
- 7
- Composio slug
harness
Tools
- List Environments
List one page of environments in a Harness project, optionally filtered by identifiers or search text.
- List Organizations
List one page of Harness organizations accessible to the connected account, optionally filtered by identifier or search text.
- List Pipeline Executions
List one page of pipeline executions in a Harness project, optionally filtered by pipeline, status, search text, or current-user ownership.
- List Pipelines
List one page of pipelines in a Harness project, optionally filtered by search text or Git branch.
- List Projects
List one page of Harness projects accessible to the connected account, optionally within an organization or filtered by module and search text.
- List Services
List one page of services in a Harness project, optionally filtered by identifiers, deployment type, tags, storage, GitOps state, or search text.
- List Templates
List one page of account-scoped Harness templates, optionally filtered by template state, entity or child type, identifier, name, description, or search text.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations tab. 2. Find Harness in the MCP directory and click Connect. 3. In Harness, go to your profile settings, generate a new API key, and copy it. 4. Paste the API key into Switchy's connection dialog and save. 5. Return to any Project in Switchy and type '@Harness list projects' in the chat to confirm the connection works. 6. If you see your Harness projects listed, the integration is live. 7. To query a specific project's pipelines or environments, first note the project identifier from the list, then use '@Harness list pipelines' with that identifier in your prompt. 8. Grant the API key read-only access to avoid accidental changes; the MCP only retrieves data, never modifies it.
What teammates see: by default, memories from Harness are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Pipeline Health Check
@Harness list the last 20 pipeline executions in project 'backend-api' and show me any that failed in the past 48 hours.
Environment Snapshot
@Harness list all environments in project 'mobile-app' and tell me which ones are marked as production.
Service Deployment Audit
@Harness list all services in project 'platform-core' and group them by deployment type.
Template Usage Review
@Harness search templates with 'kubernetes' in the name and show me the five most recently updated.
Cross-Project Pipeline Summary
@Harness list all projects in the 'engineering' organization, then for each project show me the total number of pipelines.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@harness show me all failed pipeline executions in the mobile-app project from the last week
Found 4 failed pipeline executions in mobile-app: 1. ios-release-pipeline (exec-7x9k2) - Failed at Deploy stage, 2 hours ago 2. android-build-pipeline (exec-8m1p5) - Failed at Test stage, 1 day ago 3. ios-release-pipeline (exec-6n4j8) - Failed at Build stage, 3 days ago 4. integration-test-pipeline (exec-5k7m3) - Failed at Integration stage, 5 days ago All executions are accessible in your Harness dashboard. The most recent failure (ios-release-pipeline) shows a deployment timeout error.
This read-heavy example demonstrates filtering pipeline executions by status. The MCP returns one page of results (default 50 items); if your project has more failures, you'll need to handle pagination. Requires read access to the specified project and its pipeline execution history.
@harness list all services tagged 'critical' across our production environments and show their deployment types
Found 6 critical services across production environments: 1. payment-gateway (Kubernetes) - prod-us-east 2. auth-service (Kubernetes) - prod-us-west 3. user-api (ECS) - prod-eu-central 4. notification-worker (Kubernetes) - prod-us-east 5. billing-processor (Lambda) - prod-us-west 6. analytics-stream (Kubernetes) - prod-apac All services are currently deployed and monitored. The payment-gateway and auth-service share the same cluster in different regions.
This example combines service listing with environment context, showing how the MCP handles tag-based filtering. The response is illustrative—actual service metadata varies by your Harness configuration. Useful for inventory audits, but remember this is a snapshot; real-time deployment status requires additional pipeline execution queries.
@harness summarize the deployment patterns from our last 20 pipeline runs—which services deploy most frequently and what's the success rate?
Analyzing the last 20 pipeline executions: Most frequent deployments: - user-api: 7 runs (85% success, 1 failed, 1 aborted) - notification-worker: 5 runs (100% success) - payment-gateway: 4 runs (75% success, 1 failed) - auth-service: 4 runs (100% success) Overall success rate: 85% (17 successful, 2 failed, 1 aborted). The user-api shows the highest activity but also accounts for both failures. Failed runs occurred during off-peak hours, suggesting possible infrastructure contention or test environment issues.
This synthesis example shows the AI reasoning over Harness data to identify deployment trends. The MCP provides raw execution lists; the AI performs the frequency analysis and success-rate calculation. Requires pagination awareness if your actual run count exceeds one page, and assumes the AI has context about which pipelines deploy which services.
Use-case deep-dives
When this MCP wins for tracing deployment failures across teams
A 12-person engineering org just had a prod outage traced to a bad deploy. The on-call engineer needs to answer: which pipeline ran, who triggered it, what service version shipped, and which environment config was live. The Harness MCP pulls pipeline executions filtered by status and time window, then cross-references the service and environment lists to build a timeline in one Switchy thread. This beats toggling between Harness tabs or Slacking the platform team. The trade-off: if your org has 40+ projects, the pagination cap (one page per call) means you'll miss executions outside the first page. For incident response at 2-15 project scale, this MCP closes the loop in under two minutes.
When this MCP falls short for cross-project rollup metrics
A VP of Engineering wants a weekly summary: total pipeline runs, success rate by project, and which services shipped to prod. The Harness MCP can list executions and projects, but each call returns one page with no aggregation. Building the rollup means chaining 10+ tool calls and doing the math in-thread. If you have fewer than 5 projects and run under 50 pipelines a week, this works—Switchy can script the loop and format the table. Beyond that threshold, the pagination overhead makes this a poor fit. For small-scale velocity tracking, the MCP delivers. For org-wide dashboards, you need Harness's native analytics or a BI tool hitting their API directly.
When this MCP speeds up platform topology discovery
A new SRE joins a 6-person platform team and needs to map the deployment landscape: which projects exist, what services run in each, which environments are live, and which pipelines are GitOps-enabled. The Harness MCP lists organizations, projects, services, and environments in a single Switchy session, filtered by search text or tags. The SRE asks follow-up questions—'show me all services tagged staging-only'—and gets answers without waiting on a team wiki or a Zoom walkthrough. The limit: templates and pipeline definitions aren't fully exposed, so understanding complex workflows still requires Harness UI access. For day-one topology orientation, this MCP cuts onboarding time from hours to 20 minutes.
Frequently asked
What does the Harness MCP let me do in Switchy?
It connects your Harness account so AI can read your CI/CD setup — list pipelines, check execution status, browse environments and services across projects. Think of it as giving the AI read-only visibility into your deployment infrastructure. You can ask questions like 'which pipelines failed today' or 'show me all services in the payments project' without opening Harness.
Do I need admin access to connect Harness via API key?
Not necessarily. You need a Harness API key with read permissions for the resources you want to query — pipelines, projects, environments, services. If your key only has project-level access, the MCP will only see those projects. Check with your Harness admin about which scopes your key includes before connecting.
Can the Harness MCP trigger pipeline runs or modify deployments?
No. This integration is read-only. It can list pipelines and check execution history, but it can't start builds, approve stages, or change environment configs. If you need to trigger deployments from Switchy, you'll need to use Harness webhooks or their REST API directly outside the MCP.
Why use this instead of just opening the Harness dashboard?
Speed and context. The AI can pull pipeline status, compare execution times, or find services matching certain tags without you clicking through Harness's UI. It's faster for ad-hoc questions during incidents or standups. For deep pipeline debugging or editing YAML, you still want the full Harness interface.
Should our DevOps lead or individual developers connect this?
Whoever needs to answer deployment questions in Switchy. If your whole team uses the workspace to check build status or troubleshoot environments, each person can connect their own Harness API key. The MCP will only surface what their key has access to, so permissions stay consistent with your Harness setup.