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

Annotations already mark the tool as read-only and non-destructive, covering the safety profile. The description adds a valuable behavioral detail: email and phone numbers in answers are masked, a privacy constraint the agent should anticipate. It also notes the report is 'frozen,' implying a snapshot, which is useful context beyond the annotations.

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 compact, consisting of two sentences with no fluff. The first sentence packs the purpose and included data, while the second adds the masking detail. It is front-loaded and every sentence 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 the response format is already defined externally. The description covers what the tool returns (examinee, answers, UTM, frozen report) and notes the masking behavior, which is sufficient for an agent to call the tool correctly. No additional context like pagination or permissions is needed for this single-read retrieval.

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 schema already fully describes the sole parameter `recordId` with 100% coverage, including its origin from `list_records`. The description reiterates this in text but does not introduce additional meaning or nuances beyond what the schema states. Since the schema carries the semantic load, a 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 clear verb ('View'), a specific resource ('submission record (lead)'), and scopes it to the current team and a single record id. It lists the contents (examinee, answers, UTM, frozen report), and explicitly references `list_records` as the source of the id, distinguishing it from other get/list tools.

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 provides a clear prerequisite by explaining that the record id comes from `list_records`, guiding the agent on how to obtain the argument. It implies this is the detailed view for one submission record but does not explicitly name alternatives or state when not to use them. The specificity of 'full detail' and the mention of report results give sufficient context to select it for inspection.

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