Server Quality Checklist

Tool Scores

• harness_updateA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate idempotent and non-destructive. The description adds context about URL extraction and response link, but does not disclose error handling, partial vs full update, or authentication needs.

  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 concisely convey purpose and key features. No redundancy. The most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 7 parameters and no output schema, the description omits critical details: update mode, response structure beyond the link, and error behaviors. The tool is complex but the description is minimal.

  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 each parameter is already documented. The description adds value by explaining the 'url' parameter's auto-extraction behavior, but does not clarify semantics for other parameters 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 clearly states the verb 'Update' and the resource 'existing Harness resource'. It differentiates from sibling tools like harness_create and harness_delete by specifying 'update'.

  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 usage for updating existing resources but does not explicitly state when to use versus alternatives like harness_create for new resources. No exclusion criteria or context is provided.

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

• harness_deleteA
  3.7/5.0
  Behavior4/5

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

  The description adds 'this is destructive and cannot be undone' beyond the destructiveHint annotation. It also discloses URL extraction behavior. No contradiction with annotations (idempotentHint is compatible).

  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, front-loaded with the core purpose, and contains no irrelevant details. Every sentence earns its 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?

  Given the tool has 6 parameters (including nested object) and no output schema, the description is adequate but not thorough. It covers key behavioral aspects but lacks detail on param interactions and error handling. Schema descriptions compensate partially.

  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 baseline is 3. The description does not add significant semantic information beyond the schema, except for mentioning URL auto-extraction which maps to the url parameter.

  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?

  The description clearly states 'Delete a Harness resource' with specific verb and resource. It also mentions URL auto-extraction. While it doesn't explicitly distinguish from sibling tools like harness_update or harness_create, the name and purpose are unmistakable.

  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 when to use (when deletion is needed) but provides no explicit guidance on when not to use or alternatives. The URL extraction hint is useful but does not replace formal usage guidelines.

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

• harness_listA
  3.9/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: URL auto-extraction and filtering/pagination. With readOnlyHint=true, it correctly indicates no side effects. It discloses important traits but could mention rate limits or permission requirements.

  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 extremely concise with two sentences covering the core functionality and a key behavioral trait (URL auto-extraction). Every word earns its place; no redundancy.

  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?

  Given the complexity (12 parameters, nested objects, many siblings) and no output schema, the description is adequate but not thorough. It lacks explanation of the params and filters objects, or how URL extraction interacts with other parameters. Schema covers details, but the tool description could provide more high-level context.

  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 tool description adds minimal value for parameter semantics. The schema already documents each parameter well, including the URL auto-detection hint. Baseline 3 is appropriate.

  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 'List Harness resources with filtering and pagination', specifying the verb (list), the resource (Harness resources), and key features (filtering, pagination, URL auto-extraction). It distinguishes from sibling tools like harness_get (single resource) and harness_search (different search behavior).

  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 usage for listing multiple resources but does not explicitly state when to use this tool versus alternatives like harness_get or harness_search. No when-not-to or exclusion criteria are provided, leaving some ambiguity.

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

• harness_executeA
  4/5.0
  Behavior2/5

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

  Annotations claim destructiveHint=false, but the description lists potentially destructive actions like 'kill/restore FME feature flags' and 'interrupt pipelines', creating inconsistency. The description does add value by noting URL auto-extraction and parameter behavior, but the contradiction undermines trust.

  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 concise (two sentences) and front-loaded with purpose, but the list of examples could be more structured (e.g., bullet points). Overall efficient and to the point.

  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 10 parameters and no output schema, the description covers all essential aspects: resource types, actions, URL usage, inputs, input sets, body, params, and references to other tools for supplementary info. It is complete for a complex exec tool.

  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?

  While schema coverage is 100%, the description adds significant meaning beyond the schema: e.g., URLs auto-identify resources, inputs accept key-value pairs or YAML, and it suggests using harness_describe for action-specific parameters. This extra context helps the agent parameterize correctly.

  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 'Execute an action on a Harness resource' and lists specific actions like run, retry, interrupt, etc., distinguishing it from siblings like harness_create, harness_delete, which handle CRUD operations.

  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 explicit context for using the tool (e.g., to trigger actions, pass a URL for auto-extraction). It references harness_get and harness_list for complementary setup, but does not explicitly 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.

• harness_searchA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that results are 'ranked by relevance' and that the tool 'Accepts a Harness URL for scope', which explains scope extraction behavior. 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?

  The description is two sentences, front-loaded with the core purpose and distinguishing features (search, relevance, URL scope). No wasted words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters, no output schema, and a complex search/scoping behavior, the description is too brief. It does not explain ranking algorithm, scope resolution (org/project extraction from URL), or the effect of parameters like compact and max_per_type. Incomplete for a search tool of this complexity.

  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 description adds high-level context about searching across types and URL scope, but does not explain parameter details beyond what the schema provides (e.g., what 'compact' does, default values). Minimal added value.

  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 'Search across multiple Harness resource types' and 'Returns results ranked by relevance', which distinguishes it from sibling tools like harness_list (which likely lists specific types) and harness_get (single resource). The title 'Search Harness Resources' reinforces this.

  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 implies usage for cross-resource search with relevance ranking, but it does not explicitly state when to use versus alternatives (e.g., harness_list for listing specific types) or when not to use. It provides clear context but lacks exclusions.

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

