density_view

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

With annotations already declaring non-readonly, idempotent and non-destructive, the description goes well beyond them: it explains that PyMOL normalises MRC/CCP4 maps to sigma, that absolute levels are converted before reaching PyMOL, that a default of 1.5 sigma is applied and labelled generic when level is omitted, and that EMDB depositions get a pointer to their published contour. The one gap is that it never says a new mesh object is created (and what happens if one of that name already exists), which is the actual mutation implied by readOnlyHint=false.

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 purpose is front-loaded in the first sentence and the ordering (problem, then policy, then prerequisite) is logical. Some material is heavier than needed for tool selection, notably the EMD-30913 worked example and the emphatic phrasing about the difference not being subtle, but every sentence still carries rationale an agent would otherwise lack.

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 6 parameters, an output schema and full schema coverage, the description supplies the pieces schema cannot: units semantics, the conversion rule, the default level behaviour and the load_map dependency. It is nearly complete, lacking only a note on mesh object naming/collision behaviour for a tool that creates an object.

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%, so every parameter is already documented in the schema, including units, level default, carve radius and name default. The description adds the rationale and the EMDB-pointer consequence of choosing absolute units, but it does not clarify anything the schema omits. 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 opening sentence states a specific verb and resource ("draw an isomesh around a selection") plus the distinguishing outcome (reporting the contour level in both units). It is clearly not a generic drawing tool. However, it never distinguishes itself from the sibling `isomesh` or `isosurface` tools, so an agent must guess which of the three to pick.

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?

It gives a clear usage condition for the units parameter (sigma for PyMOL, absolute for EMDB-published values) and states a hard prerequisite: the map must have been loaded through load_map because the conversion needs the header mean and RMS. What is missing is explicit routing against the sibling isomesh/isosurface tools, so the when-to-use context is clear but the when-not is absent.

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