object_ground

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

With no annotations, the description carries the full burden, and it does disclose the return shape reasonably well: the four lower corners, the surface below, the distance, and the 'floats <x> m' / '<x> m in the ground' / min-max formatting. What is missing is any statement that this is a read-only query, whether it requires an open session or loaded world, and whether a missing object id produces an error or a null entry.

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?

It is a single sentence with no filler, but it is not front-loaded with a clean verb-resource phrase: it opens with an awkward nominal clause ('How project objects (ids) ... stand on the ground') and then piles the output formats into the same sentence. The information is dense but the structure makes it slower to parse than it needs to be.

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 four-parameter tool with a nested placement object, zero annotations, and no output schema, describing the returned corner/distance data is a meaningful contribution. Still, the definition omits the safety profile, session/map defaulting behavior (only in the schema), and failure modes, leaving gaps an agent would notice when actually invoking it.

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 75%, with `map`, `session`, `placement` and its nested `orientation` already documented in the schema, so the schema does most of the work. The description adds only the notion that either `ids` or `placement` is supplied and ties them to the two modes. It adds nothing about the undescribed `ids` array (ordering, duplicates, class-vs-id expectations) that would exceed the schema baseline.

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 concrete operation on a concrete resource: determining how project objects (referenced by ids) or a hypothetical placement sit relative to the ground surface, including the four lower box corners and their distances. That is far more specific than a restatement of the name. It does not, however, distinguish itself from the sibling tool `ground_at`, which is likely the per-point variant.

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 two operating modes (existing object ids vs. a hypothetical placement) are implied, but there is no guidance on when to choose this tool over `ground_at`, `check_overlap`, or `query_objects`, and no prerequisites such as needing an active session or objects already loaded. The agent must infer the selection criteria from the name alone.

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