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

readOnlyHint=true already declares this is a safe read, so the description's added value is the return-content disclosure (contact, CV, applications with hiring step). It omits behavior like not-found handling, authorization needs, or response shape, so 3 is appropriate given annotation coverage.

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, front-loading what the call returns and then the cross-tool link to create_applicant_note. 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 no output schema, the description carries the return-value burden and does so with a concrete field listing. Minor gaps remain (not-found behavior, whether applications are paginated), but the essential shape is clear.

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?

Only one parameter exists and the schema documents it fully at 100% coverage, including the source (from talenthr_list_applicants) and bounds. The description adds nothing 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 (Get) and resource (one candidate) plus the payload returned: contact data, description, CV info, and all applications with their hiring steps. The phrase 'one candidate' distinguishes it from the sibling talenthr_list_applicants.

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 a single applicant) and it links forward to talenthr_create_applicant_note via the application ids, but it never names talenthr_list_applicants as the way to obtain an applicant_id, leaving alternative selection implicit.

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