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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds scoping context ("current document revision"), which is useful, but says nothing about behavior when the id is invalid or about the returned payload, so it is only modestly additive over the 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?

A single front-loaded sentence with zero filler. For a one-parameter read tool it is appropriately sized and wastes nothing.

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?

The tool is simple and annotations cover safety, but with no output schema and no parameter descriptions, the description leaves the agent without return-shape or error-behavior context. Adequate but with clear gaps for a body-inspection tool.

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 0%, so the description must carry parameter meaning. "Read one body" implies the single integer id identifies a body, which is a reasonable but minimal hint; it adds no format, range, or lookup guidance beyond that implication.

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?

"Read one body from the current document revision" states a specific verb (read) and resource (one body), and the singular "one body" implicitly distinguishes it from plasticity_list_bodies. However, it does not name or contrast against any sibling, so the differentiation is left to inference.

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 explicit when-to-use guidance, no mention of alternatives like plasticity_list_bodies or plasticity_select_bodies, and no prerequisites. The agent must infer that this is for retrieving details of a single known body id.

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

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description complements this by clarifying the catalog is 'bounded', only registered MCP operations are callable, the selected operation's original Zod schema and safety checks are applied, and it is 'not JavaScript execution'. That last point usefully closes off a plausible misinterpretation, though it does not describe what an invocation returns.

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?

Three tightly packed sentences with the core operation stated first, then the two usage modes, then the safety framing. No filler, no restatement of the title.

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?

For a dispatcher with a nested free-form 'arguments' object, no output schema, and 0% schema description coverage, the description covers the essential contract: how to browse, how to invoke, and that safety checks are enforced. It could still say what a successful invocation returns or how an invalid toolName is reported.

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 0%, so the description carries the burden, and it maps the parameters well: toolName selects 'catalog' or an operation name, query/offset/limit drive catalog browsing, and arguments is the target operation's argument object. It adds real meaning over bare type declarations, though limit/offset pagination semantics are only implied by the schema defaults.

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 states a specific verb+resource pair: 'Browse the bounded catalog of registered Plasticity MCP operations or invoke one by its exact tool name.' This cleanly separates the dispatcher role from every sibling in the list, which are the individual operations it would dispatch to.

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 concrete usage mechanics: use toolName='catalog' with query/offset/limit to read schemas, then set toolName to a returned operation name and pass its arguments. What is missing is guidance on when to route through this dispatcher versus calling a sibling tool (e.g. plasticity_create_circle) directly, which is the primary decision an agent faces.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description does not contradict them — the snapshot is an in-memory baseline read of the scene, not a mutation. It adds real value by describing the payload scope ('returns only the snapshot ID, document/revision identity and object counts'), which compensates for the absent output schema.

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 action and its purpose front-loaded and the follow-up usage trailing. No filler or repetition of the tool name.

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 summarizes what is returned, and annotations cover the safety profile, so an agent has what it needs to call and chain the tool. The only gap is the undocumented 'label' parameter, a minor omission for a 0-required-parameter tool.

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?

The single optional 'label' parameter has 0% schema description coverage and is never mentioned in the description, so no semantics are added. Impact is limited because the parameter is optional and self-explanatory, which keeps this at the minimum-viable baseline rather than lower.

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?

Specific verb+resource ('Capture an in-memory scene baseline') with an explicit scope and timing condition ('before manual edits'). It also names the downstream consumers (plasticity_changes_since, plasticity_wait_for_change), so an agent immediately understands this tool's role in the workflow.

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?

'before manual edits' states the intended moment to call it, and the second sentence tells the agent what to do with the returned ID, effectively routing to the two companion tools. There is no explicit when-not-to-use or statement of alternatives to this specific tool, but the workflow context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description goes further by disclosing pagination mechanics (bodyOffset default 0, bodyLimit default 20, max 100), the optimistic-revision contract, and the subtle sceneChanged vs revisionChanged distinction. That is real behavioral context an agent could not infer from the schema.

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?

Dense but front-loaded: the core purpose leads, then pagination instructions, then the companion tool, then the reporting caveat. Every sentence carries information, though the enumeration of diffed categories is long.

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 does the work of describing the return payload (changed-body B-Rep descriptors plus regions, planes, materials, visibility, instances, groups, selection), which is substantial. Remaining gap is minor: no error/expiry behavior and only implicit explanation of how the baseline snapshot is identified.

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 0%, so the description must carry parameter meaning, and it does for three of four: bodyOffset/bodyLimit defaults and maximum, and expectedRevision tied to current.revision. snapshotId is only implicitly described as the 'captured scene baseline', leaving its exact format/relationship to capture_snapshot unstated.

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?

