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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the bar is lower, yet the description still adds real value: it discloses the return shape {allowed: bool, ...} and the non-obvious detail that the underlying API answers with the string yes/no rather than a boolean. It also implicitly signals the check is scoped to 'the current account' (caller credentials), which the schema does not convey.

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?

Two sentences, zero filler, front-loaded with the core operation and followed immediately by the return-value caveat. Every clause 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?

An output schema exists so return values need no elaboration, and parameters are fully documented in the schema. The only missing piece is guidance on when to invoke the check and how to interpret a denial; for a simple read-only probe this is close to complete.

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 description coverage is 100% with enums documented for action and resource, so the schema carries the parameter burden. The description only restates the resource/action/subresource composition without adding format or semantic detail beyond the schema; baseline 3 applies.

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?

States a specific verb and resource: 'Check whether the current account may perform resource/action on a subresource.' It is unambiguously an RBAC permission probe, which no sibling tool performs (siblings are all get/list/create/patch/delete operations). It does not explicitly contrast itself with siblings, but the purpose is clear enough that no confusion arises.

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?

Usage is only implied: an agent can infer this is a pre-flight permission check before attempting an operation, but the description never states when to call it, when not to, or what to do with the result. There is no explicit alternative or condition given.

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=false and destructiveHint=false, so safety is covered. The description adds two pieces of non-obvious behavior: the return is 'slim' and it is 'Idempotent only with upsert=True' – both material to an agent deciding whether a retry is safe. It does not mention required permissions or side effects like auto-sync kicking off.

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 short sentences, all front-loaded: what it does, the alternative, the return and idempotency semantics. Every sentence earns its place and no filler is present.

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?

Output schema exists, so return values need not be explained; the description still adds the key 'slim' qualifier. For a 22-param create tool with full schema coverage and annotations, this is nearly complete – only concrete prerequisites (project must exist, repo must be registered) are missing.

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 every parameter is documented in the schema. The description adds no per-parameter syntax, constraints, or format guidance beyond the schema. Baseline 3 is correct when the schema does all the heavy lifting.

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?

States a specific verb+resource: create an ArgoCD application, and clarifies the parameter style ('flattened parameters'), distinguishing it from the structured-manifest approach used by some siblings. It does not explicitly name argocd_patch_application or argocd_generate_applicationset, but the reference to 'patch for anything this does not cover' gestures at the sibling.

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 tells the agent when to use patch instead ('Use patch for anything this does not cover'), which is a real routing rule. It does not state prerequisites (project existence, repo credentials) or when not to use create at all, so it falls short of 5.

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 destructiveHint=true and openWorldHint=true, so the safety profile is covered; the word 'destructive' mostly restates that. The clause 'cascade=False removes only the Application object' adds genuine blast-radius context beyond the annotations, though it overlaps with the cascade schema description.

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?

Very short and front-loaded with the verb and resource. The fragment 'destructive.' is awkward and largely redundant with the annotation, weakening the otherwise tight structure.

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?

With a full output schema and annotations covering the safety profile, the description need not explain returns. But for a destructive operation it omits practical guidance such as the default cascade=true behavior's consequences and when to prefer cascade=False or orphan.

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 description coverage is 100%, so the schema already documents all five parameters including cascade, project, and propagation_policy. The description's cascade note adds marginal meaning but no syntax or behavior beyond the schema, matching the baseline for full coverage.

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?

States a specific verb and resource ('Delete an application'), which clearly identifies the operation. However, it does not differentiate itself from siblings like argocd_delete_resource, leaving the agent to infer the distinction from the name alone.

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?

No when-to-use, when-not-to-use, or alternative guidance is given. It never mentions argocd_delete_resource or argocd_rollback_application, so the agent gets no routing context.

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 destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the trailing word 'destructive' is redundant with structured data. However, 'so the controller recreates it' is a genuinely useful behavioral fact not captured anywhere else – the deletion is not durable under GitOps reconciliation. Nothing is said about orphan/force semantics or auth requirements, so it stays at 3.

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?

Two short sentences, core action and effect front-loaded. The standalone 'destructive.' fragment duplicates the annotation and is the one piece that doesn't quite earn 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?

With an output schema present, a fully documented 10-parameter schema, and annotations covering the safety profile, the description only needs to convey the action and its reconciler side effect – which it does.

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 description coverage is 100%, including rich notes on project (404 vs 403) and app_namespace. The description adds no parameter 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.

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

States a specific verb and resource (delete a single managed resource) and even explains the GitOps consequence: the controller recreates it. This implicitly separates it from argocd_delete_application, though it never names a sibling explicitly, keeping it short of a 5.

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?

No when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative. The closest thing to guidance is the implied 'use this if you want the controller to recreate it', which is inference rather than instruction.

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 supply readOnlyHint=true, idempotentHint=true and openWorldHint=true. The description reinforces the safety profile with 'Creates nothing' and adds the JSON-manifest format constraint, but adds little beyond the structured data.

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 short, front-loaded sentences with the dry-run/no-write guarantee stated up front; nothing redundant or padded.

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?

