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

Goes well beyond the annotations: it discloses that activation COPIES programme checkpoints so later programme edits cannot retroactively change a past intern's requirements, and that the tool is proposal-only, returning status='confirmation_required' with action_id and plan_token, with the write occurring only after confirm_action. These are non-obvious, high-value behavioral facts an agent could not get from readOnlyHint/destructiveHint=false/openWorldHint=false.

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?

Front-loads the two activation modes, then tacks on the immutability rationale and the confirmation protocol — a sensible information ordering with no filler sentences. There is mild redundancy between 'Requires confirmation' and the following 'CONFIRMATION:' block, but the elaboration earns its place by naming the exact return fields.

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 an 8-parameter mutation with no output schema and no required fields, the description covers the two invocation shapes, the copy-on-activate semantics, and the full confirmation handshake. Remaining gaps are permissions/authorization expectations, behavior when the target internship is already active, and the meaning of responsible_user_id.

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 schema description coverage at 0% and 8 parameters, the description carries the burden and does well: it explains the internship_id vs person_id+program_id dichotomy, the optional application linkage, mentor, location and started_on. However, 'responsible_user_id' is never mentioned, and the schema reports zero required parameters even though one of the two mode groups is functionally required — that omission is not resolved by the description.

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 ('Start a trial period') and then disambiguates the two supported modes: activating a PLANNED internship by 'internship_id', or creating and activating one from 'person_id' + 'program_id'. An agent can tell exactly what this does and which path applies to it, distinct from sibling readers like hr_get_internship or hr_list_internships.

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?

Clearly explains which parameter combination selects which mode and names confirm_action as the mandatory follow-up, giving a concrete two-step workflow. It stops short of stating exclusions — e.g. what to do if the internship is already active, or when to prefer hr_complete_internship/other lifecycle tools — so it is clear context without explicit when-not guidance.

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