States a specific verb and resource ('Return a structured diff from a captured scene baseline') and enumerates the diffed categories, so an agent can distinguish it from sibling inspection tools. It also explicitly routes topology-level detail to plasticity_body_info rather than leaving the boundary implicit.

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?

Gives concrete operating guidance: follow bodyPagination.nextOffset with expectedRevision set to current.revision, and use plasticity_body_info for detailed topology of selected bodies. It also tells the agent to check sceneChanged for a reportable edit. It stops short of stating explicit when-not conditions or the snapshot prerequisites.

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

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds that the initial scene summary is compact and that body bounds/counts are paginated, but never explains what 'connect' does to any existing connection/lifecycle state — which the destructive hint implies matters.

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 tight sentences, front-loaded with the primary action and its result, then the sibling routing. Nothing wasted.

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?

No output schema exists, and the description does supply a return summary and a pagination caveat. But for a connection-establishing tool with a required, undocumented parameter, it omits the target identifier format and any connection lifecycle/replacement behavior.

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 0% for the single required targetId. The phrase 'one explicit Plasticity window' implies targetId identifies a window, which is some added meaning, but the accepted format (id vs name) and the 'one window at a time' constraint are left unstated.

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?

Specific verb+resource: connecting the MCP process to one explicit Plasticity window, plus the return value (compact initial scene summary). This clearly distinguishes it from siblings like plasticity_list_windows, plasticity_status, or plasticity_call.

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?

Explicitly routes the agent to plasticity_body_info when exact body topology is needed, and warns that body bounds/counts are paginated. It does not, however, say when to prefer connect over plasticity_list_windows or plasticity_status, so the alternative routing is only partial.

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

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

Annotations already declare a safe, non-destructive, non-open-world read, so the safety profile is covered. The description usefully extends this by enumerating what entity categories are returned, which is the main added value, but it says nothing about ordering, empty-selection behavior, or how the result is structured.

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?

A single dense sentence that front-loads the verb and scope, with the entity list following. Every element earns its place; the only mild cost is the long enumeration, which is nonetheless informative rather than filler.

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 present, the description carries the burden of describing return content and does so by listing the returned entity types. It stops short of describing result structure or the empty-selection case, but for a read-only, zero-parameter tool it is close to sufficient.

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?

The tool takes zero parameters, so the schema is trivially complete and there is nothing for the description to compensate for. The baseline for a parameterless tool applies.

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?

States a specific verb ('Read') and a well-scoped resource ('...currently selected by the user'), then enumerates the entity kinds involved (bodies, instances, reference meshes, groups, faces, edges, regions, Wire handles). It is distinctly different from sibling list_*/select_* tools in intent, but it never names a sibling to contrast against, so the differentiation is implicit rather than stated.

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 phrase 'currently selected by the user' implies the operating context (inspect the live CAD selection) but gives no explicit when-to-use, no exclusions, and no pointer to alternative tools such as plasticity_select_bodies or plasticity_list_bodies. An agent can infer the intent but must guess at the boundary cases.

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

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

Annotations already declare this a safe, non-destructive read, so the description wisely spends its space on behavior annotations cannot express: page size defaults and the 100 cap, the revision-pinning requirement that prevents mixing pages after edits, and the fact that cone faces carry extra basis/axis/semi-angle data. This is exactly the kind of operational context an agent needs before paging.

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?

Four tight sentences with no filler; the purpose and pagination contract are front-loaded before the sibling pointer and the cone-face note. Slightly dense but every sentence carries a distinct fact.

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?

No output schema exists, and the description does a reasonable job describing what comes back (topology IDs, pagination cursor, cone face basis data). It does not fully enumerate the returned body fields, but for a paginated listing tool the critical call-correctness information is present.

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 0%, so the description must carry the load and it does: bodyOffset described (default 0) and bodyLimit (default 10, max 100) are both explained in prose, and expectedRevision is given meaning and format ('pass the previous page's revision'), not just a name.

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?

States a specific verb and resource ('List exact native B-Rep body details with topology IDs') and explicitly distinguishes itself from the closest sibling by naming plasticity_body_info and the condition that selects it. An agent can separate this from plasticity_body_info, plasticity_select_bodies, and plasticity_validate_bodies without opening a schema.

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?

Gives explicit when-to-use routing ('Prefer plasticity_body_info when only one body is needed') and mandatory pagination procedure with the nextOffset/expectedRevision contract. It also flags that the revision must be threaded to prevent mixing edits across pages, which is the key usage constraint.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: discovery happens over loopback CDP, i.e. a local debugging channel rather than geometry data. It does not say what happens when no windows are exposed or whether any connection setup is required.

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 front-loaded sentence with zero filler; the resource and its access mechanism are stated immediately and nothing is repeated from the schema or annotations.

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 should carry more of the return-shape burden — an agent cannot tell from this text whether entries are window titles, IDs, counts, or process handles, nor what an empty result means. The mechanism (loopback CDP) is a helpful hint but the result contract is left implicit.

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?

The tool takes zero parameters, so the description carries no parameter burden; baseline is 4. Nothing in the description conflicts with the empty schema.

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?

States a specific verb ('List') and resource ('Plasticity document windows exposed on loopback CDP'), which an agent can distinguish from the many CAD-operation siblings since none of them enumerate windows. It is clear without being tautological, though it does not contrast itself against any particular sibling.

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 tool versus alternatives, nor any prerequisite or exclusion. Usage is only implied by the name and the presence of a CDP-exposed window list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so safety is covered. The description adds genuinely non-annotation context about the timeout/disconnect recovery scenario, but the phrase 'allow later mutations' is mildly confusing for a read-only tool and no return behavior is described.

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?

A single front-loaded sentence leading with the scenario ('after a timeout or disconnect') and the effect. It is tight, though the trailing clause about not retrying the uncertain command reads slightly awkwardly.

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?

For a zero-parameter, no-output-schema tool, the description should make the post-call state clear. It explains the scenario but not what 'reading' yields or how the agent should proceed afterward, leaving a modest gap.

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?

The tool takes no parameters, so per the baseline there is nothing for the description to compensate for; schema coverage is 100% on an empty object. No parameter-level ambiguity exists.

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 conveys a specific operation: reading the document after a timeout or disconnect to reconcile uncertain state so later mutations can proceed without retrying. It is more than a restatement of the name, though the exact mechanism (what 'reconcile' does beyond reading) stays somewhat abstract.

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 clearly states the triggering condition (after a timeout or disconnect) and the intended effect (later mutations without retrying the uncertain command), which tells an agent when to reach for it. It does not, however, name any alternative recovery approach or exclusion.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description usefully adds that the file is written new and never overwritten, plus that hidden windows are rejected to avoid stale frames. That is real behavioral context beyond the annotations, though auth/permission needs and the return value go unmentioned.

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 tight sentences, both of which earn their place: the first gives the action and its non-overwrite guarantee, the second gives the refusal condition. No filler and the core action is front-loaded.

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 should ideally indicate what comes back (saved file path, or an error on hidden windows). It covers the write semantics and the refusal case, which is adequate for a one-parameter tool, but leaves the return contract unstated.

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 coverage is 0% for the single 'path' parameter, so the description carries the burden. It says the target is a 'new file' and will not be overwritten, implying a destination path, but it never states whether the path is absolute or relative or whether the .png extension must be included.

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?

States a specific verb and resource: saving a PNG screenshot of the visible Plasticity renderer viewport. That is far more precise than a sibling like plasticity_capture_snapshot, but the description never contrasts itself with that sibling explicitly, so differentiation is left to inference.

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 reach for this tool versus plasticity_capture_snapshot or plasticity_list_windows. The only condition mentioned ('refuses hidden windows') is a failure mode rather than usage guidance, leaving the agent to guess when this is the right capture tool.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so safety is covered. The description adds genuinely useful behavior beyond that: pagination defaults and maximums, and the revision-pinning mechanism that prevents scene edits from mixing pages. It stops short of describing error handling or failure modes, but the added context is substantial.

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?

Three dense sentences with zero filler, and the most important information (what it reads, what the payload contains) is front-loaded before the pagination mechanics and the sibling routing.

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 takes on the burden of describing the return content, which it does (identity, revision, body bounds, topology counts, Undo/Redo state), and it fully explains the paginated body-summary behavior. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 0%, so the description must carry the load, and it does: bodyOffset/bodyLimit defaults (0/50) and maximum (200) are given, and expectedRevision is explained in terms of passing the prior page's revision to avoid mixed pages. All three parameters are meaningfully documented.

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 opens with a specific verb ('Read') and resource ('compact document summary') and enumerates the exact payload: identity, revision, exact body bounds, topology counts, and Undo/Redo state. It is clearly distinguishable from siblings, which it names explicitly.

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 states when to reach for alternatives: 'Use plasticity_body_info for exact face/edge/vertex geometry of one body, or plasticity_list_bodies for paginated topology details.' It also describes the correct pagination workflow (follow bodyPagination.nextOffset, pass the prior page's revision as expectedRevision), so an agent knows both when to use it and how.

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