An output schema exists so return values need no explanation, and the read-only nature is covered by annotations plus the 'Creates nothing' note. Only the lack of routing guidance to sibling tools keeps it from being fully complete.

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 description coverage is 100%, so both parameters are fully documented in the schema, and the baseline is 3. The phrase 'The manifest must be JSON' duplicates the schema's own 'Full ApplicationSet manifest as JSON' rather than adding new semantics.

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?

States a precise verb and resource ('Dry-run the generators: preview the applications an ApplicationSet would produce'), which clearly separates it from the list/get/create ApplicationSet siblings. The dry-run framing also disambiguates it from argocd_create_application.

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?

Conveys that this is a preview/dry-run operation, implying usage before committing an ApplicationSet, but never states when to prefer it over siblings like argocd_get_applicationset or argocd_list_applicationsets, nor any prerequisites.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the returned-field inventory and the refresh=hard reconciliation behavior, but the latter is already spelled out in the refresh parameter's schema description, so net new behavioral disclosure is modest.

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?

Two tight sentences with the return contents front-loaded and the refresh nuance second. No filler, though the second sentence is partly redundant with the schema.

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?

A read-only single-resource getter with full schema coverage and an output schema, so return-shape explanation is unnecessary. The description is adequate; only routing guidance against overlapping siblings is absent.

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 description coverage is 100%, so every parameter is documented in the schema and the baseline is 3. The description's refresh=hard sentence largely restates the refresh enum's own description rather than adding new syntax or defaults.

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?

States a specific verb and resource ('Get one application') and enumerates what is returned (spec, sync/health, conditions, operation, summary, resource counts). The 'one' scopes it against the many-apps sibling argocd_list_applications, but no sibling is named explicitly.

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?

No when-to-use guidance and no alternatives named. It does not tell the agent when to prefer this over argocd_list_applications, argocd_get_managed_resources, argocd_get_manifests, or argocd_get_resource_tree, all of which surface overlapping application data.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds real value beyond that: result ordering (newest first) and message truncation at 500 chars, which an agent could not know from annotations or schema.

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?

A single sentence that front-loads the core action and packs ordering plus truncation into the remainder. No filler, no repetition of the title.

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?

An output schema exists, so return values need no explanation, and annotations cover safety. The description covers ordering and truncation; the only omission is any guidance on paging (limit/offset) behavior or when this tool is the right choice, which is a minor gap for a read-only 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 description coverage is 100% and nine parameters are documented in-schema, including the project 403/404 semantics and the app_namespace override. The description adds nothing about parameters, so the baseline 3 applies.

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?

States a specific verb and resource ('Get Kubernetes events for an application') and adds two distinguishing traits: ordering ('newest first') and message truncation ('capped at 500 chars'). It is clearly separable from log/resource siblings, though it never names a sibling to contrast against.

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?

No when-to-use statement, no conditions, no alternatives. Nothing tells the agent whether to reach for this instead of argocd_get_pod_logs or argocd_get_resource when debugging an app; usage must be inferred from the tool name.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the useful ordering trait (newest first) but says nothing about pagination behavior or result volume, so with annotations carrying most of the load a 3 is right.

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?

A single tight sentence with zero filler, and the core resource (deployment history) is front-loaded before the parenthetical ordering and field details.

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?

An output schema exists so return values need no explanation, parameters are fully documented in the schema, and annotations cover the safety profile. The only material gap is routing guidance relative to similar history/operation siblings.

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 description coverage is 100%, so the schema already documents name, limit, offset, project, and app_namespace. The description adds only the "newest first" ordering hint relevant to offset/limit, so baseline 3 applies.

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?

States a specific verb+resource ("Get deployment history") and even specifies ordering (newest first) and returned content (revision, who deployed it, source). This clearly separates it from siblings like get_operation or get_manifests, though it never names an alternative.

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?

No when-to-use or when-not-to-use guidance is given, and none of the many similar siblings (get_application_events, get_operation, rollback_application) are referenced. The agent must infer usage purely from the resource name.

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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming what the read returns (generators, strategy, app statuses), going beyond the annotation set, though it does not mention pagination or auth requirements.

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?

A single front-loaded sentence that names the resource first and enumerates the returned content, with zero 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?

With a full output schema handling return structure and annotations covering safety, the description is nearly complete; the only minor gap is that it does not route the agent to the list/generate siblings or note any constraints.

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 description coverage is 100%, so all five parameters (name, full, appset_namespace, include_template, include_applications) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline of 3 when the schema does the heavy lifting.

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 states a specific verb and resource ("Get one ApplicationSet") plus the salient content it returns (generators, strategy, generated app statuses). The word "one" implicitly distinguishes it from argocd_list_applicationsets, but it does not explicitly name that sibling, so it falls short of a 5.

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?

Usage is only implied: "one" suggests a single-object fetch as opposed to the list sibling, but there is no explicit when-to-use statement, no prerequisites, and no mention of alternatives like argocd_generate_applicationset or argocd_list_applicationsets.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the credential config is always stripped, even when full=True — a non-obvious caveat an agent would otherwise miss. It does not mention auth or error behavior, keeping it short of a 5.

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?

Two short sentences, zero waste, with the primary purpose front-loaded and the credential caveat attached directly to the full=True case.

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?

