Skip to main content
Glama
harness

Harness MCP Server

Official
by harness
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

harness_schema

Read-only

Fetch Harness YAML schemas, field summaries, or example snippets for pipelines, templates, connectors, and other resource types to validate configuration before creating or updating entities.

Instructions

Fetch Harness YAML schema or examples for a resource type. Pipeline/template schemas are bundled from harness-schema; connector, environment, service, secret, and infrastructure schemas are fetched live from NG /yaml-schema (pass scope, org_id, project_id). release_process and release_activity schemas are fetched live from /gateway/rmg/api/yamlSchema. Use without path for a summary of fields and available sections. Use with path to drill into a specific section. Use with example to fetch a named example YAML snippet. Use with example_search to find examples by keyword. Precedence: example > example_search > path > summary. Available schemas: pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, agent-pipeline, connector, environment, service, secret, infrastructure, release_process, release_activity.

Input Schema

NameRequiredDescriptionDefault
pathNoDot-separated path to drill into a specific definition section. Omit for a top-level summary showing all available sections.
scopeNoHarness YAML scope for live entity schemas (connector, environment, service, secret, infrastructure, release_process, release_activity). Defaults to account. Org/project scoped entities require org_id and/or project_id.
org_idNoOrganization identifier — required when scope is org or project (live entity schemas).
exampleNoFetch a specific example by name (e.g. 'minimal-ci'). Returns the full YAML snippet and description.
identifierNoOptional entity identifier for NG yaml-schema. Use when updating an existing entity to fetch an entity-specific schema. Omit for generic create-time schemas — a placeholder identifier is sent automatically for all live entity types at any scope.
project_idNoProject identifier — required when scope is project (live entity schemas).
resource_typeNoSchema to fetch. Required for schema/path lookups, optional for example_search. Valid values are listed in the tool description.
example_searchNoSearch examples by keyword. Returns matching example names and descriptions. Optionally combine with resource_type to filter.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.2.35
    • changedInput schema / properties / resource_type / description
      Previous value: -"Schema to fetch. Available: pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, agent-pipeline, connector, environment, service, secret, infrastructure, release_process, release_activity. Required for schema/path lookups, optional for example_search."New value: +"Schema to fetch. Required for schema/path lookups, optional for example_search. Valid values are listed in the tool description."
    • removedOutput schema / description
      Removed value: -"Schema data — shape varies by query mode"
  2. Changed3 schema fields changedv3.2.21
    • changedInput schema / properties / resource_type / description
      Previous value: -"Schema to fetch. Available: pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, agent-pipeline, connector, environment, service, secret, infrastructure. Required for schema/path lookups, optional for example_search."New value: +"Schema to fetch. Available: pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, agent-pipeline, connector, environment, service, secret, infrastructure, release_process, release_activity. Required for schema/path lookups, optional for example_search."
    • changedInput schema / properties / resource_type / enum
      Previous value: -[
-  "pipeline",
-  "template",
-  "trigger",
-  "pipeline_v1",
-  "template_v1",
-  "inputSet_v1",
-  "overlayInputSet_v1",
-  "agent-pipeline",
-  "connector",
-  "environment",
-  "service",
-  "secret",
-  "infrastructure"
-]New value: +[
+  "pipeline",
+  "template",
+  "trigger",
+  "pipeline_v1",
+  "template_v1",
+  "inputSet_v1",
+  "overlayInputSet_v1",
+  "agent-pipeline",
+  "connector",
+  "environment",
+  "service",
+  "secret",
+  "infrastructure",
+  "release_process",
+  "release_activity"
+]
    • changedInput schema / properties / scope / description
      Previous value: -"Harness YAML scope for live entity schemas (connector, environment, service, secret, infrastructure). Defaults to account. Org/project scoped entities require org_id and/or project_id."New value: +"Harness YAML scope for live entity schemas (connector, environment, service, secret, infrastructure, release_process, release_activity). Defaults to account. Org/project scoped entities require org_id and/or project_id."
  3. Changed1 schema field changedv3.2.16
    • addedInput schema / properties / identifier
      Added value: +{
+  "description": "Optional entity identifier for NG yaml-schema. Use when updating an existing entity to fetch an entity-specific schema. Omit for generic create-time schemas — a placeholder identifier is sent automatically for all live entity types at any scope.",
+  "type": "string"
+}
  4. First observedv3.2.10

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/non-destructive, so the bar is lower, yet the description still adds real behavior: which resource types hit live endpoints (NG /yaml-schema, /gateway/rmg/api/yamlSchema) and that those require scope/org_id/project_id. It does not describe failure modes (bad path, unknown example name, missing scope) or response shape beyond 'summary of fields'.

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?

Front-loaded purpose followed by mode sentences and a precedence rule, so an agent can stop reading early if it just wants the summary mode. It is dense and the trailing 'Available schemas' list duplicates the enum in the schema, which is the main 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 8 optional parameters, an output schema, and full schema coverage, the description covers the mode-selection model and the provenance split well enough to call correctly. Minor gaps: no guidance on what happens when a path or example name is invalid, and no hint about response size for large schemas.

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 baseline is 3; the description still adds cross-parameter logic the schema cannot express well — that live entity schemas take scope/org_id/project_id, and the precedence between example, example_search, path, and summary. It does repeat the resource_type enum rather than adding detail about each type.

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 first sentence gives a specific verb and resource: fetch Harness YAML schema or examples for a resource type. It also splits the resource space by provenance (bundled vs live-fetched endpoints), which no sibling tool does, making it unmistakable against harness_get/harness_list/harness_describe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit mode selection: no path = summary, path = drill in, example = named snippet, example_search = keyword lookup, plus a stated precedence order (example > example_search > path > summary). This is exactly the kind of routing an agent needs when several optional parameters can be combined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools