| FMRS | 63 / 100 · C | 79 / 100 · B |
|---|
| Reliability | 8 / 20 | 12 / 20 |
|---|
| Security and permissions | 15 / 20 | 18 / 20 |
|---|
| Maintenance | 10 / 20 | 16 / 20 |
|---|
| Documentation | 17 / 20 | 18 / 20 |
|---|
| Setup experience | 13 / 20 | 15 / 20 |
|---|
| Best for | - Teams already using the Harness platform for CI/CD, GitOps, or Feature Flags management
- Automated workflows that need to dynamically discover organizations/projects rather than hardcode configuration
- Enterprises wanting centralized governance and audit logging via MCP gateways (Docker MCP Gateway, Portkey, LiteLLM, etc.)
| - Engineering teams scaling AI coding agents while controlling spend
- Platform teams that need auditable, rollback-aware agent execution records
- Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
|
|---|
| Not for | - Teams not using the Harness platform
- Use cases that require one tool per API endpoint with fine-grained per-tool permission control
- Accounts without a Harness API key or without Harness Support enabling the hosted MCP service
| - Developers who just want a simple code-completion helper without run governance
- Teams unwilling to accept local JSONL run records with HMAC signing
- Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
|
|---|
| Required permissions | - Requires a Harness personal access token (PAT) or service account token (SAT); the account ID is typically auto-extracted from the token
- Has read-write access (create/update/delete/execute) by default; can be restricted to read-only with HARNESS_READ_ONLY=true
- In multi-user HTTP mode, each session supplies its own x-harness-api-key — the server itself holds no credentials
| - Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
- Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
- Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
- Execution of user-configured verifier commands (e.g. npm test)
|
|---|
| Risks and side effects | - Mutating operations (create, update, delete, execute) can directly modify production pipelines, feature flags, or infrastructure configuration, so misuse can cause outages
- Running HTTP transport on a non-loopback bind without HARNESS_MCP_AUTH_TOKEN can expose the server to unauthorized access; HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true explicitly disables that protection
- Audit logging omits raw request/response bodies by default, but HARNESS_LOG_UNSAFE_BODIES can enable them, which may then contain secrets
| - Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
- Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
- Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
- Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
|
|---|
| Supported clients | Claude Desktop, Claude Code, Cursor, Devin Desktop | Claude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue |
|---|
| Tools | 11 | 0 |
|---|