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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a useful scope note (diagnostics, reusable detached assemblies) and the 'no browser required' context, but says nothing about result volume, pagination, or what a broken-link diagnostic looks like.

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 tightly written sentences with the resource list front-loaded and no filler. 'No browser required' is a slightly cryptic trailing clause but it does add context rather than padding.

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 output schema, the description usefully enumerates the returned artifacts (maps, assemblies, spawn IDs, room links, diagnostics), and annotations carry the safety semantics. The gap is the missing relationship to sibling map-read tools, not the tool's own contract.

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?

Only one parameter (projectId) with 0% schema description coverage, so the description must compensate and does not. It never explains that projectId identifies the project whose library is read, only implying ownership through 'owned project maps'.

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 names a specific verb (Read) and enumerates concrete resources: owned project maps, detached assemblies, spawn IDs, room links, broken-link diagnostics. That is far more specific than a tautology, but it never distinguishes this tool from siblings like get_map, list_maps, or map_authoring_context, which appear to read overlapping map data.

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 use this versus get_map/list_maps/get_map_draft. 'No browser required' hints at an API-only path but does not name an alternative or a condition, leaving an agent to guess among several map-reading siblings.

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