• harness_describeA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds that no API call is made, confirming it's a safe, local operation. This provides behavioral clarity beyond the 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?

  The description is two concise sentences: the first states core functionality, the second adds usage guidance. No extraneous information, efficiently 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 no output schema, the description explains the tool returns metadata about resource types, operations, and fields. This is sufficient for a discovery tool, though more detail on output format could be helpful.

  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% with each parameter described (e.g., 'Get details for a specific resource type'). The description does not add further meaning beyond what the schema already provides, meeting the baseline.

  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 describes available Harness resource types, their supported operations, and fields. It distinguishes itself as a local metadata-only tool to discover resource types for other harness_ tools, setting it apart from siblings like harness_create or harness_get.

  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 says 'No API call — returns local metadata only' and advises using it to discover resource types for other tools. While it doesn't list when not to use, it provides clear context and purpose.

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

• harness_getA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context about URL auto-extraction and ID-based retrieval, which enhances transparency without contradicting 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 sentences with no wasted words. The first sentence states purpose and key feature, the second gives usage guidance. Efficient and 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?

  Adequately covers the tool's purpose and key usage. For a retrieval tool with 6 parameters and no output schema, it provides enough context for an agent to decide when to use it, though more detail on return format would improve completeness.

  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 baseline is 3. The description adds value by explaining URL parameter auto-extracts identifiers and references harness_describe for fields, but does not significantly elaborate 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 clearly states the tool gets a Harness resource by ID and accepts a URL for auto-extraction. It distinguishes from the sibling harness_diagnose by directing failure analysis to that tool.

  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?

  Explicitly recommends harness_diagnose for failure analysis, providing a clear when-not-to-use. Does not cover other alternatives like harness_list or harness_search, but the guidance is specific and helpful.

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

• harness_statusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context beyond annotations: it returns a live health overview, can include a visual dashboard, and auto-extracts identifiers from a URL. No contradictions, and it complements the annotations well.

  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 fluff. It front-loads the core functionality and provides a practical usage suggestion. Every sentence adds value.

  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 5 parameters, no output schema, and the presence of annotations, the description adequately covers the tool's purpose, key parameters (url, limit, include_visual), and usage context. However, it does not explain the structure of the returned health overview, which might be helpful for an agent.

  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 already documents all parameters. The description adds no new parameter-specific information beyond what the schema provides; it only mentions the URL extraction functionality which is also stated in the schema. Baseline of 3 is appropriate.

  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's purpose: 'Get a live project health overview: recent failed executions, currently running executions, and recent deployment activity.' It uses a specific verb ('Get') and resource ('project health overview'), and distinguishes itself from sibling tools by focusing on a quick health summary rather than individual resource operations.

  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 provides clear context with 'Ideal first question: what's happening in my project right now?' and explains how to use a Harness URL for auto-extraction. However, it does not explicitly state when not to use this tool or mention alternative tools for more detailed queries.

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

• harness_diagnoseA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=true, consistent with diagnostic purpose. Description adds auto-detection behavior and default resource type. No contradictions; additional transparency about options like visual parameters and step log fetching.

  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?

  Description is four sentences with dense, relevant information; front-loaded with core purpose. Every sentence adds value, though the options detail could be slightly more compact. Overall efficient.

  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 6 parameters including a nested options object and no output schema, description covers default behavior, auto-detection, and detailed options. References harness_describe for further info. Missing output explanation but acceptable for a diagnostic tool.

  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?

  Schema coverage is 100%, but description adds substantial meaning beyond schema: explains auto-detection from url, defaults, and provides detailed documentation for the options object including all sub-keys (e.g., visual_width, visual_type, include_visual). This significantly enhances parameter understanding.

  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?

  Description clearly states it diagnoses Harness resources such as failures, connectivity, health, and GitOps sync issues. It explicitly defaults to pipeline execution diagnosis and distinguishes from sibling harness_describe by referencing it for details.

  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?

  Description outlines default behavior (pipeline execution) and auto-detection from URL. It also mentions calling harness_describe for details, providing an alternative. However, it does not explicitly state when not to use this tool.

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

• harness_schemaA
  4.4/5.0
  Behavior4/5

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

  Describes return type (JSON Schema definition) and path parameter behavior, adding value beyond annotations that already indicate read-only and open world. No contradictions.

  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 focused sentences plus a list of schemas; no wasted words. Front-loaded with main purpose, then specifics.

  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 annotations cover safety and open world, and schema covers parameters, description provides adequate context on path behavior and available schemas. No output schema but mentions return type.

  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?

  With 100% schema coverage, description enhances understanding by explaining path usage with examples and reiterating enum values for resource_type, going 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 clearly states 'Fetch Harness YAML schema for a resource type' with specific verb and resource, and explains its purpose for knowing body structure for harness_create/harness_update, distinguishing it from siblings.

  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?

  Provides clear guidance on using without path for summary and with path to drill into sections, along with available schemas. Lacks explicit 'when not to use', but context is sufficient.

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

• harness_createA
  4.7/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only, non-destructive, non-idempotent, open world. The description reinforces that this is a creation operation and adds context about body formats and git requirements, which is helpful beyond the 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?

  The description is concise with four sentences, front-loaded with the primary purpose, and every sentence adds essential guidance. No fluff or repetition.

  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?

  Despite the tool's complexity (6 params, nested objects, no output schema), the description covers key usage patterns: pipeline creation, remote git, and directing to harness_describe for other resources. It is complete and actionable for an AI agent.

  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 adds value by specifying that for pipelines, body should be a YAML string or JSON, and for remote pipelines, params must include git details. This clarifies the intended use beyond the schema's generic 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 clearly states 'Create a Harness resource' with a specific verb and resource. It distinguishes from sibling tools like harness_delete, harness_describe, etc., by providing explicit guidance for pipelines and deferring to harness_describe for other resource types.

  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?

  The description gives explicit when-to-use and when-not-to-use: for pipelines, recommends YAML vs JSON; for remote pipelines, explains git details needed; for other resources, instructs to call harness_describe for the body format. This clearly differentiates usage scenarios and alternatives.

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