An output schema exists, so return structure need not be explained, and the key gotcha (credential stripping) is disclosed. For a simple two-param read tool this is nearly complete; only explicit sibling routing guidance is absent.

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% and already documents both params, so baseline is 3. The description goes further by constraining the 'full' parameter's actual output (credentials removed even in raw mode), adding meaning the schema does not convey.

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?

States a specific verb ('Get') and resource ('one cluster') plus the two lookup keys, which distinguishes it cleanly from the sibling argocd_list_clusters. An agent can route between the single-get and the list without opening either schema.

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 singular 'one cluster' vs the sibling argocd_list_clusters implies the selection condition, but there is no explicit when-to-use guidance or statement of alternatives. Usage is inferable rather than stated.

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?

With readOnlyHint/idempotentHint already covering the safety profile, the description adds real behavioral detail: diffs are truncated by default, include_states expands output to three parsed manifest forms, and managedFields are stripped from them. It omits auth/permission needs and how truncation interacts beyond max_diff_chars, so not a full 5.

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?

Two sentences, zero filler; the primary behavior and its default truncation are front-loaded, and the opt-in expansion is stated immediately after. Every clause carries new information.

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?

An output schema exists, so return values need not be described, and the schema documents all 11 parameters. The description covers defaults and the one non-obvious parameter, leaving only permission/error semantics (e.g. the project 403/404 behavior) unmentioned, which the schema partly carries.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning beyond it by explaining what include_states actually returns (parsed target, normalized-live, predicted-live manifests with managedFields stripped) and by connecting 'truncated by default' to max_diff_chars.

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?

States a specific verb and resource ('Get managed resources') plus the distinctive payload (live-vs-desired diffs), which separates it from generic manifest fetchers. It does not name a sibling to differentiate itself from argocd_get_manifests or argocd_get_resource_tree, so it stops short of a 5.

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 never says when to use this tool rather than argocd_get_manifests, argocd_get_resource, or argocd_get_resource_tree, nor any prerequisites. The include_states sentence describes a parameter, not usage context, so an agent gets no routing 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The description usefully adds that the manifests are the rendered desired state and that output is parsed into objects and paged, but it omits error behavior (e.g. the 404/403 semantics tied to project, which live only in the schema) and any note on page-size defaults.

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?

A single sentence that front-loads the verb and resource and appends the two most decision-relevant behavioral facts (parsed objects, paging). There is no filler or restatement of the title.

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?

With an output schema present and 100% schema description coverage, the description does not need to enumerate parameters or return values, and it correctly stays brief. It is nearly complete for an 8-parameter read tool; only the absence of any sibling routing or error-context keeps it short of full marks.

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 description coverage is 100%, so every parameter, including the client-side kind/resource_name filters and the project 404/403 note, is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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 gives a specific verb and resource: 'Get the rendered desired manifests for a revision', and adds qualifiers ('rendered desired', 'parsed into objects', 'paged') that differentiate it from a raw live-resource fetch. It does not, however, name or contrast with the closest siblings such as argocd_get_managed_resources or argocd_get_resource, leaving that distinction to be inferred.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives. The phrase 'for a revision' faintly implies the revision-rendering use case, but an agent gets no signal about when to prefer this over argocd_get_managed_resources (live resources) or argocd_get_application.

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 confirm read-only, idempotent, open-world behavior. The description adds a genuinely useful edge case: it returns {"phase": null} when no operation has run, which is behavior an agent cannot infer from the annotations. This is helpful additional context, though it stops short of describing the full response shape.

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?

Two short sentences, front-loaded with the operation's core output, and the null-phase caveat immediately follows. No filler or redundant restatement of the name.

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?

Because an output schema exists, the description need not enumerate return values, and it correctly focuses on the one behavioral surprise (null phase). It is complete for the core call, though it could note the current-vs-last distinction's effect on the returned phase more explicitly.

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 every parameter is already documented in the schema, including namespace/name handling and the project 404/403 semantics. The description adds no parameter-level information beyond that baseline, which is correct but not additive.

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?

States a specific verb and resource ('Get the current or last sync operation') and enumerates the returned fields (phase, initiator, per-status result counts). It is clearly distinguishable from siblings like argocd_wait_for_operation or argocd_terminate_operation, which act on operations rather than reading them.

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?

Usage is implied by the read-only nature and the phrase 'current or last' operation, but the description never says when to prefer this over argocd_get_application, argocd_get_application_history, or argocd_wait_for_operation, nor does it state prerequisites or exclusions.

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 readOnly, idempotent and openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: it 'never follows' (non-streaming), terminates at the stream's last marker, and reports pods seen plus a shown_lines count.

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?

Two tight sentences with no filler; the key constraint ('never follows') is front-loaded and the return-shape details follow. Efficient and well-ordered.

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 14-parameter tool, the schema fully documents every parameter and an output schema exists to cover the return shape, so the description does not need to. It supplements with the streaming/termination behavior, leaving it adequately complete.

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 description coverage is 100%, so all 14 parameters are already documented in the schema (including the pod_name vs kind+resource_name selector and the project 403/404 semantics). The description adds no parameter-level detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Get container logs') with an added behavioral qualifier ('never follows'). It is unambiguous, and no sibling tool covers logs, so there is little risk of confusion, though the description does not explicitly differentiate itself from any named sibling.

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?

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or context. The usage is only implied by the resource name; an agent gets no routing help.

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, idempotentHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: role token values (jwtTokens) are never returned, only a count, which tells the agent not to expect secrets in the payload.

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?

