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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two genuinely useful behavioral facts: includeResume pulls in resume text (signalling a heavier payload), and everything under 'applicant' is applicant-authored, which is a provenance/trust warning. It stops short of describing error behavior or response shape beyond the field list.

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 returned payload and then the optional-parameter effect plus a caveat. The opening fragment 'An application: ...' is slightly elliptical but every clause carries information; nothing is redundant.

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 output schema and only 50% parameter coverage, the description carries real weight, and it does describe the returned fields and the one undocumented boolean. It is still missing the basic retrieval contract: that it fetches exactly one application by ID, and any failure mode for an invalid or removed ID. Adequate but with clear gaps for a single-record getter.

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 50%: applicationId is documented in the schema, includeResume is not. The description compensates by explaining that includeResume adds the resume's text, which gives the agent the cost/benefit needed to set it, but it does not restate the default or note that omitting it yields a lighter response. Baseline for this coverage level is a low 3, and the description does marginally better than that.

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 enumerates exactly what a fetched application contains (stage, AI match scores, applicant answers, team comments and activity), which makes the retrieval purpose unambiguous in combination with the name. It never states the verb explicitly ('retrieves one application by ID'), and it does not distinguish itself from list_applications, but the enumerated payload is specific enough that an agent knows what it gets back.

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 when-to-use guidance: nothing says to call this instead of list_applications for a single record, no note about what happens for a nonexistent or deleted application, and no prerequisites. The only pointer to a sibling ('from list_applications') lives in the schema's parameter description, not in the tool description itself.

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