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

Annotations already declare readOnlyHint=true, and the description is consistent with a safe read. It adds useful substance beyond the annotations by telling the agent that results are scoped to the current room's blocks and are organized 'by number', implying a numbered index rather than a flat name list. That indexing detail is the key behavioral fact an agent needs and is not in any structured field.

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?

One short sentence with no filler, which is good, but it is not front-loaded with a verb and the trailing 'by number' clause is grammatically detached, making the sentence harder to parse than its length warrants.

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 parameters and no output schema, the description carries the whole burden of explaining the return shape, and 'by number' is too terse to fully convey the mapping format. It is adequate to know what you get, but an agent cannot be certain whether the response is a list, a dict keyed by index, or a count.

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?

Zero parameters, so the baseline is 4. The 'by number' phrase refers to return ordering rather than input, and the description correctly signals there is no argument to supply.

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 identifies a resource (texture names for this room's blocks) and implies it returns a numbered list, but never states the verb (list/return) explicitly and gives no hint of how it differs from siblings like appearance, face, or paint_faces. An agent can guess it is a static lookup table, but the phrasing is ambiguous enough that the purpose is only implied.

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 guidance on when to call this versus appearance, face, or paint_faces, even though the sibling list makes it plausible this is a prerequisite lookup for painting blocks. No prerequisites, no when-not-to-use, no alternative named.

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