Two short sentences, front-loaded with the core purpose and followed immediately by the one non-obvious caveat. No filler.

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?

With an output schema present and annotations covering the read-only/idempotent profile, the description does not need to explain return values. It is nearly complete, though it omits failure behavior (e.g. unknown project name) for an open-world lookup.

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 name, full and include_roles are already documented. The jwtTokens sentence duplicates the schema's own 'never jwtTokens' note on include_roles and adds no syntax or format detail beyond it, so the baseline 3 applies.

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?

States a specific verb ('Get') and resource ('a project') and enumerates the returned facets (allowed repos, destinations, whitelists/blacklists, roles), so an agent can tell it apart from argocd_list_projects and argocd_get_application. It does not explicitly name a sibling, so it falls short of a 5.

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?

Usage is implied: fetch one project's configuration by name. There is no explicit when-to-use vs argocd_list_projects, no note that a project name is required, and no stated alternatives or exclusions.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuine behavioral fact — branches and tags are paged independently with separate counts — but says nothing about caching (force_refresh) or auth/permission needs.

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?

One sentence, front-loaded with the verb and resource, and every clause (branches, tags, separate paging, separate counts) carries information. No filler.

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?

An output schema exists, so return values need not be described, and the annotations plus full schema coverage handle most of the burden. The remaining gap is routing guidance against sibling repository tools, which the description leaves implicit.

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 description coverage is 100%, so all five parameters are documented in the schema and the baseline is 3. The description's paging remark loosely hints at limit/offset semantics but adds no format or syntax detail beyond 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?

