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

Annotations provide readOnlyHint=true, so the agent already knows this is a safe read operation. The description adds useful context: it warns about the heavy payload, which is behavioral information beyond annotations. It also implies the response includes items, lists, timelines, and metadata, which adds clarity. There is no contradiction with 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 two sentences, front-loaded with the purpose ('Read full detail of a model') and then adds the heavy payload warning and alternative. Every sentence adds value; no fluff or verbosity. It is appropriately concise and structured for quick parsing.

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?

Given the tool has a single parameter with full schema coverage, no output schema (so return format is not documented), and annotations cover safety, the description covers the essential: what it reads, the payload size, and when to use an alternative. It doesn't describe return format or pagination, but for a simple get-by-id tool, this is adequate. A 4 is appropriate for near-completeness.

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 100%, and the schema already describes model_id with details about UUID format and scoping behavior. The description does not repeat parameter details but adds nothing new either. Since coverage is high, a baseline of 3 is typical, but the description's mention of different payload weights implicitly clarifies the parameter's role (selecting the model to read), so it slightly elevates to 4 for reinforcing usage context.

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 clearly states 'Read full detail of a model' with a specific verb ('Read') and resource ('model'), and enumerates the content ('items, lists, timelines, and metadata'). It also differentiates from sibling layerz_read by noting this is the heavy payload variant. This distinguishes it from other siblings and provides clear scope.

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 explicitly contrasts with layerz_read, advising 'prefer layerz_read for snapshots'. This gives a specific alternative and a condition (snapshots) for when to use the other tool. However, it doesn't provide detailed 'when-not-to-use' scenarios beyond the heavy payload hint, so it is clear but not exhaustive.

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