Harness MCP Server

Official

by harness

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.2.21
Disambiguation4/5
Most tools target clearly distinct operations such as create, update, delete, get, execute, diagnose, and status. The closest pairs are list vs. search and describe vs. schema, but their descriptions provide enough distinguishing cues to avoid serious confusion.
Naming Consistency4/5
All tools share the harness_ prefix and use snake_case, which is predictable and consistent. The naming is slightly inconsistent at the pattern level because most names are bare verbs like harness_create while harness_status and harness_schema are nouns rather than verb_noun forms.
Tool Count5/5
With 11 tools, the server is well-scoped for a broad platform like Harness: lifecycle operations, search, schema discovery, execution, diagnosis, and health status each have a dedicated tool. There is no obvious redundancy or bloat.
Completeness5/5
The tool surface covers the full resource lifecycle with create, update, delete, get, and list, plus discovery via describe and schema, execution via execute, and operational insight via diagnose and status. This provides excellent coverage with no obvious dead ends for typical Harness management workflows.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 16 of 19 community issues answered or closed in the last 6 months
- 207 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail (relevance ranking, multi-type scope, URL-based scope), but says nothing about result grouping, pagination, or scope precedence. It does not contradict 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?
Three short sentences with no filler; the main action is front-loaded. One minor redundancy with the title ('Search Harness Resources') costs a point, but the relevance and scope statements earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is rich (8 params, 100% coverage), an output schema exists, and annotations cover read-only safety, so the description does not need to document parameters or return values. However, it is incomplete on tool-selection context: an agent cannot confidently decide between harness_search and harness_list without additional reasoning. This is the main gap.
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 the baseline is 3. The description adds meaning beyond the schema by identifying url as a scope-defining input and framing resource_types as the 'multiple resource types' being searched. This helps an agent understand parameter intent without reading every enum value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Search'), a broad but concrete resource ('multiple Harness resource types'), and a distinctive behavior ('Returns results ranked by relevance'). This is clear enough to differentiate from harness_get or harness_describe, though it does not explicitly call out sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose harness_search over harness_list, harness_get, or harness_describe. The description implies cross-type search but never states a decision rule, such as 'use when the type or ID is unknown' or 'use harness_list to enumerate a single type.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so there is no contradiction. The description adds that scope can be auto-extracted from a Harness URL and that results support filtering/pagination, which is useful but modest; it does not describe edge cases like per-resource page-size limits (present only in the schema) or response shape. With annotations covering the safety profile, this is adequate but not enriched.
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?
Two short sentences, front-loading the core action ('List Harness resources') before the URL auto-extraction note. Every sentence contributes; no filler or redundancy. It is appropriately concise for a tool whose parameter detail lives in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a large-surface list tool (11 params, ~150 resource types, nested params), the description alone is minimal. However, the input schema provides rich per-parameter guidance and an output schema exists, so nothing critical about return format or parameter behavior is missing from the overall definition. The main gap is selection guidance relative to harness_search/harness_get, which keeps this from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all 11 parameters and carries most semantic weight. The description's filtering/pagination/URL statements echo the url, filters, page, and size parameters without adding new meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') with a clear resource family ('Harness resources') and names two core behaviors (filtering, pagination). It is not a tautology and is distinguishable from siblings like harness_get (single fetch) and harness_search by the 'list' scope, though it does not explicitly name those distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative routing appears in the description. It states capabilities (filtering, pagination, URL auto-extraction) but never tells an agent to prefer this over harness_search or harness_get, nor excludes cases where it should not be used. The only exclusions/alternatives live inside parameter descriptions (e.g., call harness_describe), not in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. The description adds context about auto-detection from URLs and defaulting to pipeline diagnosis. The extensive options parameter description further details behavioral traits like log fetching in batches and capping, enhancing transparency.
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 main description is two sentences with no wasted words, front-loading the purpose. The options parameter description is detailed but necessary given the tool's complexity. Overall, the structure is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, multiple resource types) and that an output schema exists, the description is fairly complete. It covers high-level use cases and the options parameter fleshes out details. The description could be slightly more explicit about all supported resource types, but it adequately serves its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The main description adds the default resource type behavior (pipeline) which is not explicit in the schema, and the options parameter description provides detailed semantics for various scenarios. However, the main description does not add significant meaning beyond what the schema already provides for most parameters.
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 the tool diagnoses Harness resources, specifying actions like analyzing failures, testing connectivity, checking health, and troubleshooting GitOps sync. It distinguishes from siblings by focusing on diagnostic actions rather than listing, getting, or modifying resources. The default to pipeline execution diagnosis and auto-detection from URL further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for troubleshooting and diagnosis, and mentions defaults to pipeline execution. It also references calling harness_describe for details within the options parameter. However, it lacks explicit guidance on when to use this tool versus other siblings like harness_get or harness_execute, and does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that the operation is not read-only and may be destructive, so the description does not need to restate that. It adds some behavioral value by describing YAML-versus-object body handling, URL-based identifier extraction, and the openInHarness response link, but it does not clarify overwrite/merge semantics, permissions, or confirmation prerequisites beyond what the schema already covers.
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?
Three concise sentences, each carrying distinct information: the operation, body encoding for special cases, and URL/response behavior. The core action is front-loaded, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, an output schema, and annotations covering the destructive/mutating nature, the description covers the key decision-relevant nuances for most update calls. It could be more complete with explicit create-vs-update routing or a warning about overwriting, but those are partly inferable from the sibling names and schema.
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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining how to encode the body for pipelines/input sets with direct YAML recommended for complex definitions and by highlighting the URL shortcut for identifier extraction. This goes beyond the schema's type-level 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 states a clear action ('Update an existing Harness resource') with a specific resource scope, and the word 'existing' distinguishes it from creation or deletion tools. It also provides targeted detail for pipelines/input sets, reinforcing what the tool operates on and how.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing resource' implies this tool is for modifying already-created resources rather than creating new ones, and the body-format guidance gives practical invocation context. However, it does not explicitly state when to prefer harness_create, harness_delete, or other siblings, leaving alternative routing mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral trait beyond annotations: the ability to pass a Harness URL that auto-extracts identifiers. It does not describe response/error behavior, but the output schema and annotations reduce the burden.
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?
Two sentences with no filler. The first sentence front-loads the core operation and target, the second adds a valuable routing cue for failure analysis. Every word earns its place.
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 read-only annotations, the presence of an output schema, and a fully self-documenting input schema with high coverage, the description does not need to enumerate parameters. It supplies the missing routing guidance and the URL shortcut, making it complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's URL auto-extraction point is already present in the url parameter description, and it introduces no new parameter semantics beyond clarifying the get-by-ID entry path. The schema carries the heavy lifting.
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 states a specific verb ('Get') and resource ('a Harness resource') with an explicit selection criterion ('by ID'), clearly distinguishing this from create/update/delete/list/search siblings. It also points to harness_diagnose for failure analysis, further separating concerns.
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 explicitly directs failure-analysis use cases to harness_diagnose, providing a valuable when-not-to-use signal. It does not fully enumerate alternatives like harness_list or harness_search, but 'by ID' conveys the intended fetch-a-single-resource use case well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a non-read-only, non-destructive, non-idempotent operation, and the description does not contradict that. It adds useful workflow context around body format and remote git parameters, but it does not disclose runtime behavior such as whether existing resources are overwritten, confirmation requirements, or error semantics beyond what the schema already covers.
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 front-loaded with the core purpose, then delivers the most important conditional guidance in a compact, well-organized form. Every sentence earns its place, and the use of colon-separated cases keeps the branching logic readable without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large resource_type enum and nested body/params structures, the description is reasonably complete: it covers the main problem cases (pipelines/input sets and remote pipelines) and routes users to harness_describe for other resource formats. The input schema covers the remaining parameters at 100% description coverage, and an output schema exists, so missing return-value details are acceptable.
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 the baseline is 3. The description adds meaningful semantics by recommending a direct YAML string for complex pipelines, explaining the body.yamlPipeline and body.pipeline alternatives, and enumerating the exact keys needed for remote Git and Harness Code pipelines. This goes beyond the schema's generic parameter 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-resource statement, 'Create a Harness resource,' and immediately distinguishes creation from the sibling tools like harness_update, harness_delete, and harness_execute. It also elaborates on which resource types have special handling, making the tool's scope unambiguous.
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 gives clear usage guidance for pipelines/input sets and remote pipelines, including when to pass a YAML string versus a JSON object and which git parameters to include. It directs users to harness_describe for other resource body formats, though it does not explicitly state when to prefer update/delete over create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context beyond those flags: the operation 'cannot be undone,' and it discloses the URL auto-extraction behavior. This meaningfully complements the structured annotations without contradicting them.
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 two sentences with no filler. It front-loads the core action, then the convenience feature, then the critical warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, annotations, and presence of an output schema, the description covers what an agent needs to orient: what the tool does, how to simplify input via URL, and that the operation is permanent. The confirm parameter nuance is left to the schema, which is acceptable since the schema documents it thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter schema already documents all fields thoroughly. The description's mention of passing a URL to auto-extract identifiers largely restates what the url parameter description already says. Thus the description adds little parameter-level meaning beyond the schema.
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 and resource: 'Delete a Harness resource.' This clearly distinguishes it from siblings like harness_create, harness_update, and harness_search. It also adds a useful capability (URL-based identifier extraction), making the tool's purpose unambiguous.
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 tool's purpose—deleting a Harness resource—is stated explicitly enough that an agent knows when to select it. The warning 'This is destructive and cannot be undone' provides clear contextual guidance to exercise care. It does not reference alternatives, but no exclusions or alternative routing are needed for a delete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds a valuable behavioral fact beyond them: 'No API call — returns local metadata only.' This tells the agent the operation is offline, instant, and requires no credentials or rate-limit consideration. No contradiction with annotations exists.
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?
Three sentences with zero waste: purpose is front-loaded first, the critical no-API-call differentiator second, and usage guidance third. Every sentence earns its place and the ordering supports quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only discovery tool, the picture is nearly complete: annotations cover safety, output schema covers return values, the schema covers parameter semantics, and the description covers purpose, behavior, and usage context. The only notable gap is not clarifying how this tool relates to harness_schema, a sibling that could plausibly serve a similar discovery role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters, including informative details like search_term 'matches type name, display name, toolset, description' and large enums for toolset and resource_type. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.
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 states a specific verb and resource: 'Describe available Harness resource types, their supported operations, and fields.' It also differentiates from siblings by declaring 'No API call — returns local metadata only,' which clearly separates it from harness_get, harness_list, and harness_search that fetch live platform data.
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 gives clear when-to-use context: 'Use this to discover what resource_types you can use with other harness_ tools.' The 'No API call' phrase further signals that live-data fetches belong elsewhere. However, it never names alternatives explicitly and does not delineate the boundary with the conceptually overlapping sibling harness_schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds behavioral context: the tool returns a live overview and can auto-extract org/project from a URL. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the tool's purpose and deliverables; the second adds a usage hint and practical use case. No wasted words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, 100% schema coverage, and existence of an output schema, the description adequately covers the tool's role as a health overview. It could optionally mention the output structure, but that is handled by the output schema. The description is complete for its context.
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 coverage is 100% with each parameter described. The description adds value by explaining the URL parameter's auto-extraction behavior and the override semantics for org_id/project_id, beyond what the schema provides. Baseline 3 with additional insight justifies a 4.
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 uses the specific verb 'Get' and resource 'live project health overview', detailing exactly what is returned (failed executions, running executions, deployment activity). It distinguishes from siblings like harness_get or harness_list by focusing on a health overview, and provides an ideal first question for context.
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 explicitly states the ideal use case ('what's happening in my project right now?'), implying this is the go-to for quick status checks. However, it does not provide explicit when-not-to-use guidance or direct alternatives among siblings, but the context signals and sibling names offer implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false), the description discloses concrete behavior: killing/restoring feature flags (what can be destroyed), server-side blocking wait until terminal status, URL-based auto-extraction of identifiers, and parallel HQL batch execution. The parameter-level text reinforces this with a risk/confirm model ('required when the action's risk is medium_write or above'), confirmation semantics ('Does NOT override an explicit decline'), and timeout behavior ('returns execution_timed_out=true with the last observed status'). No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all high-signal: purpose with action examples, the URL shortcut, the wait-until-terminal pattern, and the HQL special case. The broadest statement is front-loaded, followed by the two highest-value invocation tips. No filler, no restatement of schema content — appropriately compact for a tool with 16 parameters and a 60+ value resource_type enum.
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?
For a highly complex tool (16 params, large enums, nested objects, output schema present), the definition is complete: return values are covered by the output schema, the safety profile by annotations, parameter semantics by 100% schema coverage, and the non-obvious invocation patterns (wait, HQL batch, URL extraction) by the description. The pointer to harness_describe for action-specific fields closes the otherwise unbounded action/resource-type matrix.
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 coverage is 100% and each parameter description is already rich (defaults, min/max, sibling references, 'Ignored for other actions'), so the baseline is 3. The main description adds value by encoding cross-parameter dependencies that prevent mis-invocation: wait only applies to pipeline run/retry, queries is only valid with resource_type='hql_query' AND action='validate' or 'run', and URL auto-extracts identifiers across the resource_type/org/project/id fields. These rules exist in the schema but are scattered; the description synthesizes them into callable patterns.
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?
States a specific action verb and resource — 'Execute an action on a Harness resource' — and grounds it with concrete examples: run/retry/interrupt pipelines, kill/restore FME feature flags, test connectors, sync GitOps apps, run chaos experiments. These action verbs clearly differentiate it from CRUD siblings (harness_create/update/delete) and read siblings (harness_get/list/search), so an agent can route to it without opening schemas.
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?
Gives explicit when-to-use conditions in the main prose: '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' and 'For HQL batch operations pass queries with resource_type="hql_query" and action="validate" or "run"'. Prerequisite routing to siblings is embedded in parameter descriptions ('Check runtime_input_template first via harness_get', 'Call harness_describe for available fields', 'List available: harness_list'). However, it never explicitly excludes CRUD operations — the boundary with harness_create/update/delete is implied by the action examples but never stated as a when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral detail beyond that: bundled vs live-fetched schema sources, the requirement for scope/org_id/project_id on live entities, and the automatic placeholder identifier behavior. The precedence behavior is also disclosed. This gives an agent an accurate model of how the tool behaves.
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 dense but well organized, moving from the core purpose to usage modes to precedence to the available schema list. Almost every sentence earns its place. The final 'Available schemas' list duplicates the resource_type enum, which is minor redundancy, but the description remains efficient and scannable.
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?
For a tool with 8 parameters, multiple source backends, and several operation modes, the description is remarkably complete. It covers all parameter combinations, precedence, scope constraints, and the distinction between bundled and live schemas. The presence of an output schema reduces the need to describe return values, and nothing critical is left ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all parameters at 100% coverage, the description adds substantial semantic value beyond the schema. It explains how path, example, and example_search interact, when scope/org_id/project_id are required, and how identifier behaves for create-time vs update-time lookups. This transforms a list of parameters into an actionable decision procedure.
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 and resource: 'Fetch Harness YAML schema or examples for a resource type.' It clearly distinguishes this tool from the create/update/delete/get/search siblings by focusing solely on schema and example retrieval. The supported resource types and operation modes are enumerated.
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 gives concrete usage guidance: use without path for a summary, use with path to drill in, use with example for named snippets, and use with example_search for keyword exploration. It also states the precedence order example > example_search > path > summary. However, it does not explicitly say when NOT to use this tool versus alternatives like harness_get or harness_describe, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/harness/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/harness/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/harness/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/harness/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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