get_application

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

No annotations are provided, so the description carries the disclosure burden. It clearly states it's a read-only operation returning details and doesn't hint at any destructive or mutating behavior, which is inferred to be safe. However, it doesn't disclose pagination, response structure beyond a list of fields, or any rate-limit/auth considerations. Adequate for a read operation 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 sentences, front-loaded with the core purpose and a focused enumeration of returned fields. No wasted words. Could arguably add param guidance without becoming verbose, but current structure is clean and efficient.

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 detail return types, and the field list (source repo, sync status, health, destination, conditions) is useful. However, with 0% schema description coverage and undocumented parameters (especially 'instance' with a default), there's a noticeable gap. For a single-app detail tool with output schema present, it's adequate but could clarify both parameters.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. The description mentions fields returned but doesn't explain the 'name' and 'instance' parameters at all — notably 'instance' with its 'primary' default is undocumented. The description provides some context about the tool's output but nothing about how parameters relate to the output.

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 says 'Get detailed information about a specific ArgoCD application' with a clear verb+resource focus, and lists the specific details returned (source repo, sync status, health status, destination, conditions/errors). It distinguishes from siblings somewhat by noting it returns comprehensive details rather than status-only, though it doesn't explicitly contrast with get_application_status.

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

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

The description implies use when you need full application details vs. just status, but does not explicitly state when to use get_application_status instead for quick status checks, or when alternatives like list_applications or get_application_diff are appropriate. No explicit when/when-not guidance, just implied context from mentioning comprehensive detail coverage.

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