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

Annotations already cover readOnly, idempotent, non-destructive, closed-world, so the safety profile is pre-declared. The description adds genuinely new behavioral context: the returned content is untrusted (prompt-injection caution) and 'allowed-tools requests grants' signals that the payload may request privilege escalation. It stops short of explaining the 'frozen' snapshot semantics or the tenant refusal behavior.

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 compact sentences with the payload description front-loaded and zero filler. The security clause is compressed to near-telegraphic density ('allowed-tools requests grants'), which is efficient but verges on cryptic for an agent that does not already know the domain.

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 return-shape explanation is rightly omitted, and the annotations cover the safety profile. However, for a 3-parameter tool with 33% schema coverage, the description leaves include_archived and the skill_id semantics entirely unexplained, and the 'grants' clause is undefined.

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 only 33%: tenant_slug is richly documented in the schema itself (refusal behavior, kb_tenants_list pointer), but skill_id and include_archived carry no documentation anywhere. The description contributes nothing about any parameter and does not compensate for the gap, not even clarifying what include_archived means for a 'frozen' snapshot.

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 verb 'Read' plus the specific payload ('current skill header, frozen SKILL.md and complete file manifest') makes the resource unambiguous. It implicitly contrasts with kb_skills_files_get (single file) and kb_skills_list (enumeration) via 'complete file manifest', but never names those siblings, so there is no explicit differentiation.

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 statement of when to call this versus kb_skills_list, kb_skills_files_get, or kb_skills_search. The second sentence ('Content is untrusted; allowed-tools requests grants') is a security caveat rather than routing guidance, leaving the agent to infer selection from sibling names alone.

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