States a specific verb and resource ('Get a repository's branches and tags'), which clearly separates it from argocd_list_repositories and argocd_list_repository_apps. It does not explicitly name a sibling or contrast itself, so it stops short of a 5.

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?

No guidance on when to call this versus alternatives such as argocd_list_repositories or argocd_list_repository_apps, and no prerequisites (e.g. repo must be configured in Argo CD). Usage must be inferred from the name alone.

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 establish the safe-read profile (readOnlyHint, idempotentHint), so the description's added value is the payload transformation: managedFields and the last-applied annotation are stripped from the returned manifest. That is genuinely useful context beyond the structured fields, though it says nothing about error behavior or payload size limits.

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?

A single front-loaded sentence with no filler. The resource scope comes first and the payload caveat follows, which is exactly the right ordering for an agent skimming the text.

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?

With annotations covering safety and a full output schema plus complete parameter descriptions, the description only needs to characterize the tool's scope and output shape, which it does. It falls just short of complete because it omits any routing guidance among the many sibling read tools.

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 description coverage is 100%, so all nine parameters, including the 'full' toggle and the project 404/403 semantics, are already documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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 gives a specific verb and resource: retrieving a single managed resource's live manifest. It is clearly distinct from list-style siblings like argocd_get_managed_resources and argocd_get_manifests, though it never names those alternatives explicitly.

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?

Usage is only implied: the word 'single' suggests this is for one resource rather than a listing. There is no explicit when-to-use statement, no mention of when to prefer argocd_get_managed_resources or argocd_get_manifests, and no prerequisites such as needing an existing application.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description still adds genuine behavioral context: the node shape returned, the fields deliberately dropped (networkingInfo, uid, resourceVersion), and that filtering is applied client-side rather than server-side.

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 short sentences, front-loaded with the core action, then the payload shape, then the dropped fields and filter behavior. Nothing is padded and every clause carries information.

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?

With an output schema present, the description needn't explain return values, and it correctly stays brief while noting the trimming of fields. Annotations cover the safety profile and the schema covers all 9 params, so an agent has what it needs; only the relationship to sibling resource tools is left implicit.

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 description coverage is 100%, so every parameter is already documented in the schema (including 'Client-side kind filter'). The description repeats the client-side filtering semantics without adding syntax or format 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?

States a specific verb+resource ('Get the live resource tree') and even characterizes the output shape ('slim nodes (kind, name, health, images, parent)'). This clearly distinguishes it from data-oriented siblings, though it never names a sibling (e.g. get_managed_resources) to anchor the distinction.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named. The only usage-relevant hint is that kind/health filtering happens client-side, which is incidental rather than a directive about tool selection.

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, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds the returned field list but says nothing about auth requirements, error behavior, or how a missing revision is handled, so it adds only modest value.

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?

A single efficient sentence with the verb and field list front-loaded and zero filler. It is appropriately sized, though the terse colon-list form leaves no room for context.

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?

An output schema exists, so return-value explanation is not needed, and the schema covers parameters fully. However, for a 6-parameter tool, the description provides no usage context or disambiguation from sibling reads, leaving it minimally adequate.

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 description coverage is 100%, so the schema already documents all six parameters in detail (namespace/name handling, 404/403 semantics, source_index, version_id). The description adds no parameter-level meaning beyond what the schema provides, which is the baseline 3.

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?

States a specific verb ('Get') and resource ('commit metadata for a revision') and enumerates the fields returned (author, date, message, tags, signature). It is clearly distinguishable from sibling read tools like argocd_get_application_history, but it does not explicitly contrast itself against them.

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?

There is no guidance on when to use this tool versus alternatives such as argocd_get_application_history or argocd_get_manifests. No prerequisites or context of use are stated.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot convey: the default response is a slim view that drops OIDC/Dex config and UI banner fields.

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?

Two short sentences with no filler. The returned fields are front-loaded and the slim-view caveat follows immediately, giving an agent the key behavior without scrolling.

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?

An output schema exists, so return values need not be spelled out. Between the listed payload fields, the slim-vs-full tradeoff, and annotations covering safety, an agent has everything needed to call this correctly.

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% and the `full` flag is documented there, so the baseline is 3. The description earns above that by explaining the consequence of the default mode — exactly which fields are omitted in the slim view — which clarifies what `full=true` actually recovers.

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?

States a specific verb and resource (get server settings) and enumerates the payload contents: URL, enabled features, tracking method, plugin names. This clearly separates it from siblings like argocd_get_version or argocd_get_userinfo, though it never names those alternatives explicitly.

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 says what is returned but never when to reach for this tool versus argocd_get_version, argocd_get_userinfo, or argocd_can_i. Usage is only implied by the resource name, with no conditions, prerequisites, or exclusions.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the nature of the response (current syncability plus active/assigned windows), but since an output schema exists, it discloses little beyond what structured fields already provide.

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?

A single front-loaded sentence that names the subject first and then the returned facts, with no redundant or filler text.

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 read-only lookup with rich annotations and a declared output schema, the description covers the essential identity and content of the call. What is missing is routing guidance relative to siblings such as argocd_sync_application, which would make it fully self-sufficient.

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 description coverage is 100% with three well-annotated parameters (name, project, app_namespace) covering namespace/name syntax, 404/403 behavior and the ARGOCD_APP_NAMESPACE default. The description adds no additional parameter meaning, so the baseline 3 applies.

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?

States a specific verb (Get) and resource (sync windows) scoped to an application, and even enumerates the payload (can-sync-now, active and assigned windows). This clearly separates it from the mutating sibling argocd_sync_application, though it does not name any sibling to sharpen the distinction.

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?

Usage is implied rather than stated: the 'whether it can sync now' framing suggests checking windows before invoking argocd_sync_application, but the description never says when to use this versus alternatives or what prerequisites exist.

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, idempotentHint, and openWorldHint, covering the safety and side-effect profile. The description adds useful specifics about what is returned (groups, token issuer, login state), which goes beyond the annotations, though it does not discuss auth requirements or failure modes.

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?

A single front-loaded sentence that lists the key returned fields with zero filler. Every element 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?

With no parameters, rich annotations, and an output schema, the description is largely complete; it explains what identity fields are returned. It could note auth prerequisites but is otherwise sufficient.

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?

The tool takes zero parameters, so the baseline is 4. Schema coverage is 100% and there is nothing to document, so the description need not compensate.

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?

States a specific verb (Get) and resource (authenticated identity) and enumerates the exact fields returned (username, groups, login state, token issuer). This is clearly distinguishable from siblings like argocd_get_settings or argocd_can_i.

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 phrasing 'Get the authenticated identity' makes the when-to-use context clear: it is for identifying the calling user. However, it does not name alternatives or explicitly state when not to use it (e.g., versus argocd_can_i for permission checks).

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, idempotentHint and openWorldHint, so safety is covered. The description adds genuine behavioral context beyond that: it returns bundled tool versions, not just the server version, and it can serve as a connectivity probe, which tells the agent what a successful vs. failed call means.

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?

Two short sentences with zero filler; the primary purpose is front-loaded and the secondary 'probe' framing follows. Every clause 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?

With an output schema present, the description needn't enumerate return fields, and for a no-parameter read tool it is nearly complete. It could say marginally more about failure/error semantics when used as a probe, but nothing essential is missing.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is required and points at what the call returns instead.

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 names a specific verb and resource (get the Argo CD server version) plus the extra payload (bundled tool versions). No sibling tool covers version retrieval, so it is trivially distinguishable from the list/get cluster of 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?

'The connectivity probe' implies a usage context — checking that the server is reachable — but the description states no explicit when-to-use conditions, prerequisites, or alternatives it might replace (e.g., versus get_settings or get_userinfo for a health check). Usage is implied rather than specified.

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 idempotent=true and destructiveHint=false, so the safety profile is partly covered. The description meaningfully reinforces this by clarifying that the operation "removes nothing real" — important reassurance given readOnlyHint=false, which could otherwise make an agent hesitate. It does not state whether a resync/refresh cost or timing is involved.

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?

Two short sentences with zero padding: the action and its non-destructive nature are front-loaded, and every clause 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?

An output schema exists and annotations cover the safety profile, so the description is not obliged to explain return values. Purpose, trigger, and non-destructiveness are all present; only the mechanics of what happens after invalidation (cache rebuild behavior) are left implicit.

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?

With one parameter at 100% schema description coverage, the schema fully documents that it accepts a cluster name or server URL. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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 names a specific verb (invalidate) and resource (a cluster's cached resources) and explains the user-visible symptom it addresses (phantom OutOfSync or Unknown health). No sibling tool overlaps with this function, so explicit differentiation isn't needed, but it also doesn't route against alternatives.

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 standard fix for phantom OutOfSync or Unknown health" gives a clear, concrete trigger for when to reach for this tool. It stops short of stating when not to use it or naming an alternative diagnostic (e.g. get_resource_tree) first, so it is clear context without exclusions.

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/idempotentHint, so the safety profile is covered. The description adds genuinely new behavior: that sync_status, health_status, destination, and name_prefix are filtered client-side, that the endpoint has no paging, and that results are sorted by name and sliced here — important for interpreting limit/offset and result ordering.

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?

Two sentences, front-loaded with the core action and result shape, followed by the behavioral caveat. No filler; every clause carries information the agent needs.

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?

An output schema exists so return-value explanation is unnecessary, and the description covers the two non-obvious things an agent must know (client-side filtering and emulated paging). For a 12-parameter read-only list tool this is complete.

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, but the description goes beyond the schema by disclosing that four of the filters are applied client-side and that paging is emulated via sort-and-slice. This meaningfully changes how an agent should reason about limit/offset and filter reliability.

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?

States a specific verb+resource ('List applications') and immediately qualifies the shape of the result ('slim rows') with the returned fields enumerated. An agent can distinguish this from argocd_get_application or argocd_list_applicationsets without opening a schema.

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 explains the operational context an agent needs to choose it: it's a listing endpoint with no server-side paging, so limit/offset are applied locally. It does not, however, explicitly say when to prefer this over argocd_get_application for a single app or name an alternative, so it stops short of a full 5.

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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), so the description only needs to add context. It does add the returned field set (generators present, strategy, health, conditions), which tells the agent what a 'slim row' contains, but says nothing about pagination behavior despite limit/offset params.

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?

A single tight sentence with the verb and resource front-loaded and the output shape in a trailing parenthetical. Every clause carries information; nothing is padding.

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 read-only list tool with a full output schema and fully documented parameters, the description covers what is needed to select and call it. The only minor gap is that it doesn't acknowledge the pagination parameters or the null-filter defaults, though the schema handles those.

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 description coverage is 100%, so all five parameters (limit, offset, projects, selector, appset_namespace) are already documented in the schema. The description adds no filter syntax or behavioral detail beyond that, so the baseline of 3 applies.

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 pairs a specific verb ('List') with the exact resource ('ApplicationSets') and adds a scoping detail ('slim rows') that signals a lightweight listing rather than a full fetch. It implicitly distinguishes itself from argocd_get_applicationset (singular) and argocd_generate_applicationset, but never names an alternative explicitly.

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?

There is no statement of when to use this versus argocd_get_applicationset or argocd_generate_applicationset, and no mention of prerequisites or filtering context. The 'slim rows' phrasing implies a lighter-weight browse use case, but that is inference rather than 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the row shape includes connection state, server version, and app/cache counts, and the cluster credential config is never returned, which is an important security/data-scope disclosure.

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?

Two sentences, front-loaded with the core operation and followed by the critical data-exclusion note. Every sentence earns its place with no 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?

For a simple read-only list tool with full schema descriptions, a rich set of annotations, and an output schema, the description is complete enough to invoke correctly. It covers purpose, return scope, and a key omission without needing to restate schema details.

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 description coverage is 100% and all four parameters (name, limit, offset, server) are documented in the schema. The description adds no parameter-level syntax or filtering semantics beyond what the schema already provides, so the 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 states a specific verb and resource ('List clusters') and scopes the result shape ('slim rows') with returned fields, which implicitly distinguishes it from the singular argocd_get_cluster. An agent can tell this is a summary-list operation rather than a detail-fetch operation.

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?

No when-to-use guidance or alternatives are named. It does not say when to prefer this over argocd_get_cluster or how it relates to argocd_invalidate_cluster_cache, leaving the agent to infer usage from the verb alone.

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, idempotentHint and openWorldHint, covering the safety profile. The description adds genuine value by disclosing the returned content (counts, role names, sync-window count), but says nothing about pagination behavior, ordering, or the cost of openWorld discovery.

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?

A single efficient sentence with the resource and the returned shape front-loaded; nothing is wasted, though it is terse enough that a little more routing context could have been included without bloat.

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?

With an output schema present, the description need not explain return values, and it correctly signals the slim return shape. For a zero-required-param read-only list tool this is nearly complete; only the distinction from argocd_get_project is missing.

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 description coverage is 100% – name, limit and offset are all documented in the schema itself. The description adds no parameter detail (e.g. name matching semantics), so the baseline 3 applies.

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?

States a specific verb (List) and resource (projects) and further specifies the shape of what is returned (slim rows with repo/destination counts, role names, sync-window count). It implicitly contrasts with the singular argocd_get_project, but never names the sibling, so differentiation is left to inference.

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 phrase 'slim rows' implies this is a lightweight overview tool, suggesting use when a summary is wanted rather than full project detail, but no explicit when-to-use or when-not-to-use guidance is given and no alternative is named.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: credentials are never returned and has_credentials reports configured credentials, which prevents an agent from expecting secrets in the output.

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?

Two tight sentences with zero filler; the key safety fact (credentials never returned) is front-loaded after the purpose statement. Nothing is wasted.

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?

An output schema exists, so return-value details are unnecessary in the description, and the schema fully documents parameters. The main omission is any routing guidance versus the repository-related siblings, but for a simple read-only list tool the description is largely complete.

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 description coverage is 100%, so the schema already documents all five parameters (repo, limit, offset, app_project, force_refresh). The description adds no filter, paging, or refresh semantics beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ("List repositories") plus a distinguishing detail about the shape of results ("slim rows and connection state"). It does not explicitly distinguish itself from the close siblings argocd_get_repository_refs or argocd_list_repository_apps, so it stops short of a 5.

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 offers no when-to-use guidance, no prerequisites, and no alternatives. It never tells the agent when to prefer this over argocd_get_repository_refs or argocd_list_repository_apps. Usage is only implied by the verb "List".

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only that results are 'discoverable in a repository' (implying a scan), but says nothing about pagination behavior despite limit/offset parameters, nor about cost or failure modes for a bad revision.

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?

A single efficient sentence with the core action front-loaded and no filler. It is arguably too terse for a tool with five parameters, but nothing in it is wasted.

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?

An output schema exists so return values needn't be explained, and annotations carry the safety profile. Still, for a paginated repository-scanning tool the description is minimal – it omits paging semantics and how revision/app_project scope results, leaving the agent to infer usage.

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 description coverage is 100%, so all five parameters (repo, limit, offset, revision, app_project) are already documented in the schema. The description adds no extra syntax, format, or default behavior beyond what the schema states, so the baseline of 3 applies.

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?

Specific verb+resource: 'List the application paths (and their config type) discoverable in a repository.' It clearly states what is enumerated and adds the parenthetical about config type. It does not name or differentiate from siblings like argocd_list_repositories or argocd_get_repository_refs, which a reader could easily confuse with this.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The tool sits next to argocd_list_repositories and argocd_get_repository_refs, and nothing tells the agent when to pick this one over those.

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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds examples of action names but no additional behavioral context such as permission requirements, scoping rules, or response characteristics, which is acceptable but not enriching.

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 a single, front-loaded sentence that states the tool's purpose immediately. It contains no filler or repetition, and every word 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 read-only list tool with full schema coverage, rich annotations, and an output schema, the description is nearly complete. It clearly states what is listed, though it omits the practical relationship to argocd_run_resource_action, which would help an agent understand the workflow 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 description coverage is 100%, so all eight parameters are documented directly in the schema, including required fields and defaults. The description adds no parameter-level syntax or meaning beyond what the schema already provides, making the baseline 3 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 uses a precise verb 'List' and specific resource 'custom resource actions' scoped to 'available on a resource', with concrete examples (restart, pause). It clearly contrasts with the sibling argocd_run_resource_action by indicating discovery rather than execution, so an agent can distinguish the two 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.

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

The description states only what the tool does, not when to use it or how it relates to alternatives. It never mentions argocd_run_resource_action or any prerequisite for listing actions, leaving the agent to infer that this tool is used before running an action.

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 destructiveHint=false and idempotentHint=true, so the safety profile is covered structurally. The examples hint at merge-patch semantics (setting 'automated': null removes the field), but that behavior is never stated, nor are permission/RBAC needs or the consequences of a failed patch. Useful but not rich beyond the structured data.

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?

One short scoping sentence followed by two examples — no filler, and the tool's identity is front-loaded before the illustrative detail. Every sentence carries information.

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?

With an output schema present, return values need no explanation, and the 5 parameters are fully documented in-schema. The only residual gap for a write tool with openWorldHint=true is the absence of any note on how patch conflicts or invalid JSON bodies surface, which is minor.

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 earns an extra point by making the otherwise vague 'JSON patch body' concrete with two literal patch examples showing the expected shape. It adds nothing for name, project, patch_type or app_namespace, which the schema already documents well.

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?

States a specific verb (patch) and resource (application), then immediately positions itself as 'the one tool for every update', which distinguishes it from sibling mutators like argocd_sync_application, argocd_rollback_application and argocd_delete_application. The two inline examples make the tool's remit concrete rather than abstract.

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 phrase 'the one tool for every update' plus concrete examples (bump targetRevision, disable auto-sync) tells an agent exactly what class of change belongs here rather than in the dedicated sync/rollback tools. It stops short of stating exclusions explicitly — e.g. that a full sync or rollback should use the sibling tools instead of a hand-written patch.

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 destructiveHint=true and readOnlyHint=false, and the description repeats 'destructive' rather than adding to it. It does add real behavioral context beyond the annotations: the pre-read of the app that yields an actionable error, and the warning that the old revision is re-applied so Git must be fixed afterward.

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 short sentences plus a one-word hazard flag. The core action is front-loaded and every sentence carries unique information (action, precondition, post-action caveat) with no filler.

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?

An output schema exists so return values need not be described, and all 8 parameters are documented in the schema. The description covers the important operational nuances (auto-sync refusal, needing to fix Git), leaving only minor gaps like interaction between dry_run and the pre-read behavior.

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 description coverage is 100%, so name, history_id, wait, prune, dry_run, project, app_namespace, and timeout_seconds are all documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Roll back to a prior deployment history entry.' The action is inherently distinguishable from read siblings like argocd_get_application_history and from argocd_sync_application, but the description never names or contrasts against those siblings explicitly.

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?

Gives a concrete precondition (Argo CD refuses rollback while auto-sync is on) and the follow-up obligation (fix Git afterward). However, it does not route the agent to alternatives such as argocd_sync_application or explicitly state when-not to use rollback.

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 destructiveHint=true and readOnlyHint=false, so safety is covered. The description reinforces 'destructive' but adds no further behavioral context such as whether the action is reversible, what permissions are required, or what the response contains. With annotations present, the bar is lower, but additional context would be valuable.

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 extremely concise (one sentence) and front-loaded with the core purpose and examples. Every word 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 destructive action tool with 10 parameters and an output schema, the description is minimal. It covers the essence but omits important context such as authorization requirements (project scoping), the need to discover actions first, and error conditions. An agent would need to infer these from the schema and annotations.

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 all parameters are documented in the schema. The description mentions 'action' and target resource but does not add meaning beyond what the schema already provides (e.g., no clarification on the parameters object or group/version). Baseline 3 is appropriate when the schema does the heavy lifting.

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 action: running a custom resource action, with concrete examples (restart a Deployment, pause a Rollout). It distinguishes from read-only siblings like list_resource_actions. However, it does not explicitly name the sibling list_resource_actions as a prerequisite, leaving some ambiguity about how to discover available actions.

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?

There is no explicit guidance on when to use this tool versus alternatives. It does not mention that one should first call list_resource_actions to discover valid action names, nor does it describe prerequisites or typical use cases beyond the example.

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 destructiveHint=true, so the description earns credit for explaining WHY it is destructive (prune and force can delete or recreate resources) rather than restating the hint. It also discloses the async behavior (returns the started operation, or the final one with wait=True) and the `applications, override` RBAC requirement for revision.

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 short sentences, front-loaded with purpose and destructive rationale, with no filler. The 'Returns the started operation; with wait=True, the final one' sentence is slightly telegraphic but still earns its place by conveying async semantics.

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?

With annotations covering the safety profile, a 100%-covered schema, and an output schema for return values, the description supplies the missing pieces: destructive rationale, RBAC prerequisite, and operation lifecycle. It omits any precondition about the target app existing or the meaning of the default timeout, but nothing critical is missing.

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 description coverage is 100%, so the schema already documents all 13 parameters including force, prune, and revision. The description adds only the RBAC permission for revision override, which the schema itself already states ('needs override RBAC'), so it contributes essentially nothing new. Baseline 3 applies.

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?

States a specific verb+resource ('Sync an application') and immediately qualifies it with the destructive semantics. It is clearly distinguishable in intent from siblings like argocd_rollback_application or argocd_terminate_operation, though it never names an alternative to route the agent.

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?

Usage is only implied: the note that wait=True returns the final operation hints at a relationship with argocd_wait_for_operation, and the RBAC note implies a prerequisite for revision override. There is no explicit when-to-use/when-not-to-use guidance or named alternative for sync vs rollback.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds only the scoping qualifier 'running', and says nothing about what happens when no operation is running, permissions required, or error behavior. Adequate given annotations, but not rich.

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?

Two short sentences with zero waste; the action is front-loaded and the usage trigger follows immediately. Nothing could be removed without losing information.

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 3-parameter mutation with an output schema and rich annotations, the description covers what it does and when to use it. The only gap is behavior when no operation is running, which is a minor omission given the annotations and output schema present.

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% and every parameter is documented in-schema (including the 404/403 semantics of project and the ARGOCD_APP_NAMESPACE default), so the schema does the heavy lifting. The description adds no parameter meaning beyond what is already provided, making 3 the correct baseline.

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?

States a specific verb and resource: 'Terminate the running sync operation.' An agent can tell it apart from argocd_get_operation and argocd_wait_for_operation by the verb alone, though it does not explicitly name those 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?

Gives a clear trigger condition: 'Use to unstick a sync hanging in Running.' That is genuine when-to-use guidance. It stops short of naming alternatives (e.g., wait_for_operation) or stating 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 declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavior: it never errors on timeout and instead returns timed_out=true with the latest operation, sync, and health — an important contract for a polling tool. It omits any note on poll load or server-side cost, keeping it short of a 5.

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?

Two tight sentences with zero filler. The core behavior (poll until terminal/disappears/times out) is front-loaded, and the timeout contract follows immediately.

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?

With an output schema present and annotations covering the safety profile, the description carries only the burden of the polling semantics, which it discharges well. It could be marginally stronger by noting typical sequencing (e.g., call after sync/rollback/terminate), but nothing essential to correct invocation is missing.

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 description coverage is 100%, so all five parameters (name, project, app_namespace, timeout_seconds, poll_interval_seconds) are already documented with ranges and defaults. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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?

Names a specific verb+resource (poll an application's operation) and states the exact termination conditions: terminal phase, disappearance, or timeout. This clearly distinguishes it from the single-shot argocd_get_operation and from the action tools like argocd_sync_application.

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 conveys clear usage context: this is the tool to call when you need to block until an operation finishes rather than sample it once. However, it never explicitly names the alternative (argocd_get_operation) or states when not to use it, so the routing is implied rather than spelled out.

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