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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds behavioral context by listing the specific reasons emitted (untagged, never_pulled, old_version) and confirming no deletion occurs. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with minimal sentences, yet fully informative. It uses bullet points for reasons, front-loading the purpose. Every sentence adds value without redundancy.

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

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

Given the tool has an output schema, the description complements it by explaining the reasons that appear in the output. Input parameters are fully covered in schema. References to sibling tools for actions complete the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 does not add additional meaning beyond the schema for parameters; it focuses on output reasons. This is adequate but not enhanced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool suggests artifacts for deletion to reclaim space, using specific verbs and resources. It distinguishes itself from deletion tools by emphasizing read-only nature and listing reasons emitted, which differentiates 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.

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

Explicitly states it is read-only and never deletes, and directs users to sibling deletion tools (harbor_delete_artifact, etc.) for acting on results. This provides clear when-to-use and when-not-to-use guidance.

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

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

Description goes beyond annotations by emphasizing 'DESTRUCTIVE & IRREVERSIBLE', explaining immediate manifest removal and blob reclamation during GC, with no soft-delete or undo. Also states the return value of freed space and tag list for confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is relatively concise with front-loaded purpose. The warning section is slightly redundant but adds value. Could be more streamlined without losing clarity.

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

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

Description covers purpose, behavioral impact, parameter clarification, and return value. For a destructive action with 3 required parameters, it adequately informs the agent. Output schema existence is noted but not detailed, which is acceptable given description covers return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with clear descriptions for each parameter. Description adds minimal value beyond schema, only clarifying that reference can be tag or digest. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Delete a single artifact by tag or digest', using a specific verb and resource. It distinguishes from sibling tools like harbor_delete_old_artifacts (batch deletion) and harbor_delete_untagged (deletes untagged artifacts).

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

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

Description implies usage for deleting a specific artifact by tag or digest. It does not explicitly mention when not to use or alternative tools, but the context of siblings provides some guidance. Lacks exclusions for bulk or untagged deletion scenarios.

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

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

Annotations already set destructiveHint=true and readOnlyHint=false. The description adds key behavior: 'dry_run=True is the default' and that each to_delete entry has a 'deleted' field (True/False after real run, None in dry-run). This adds value beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences plus a note. It front-loads the main purpose and essential safety information without any wasted words.

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

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

Given the output schema (mentioned in context signals) and good annotations, the description covers the key aspects: purpose, destructive nature, dry-run default, and a preview of the response. It is complete for a cleanup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all 4 parameters. The description adds extra context: the dry_run default behavior and the output field 'deleted' which is not in the input schema, providing additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state: 'Keep the N newest artifacts in a repository, delete the rest.' It uses a specific verb (delete) and resource (old artifacts in repository) and distinguishes from siblings like harbor_delete_artifact (single artifact) and harbor_delete_untagged (untagged only).

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

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

The description warns 'DESTRUCTIVE' and explains the dry_run default, advising the agent to explicitly set dry_run=False for actual deletion. This provides clear usage guidance and safety context, though it doesn't explicitly list 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.

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

Annotations already include destructiveHint=true and idempotentHint=true. Description adds context about what untagged artifacts are, that the sweep is opaque, and that response includes repos_scanned for visibility, enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three very concise sentences with bold for emphasis. Front-loaded with key action, no wasted words. Earns its length.

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

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

Given output schema exists and parameters are fully described in schema, description adds necessary behavioral context. Could mention output schema content briefly, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. Description adds nuance about opacity but doesn't add new parameter meaning beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it deletes all untagged artifacts in a project or single repository. Verb 'delete' plus resource 'untagged artifacts' with scope specified, differentiating from siblings like harbor_delete_artifact.

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

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

Explains when to use: for untagged artifacts which are typically orphaned and safe to delete. Mentions opaque project sweep and repos_scanned for visibility. Lacks explicit when-not or direct comparison to alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so safety is clear. The description adds useful behavioral context such as the fields returned (digest, size, timestamps, scan status) and pagination with has_more flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 4 sentences: purpose, returned fields, pagination, and alternative recommendations. No unnecessary words.

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

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

Given the tool's complexity (4 parameters, output schema), the description covers purpose, usage, behavioral details, and alternatives comprehensively. It is fully adequate for agent selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for all 4 parameters. The description adds value by explaining the pagination behavior and the has_more flag, which are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists artifacts (tags) in a repository, newest first, which is a specific verb and resource. It distinguishes itself from siblings like harbor_storage_report and harbor_cleanup_candidates by noting their internal pagination.

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

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

The description explicitly advises preferring harbor_storage_report or harbor_cleanup_candidates for repositories with hundreds of artifacts, providing clear when-to-use guidance. It also explains pagination mechanics.

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

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

Annotations already indicate readOnly, destructive, idempotent, and open-world hints. The description adds crucial behavioral context: sorting is per-page, pagination logic, and return structure, which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise (about 6 sentences) and well-structured. Front-loaded with main purpose, then usage guidance, pagination details, sorting caveat, and return format. No wasted words.

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

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

Given the presence of annotations covering safety and idempotency, and an output schema (implied by return key listing), the description fully covers purpose, usage, pagination, sorting nuance, and return structure for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good parameter descriptions. The description adds some context about per-page sorting affecting results, but does not significantly enhance parameter understanding beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List Harbor projects' with a specific verb and resource. It distinguishes from siblings by indicating it should be used first before harbor_list_repos and harbor_list_artifacts.

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

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

Explicitly says 'Use this first to discover which Harbor projects exist before drilling in with harbor_list_repos / harbor_list_artifacts.' Also provides pagination instructions.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds behavioral context: it explains pagination mechanics (has_more flag, calling again with page+1) and what data is returned per repository. This goes beyond annotations but does not cover rate limits or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: first states purpose, second adds output details and use case, third explains pagination. It is front-loaded and contains no unnecessary information. Every sentence earns its place.

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

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

For a list tool with pagination, the description covers purpose, reported data, and pagination. With output schema present and annotations providing safety hints, the description is largely complete. It does not mention prerequisites or error handling, but these are less critical given the output schema and simple parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers all 3 parameters with descriptions (100% coverage). The description does not add additional meaning to parameters beyond what the schema provides. The pagination detail refers to the response, not parameters, so parameter semantics are adequately covered by schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List repositories in a Harbor project' with specific verb and resource. It adds details about reported data (artifact count, pull count) and a use case (spotting unused repos before cleanup), distinguishing it from sibling tools like harbor_list_artifacts.

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

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

The description provides a use case ('useful for spotting unused repos before cleanup') but does not explicitly state when to use this tool vs alternatives like harbor_list_artifacts or harbor_cleanup_candidates. The context is implied rather than explicit, lacking exclusions or alternative recommendations.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it performs O(repos×artifacts) API calls and emits progress events, providing behavioral context beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: first states purpose, second explains method and performance, third mentions progress events. No filler words; every sentence adds value.

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

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

Given the annotations (readOnly, idempotent) and output schema existence, the description covers purpose, method, computational cost, and event output. No obvious gaps for a reporting tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter (project_name) described as 'Harbor project name.' The description adds no additional parameter detail beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Full storage breakdown for a Harbor project' and explains it iterates over repositories and artifacts. It positions itself as the canonical view for quota usage, distinguishing it from sibling tools like cleanup or deletion tools.

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

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

The description implies use for diagnosing quota usage ('what's eating up our quota?') and notes the computational cost (O(repos×artifacts) calls), but does not explicitly exclude other use cases or compare to siblings beyond mentioning its unique scope.

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